库存扣减还有这么多方案? | 架构师之路

昨天一篇《库存扣多了,到底怎么整》,核心观点是:

  • 用“设置库存”替代“扣减库存”,以保证幂等性

  • 使用CAS乐观锁,在“设置库存”时加上原始库存的比对,避免数据不一致

文章非常多朋友留言发表观点,“架构师之路”能引发不少同学思考,甚是欣慰。

 

原以为两个核心观点应该是没有疑义的,结果很多朋友说方案不好,今天交流下部分回复的方案,个人的一些看法。

 

留言一

是否能使用

update stock set num=num-$count where sid=$sid and stock>=$count;

的方式扣减库存?

回答:这个方案无法保证幂等性,有可能出现重复扣减。

 

留言二

把库存放到reids里,利用redis的事务性来扣减库存。

分析

redis是如何实现事务操作的?

本质也是乐观锁。

在redis客户端执行:

$num = GET key

$num = $num - $count

SET key $num

在并发量大的时候,会遇到和《库存扣多了,到底怎么整》文章中一样的并发一致性问题。

 

redis的WATCH和EXEC可以提供类似事务的机制:

  • WATCH观察key是否被改动

  • 如果提交时key被改动,EXEC将返回null,表示事务失败

上面保证一致性的库存扣减可能类似于这样执行:

WATCH key

$num = GET key

$num = $num - $count

MULTI

SET key $num

EXEC

 

在WATCH之后,EXEC执行之前,如果key的值发生变化,则EXEC会失败。

 

redis的WATCH为何能够保证事务性,本质上,它使用的就是乐观锁CAS机制。

大部分情况下,redis不同的客户端会访问不同的key,所以WATCH碰撞的概率会比较小,在秒杀的业务场景,即使使用WATCH,调用侧仍然需要重试。

 

在CAS机制这一点上,redis和mysql相比没有额外的优势。

redis的性能之所以高,还是redis内存访问与mysql数据落盘的差异导致的。内存访问的不足是,数据具备“易失性”,如果重启,可能导致数据的丢失。当然redis也可以固化数据,难道每次都刷盘?redis真心没法当作mysql用。

 

最后,redis用单线程来避免物理锁,但mysql多线程也有多线程并发的优势。

 

回答:可以使用redis的事务性扣减库存,但在CAS机制上比mysql没有优势,高性能是因为其内存存储的原因,带来的副作用是数据有丢失风险,具体怎么用,还得结合业务折衷(任何脱离业务的架构设计都是耍流氓)。

 

柳岩三

支持幂等能否使用客户端token,业务流水?

能否使用时间戳,版本号来保证一致性?

回答:可以。

 

留言四

能否使用队列,在数据库侧串行执行,降低锁冲突?

回答:可以。

 

留言五

能否使用事务?

回答:容易死锁,吞吐量很低,不建议。

 

留言六

能否使用分布式锁解决,例如setnx, mc, zookeeper?

回答:可以,但吞吐量真的高么。

 

留言六

文章重点讲了幂等性和一致性,没有深入展开讲高吞吐,利用缓存抗读请求,利用水平扩展增加性能是提升吞吐量的根本方案。

回复:很中肯。

留言1-6代表了评论的多个观点,由于时间有限,《库存扣多了,到底怎么整》许多地方没有讲清楚,大伙见谅。

如果本文让你对redis的事务操作有个重新认识,帮忙点赞和转发哟。

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值