余額并發(fā)扣減一致性，能否使用Redis事務？
《并發(fā)扣款，如何保證數據的一致性?》一文的核心觀點是：使用CAS樂觀鎖，在寫回余額時加上舊余額的比對，可以在不影響吞吐量的前提下，保證余額的一致性。
文章非常多朋友留言問，能不能把余額放到reids里，利用redis的事務性來扣減余額。今天，就這個問題簡單的說一下。
redis如何實現事務性?
本質也是樂觀鎖。
在redis客戶端執(zhí)行：
- $money = GET key
- $money = $money - $diff
- SET key $money
在并發(fā)量大的時候，會遇到和《并發(fā)扣款，如何保證數據的一致性?》中描述的并發(fā)一致性問題。
redis的WATCH和EXEC可以提供類似事務的機制：
- WATCH觀察key是否被改動
- 如果提交時key被改動，EXEC將返回null，表示事務失敗
上面保證一致性的余額扣減可能類似于這樣執(zhí)行：
- WATCH key
- $money = GET key
- $money = $money - $diff
- MULTI
- SET key $money
- EXEC
在WATCH之后，EXEC執(zhí)行之前，如果key的值發(fā)生變化，則EXEC會失敗。redis的WATCH為何能夠保證事務性，本質上，它使用的就是樂觀鎖CAS機制。
大部分情況下，redis不同的客戶端會訪問不同的key，所以WATCH碰撞的概率會比較小，在秒殺的業(yè)務場景，即使使用WATCH，調用側仍然需要重試。
畫外音：如《同樣是高并發(fā)，QQ/微博/12306的架構難度一樣嗎?》所述，key的訪問會過濾uid屬性，所以可以支持高并發(fā)。
在CAS機制這一點上，redis和mysql相比沒有額外的優(yōu)勢。
redis的性能之所以高，還是redis內存訪問與mysql數據落盤的差異導致的。內存訪問的不足是，數據具備“易失性”，如果重啟，可能導致數據的丟失。當然redis也可以固化數據，但如果每次都刷盤，redis反而性能會下降很多。
畫外音：每個工具都有自己的適用場景，不宜將緩存當數據庫用。
最后，redis用單線程來避免物理鎖，但mysql多線程也有多線程并發(fā)的優(yōu)勢。
畫外音：各有優(yōu)劣。
結論：可以使用redis的事務性扣減余額，但在CAS機制上比mysql沒有優(yōu)勢，高性能是因為其內存存儲的原因，帶來的副作用是數據有丟失風險。
任何脫離業(yè)務的架構設計都是耍流氓。
【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯系原作者】
