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