库存扣减还有这么多方案？
昨天一篇《库存扣多了，到底怎么整》，核心观点是：
•用“设置库存”替代“扣减库存”，以保证幂等性
•使用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-7代表了评论的多个观点，由于时间有限，《库存扣多了，到底怎么整》许多地方没有讲清楚，大伙见谅。
•用“设置库存”替代“扣减库存”，以保证幂等性
•使用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-7代表了评论的多个观点，由于时间有限，《库存扣多了，到底怎么整》许多地方没有讲清楚，大伙见谅。