庫存扣減還有這么多方案？
昨天一篇《庫存扣多了，到底怎么整》，核心觀點是：
- 用“設置庫存”替代“扣減庫存”，以保證冪等性
- 使用CAS樂觀鎖，在“設置庫存”時加上原始庫存的比對，避免數據不一致
原以為兩個核心觀點應該是沒有疑義的，結果很多朋友說方案不好，今天交流下部分回復的方案，個人的一些看法。
留言一
是否能使用
- update stock set numnum=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?
回答：可以，但吞吐量真的高么。
留言七
文章重點講了冪等性和一致性，沒有深入展開講高吞吐，利用緩存抗讀請求，利用水平擴展增加性能是提升吞吐量的根本方案。
回復：很中肯。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
