人妻少妇乱子伦精品_日韩人妻潮喷视频网站_日本最新最全无码不卡免费_日韩AV无码中文

當前位置: 首頁 > 科技新聞 >

專欄

時間:2019-11-13 00:48來源:網(wǎng)絡整理 瀏覽:
《并發(fā)扣款,如何保證數(shù)據(jù)的一致性?》一文的核心觀點是:使用CAS樂觀鎖,在寫回余額時加上舊余額的比對,可以在不影響吞吐量的前提下,保證余額的

《并發(fā)扣款,如何保證數(shù)據(jù)的一致性?》一文的核心觀點是:使用CAS樂觀鎖,在寫回余額時加上舊余額的比對,可以在不影響吞吐量的前提下,保證余額的一致性。

文章非常多朋友留言問,能不能把余額放到reids里,利用redis的事務性來扣減余額。今天,就這個問題簡單的說一下。

redis如何實現(xiàn)事務性?

本質(zhì)也是樂觀鎖。

在redis客戶端執(zhí)行:

 

在并發(fā)量大的時候,會遇到和《并發(fā)扣款,如何保證數(shù)據(jù)的一致性?》中描述的并發(fā)一致性問題。

redis的WATCH和EXEC可以提供類似事務的機制:

  • WATCH觀察key是否被改動
  • 如果提交時key被改動,EXEC將返回null,表示事務失敗

上面保證一致性的余額扣減可能類似于這樣執(zhí)行:

 

在WATCH之后,EXEC執(zhí)行之前,如果key的值發(fā)生變化,則EXEC會失敗。redis的WATCH為何能夠保證事務性,本質(zhì)上,它使用的就是樂觀鎖CAS機制。

大部分情況下,redis不同的客戶端會訪問不同的key,所以WATCH碰撞的概率會比較小,在秒殺的業(yè)務場景,即使使用WATCH,調(diào)用側仍然需要重試。

畫外音:如《同樣是高并發(fā),QQ/微博/12306的架構難度一樣嗎?》所述,key的訪問會過濾uid屬性,所以可以支持高并發(fā)。

在CAS機制這一點上,redis和mysql相比沒有額外的優(yōu)勢。

redis的性能之所以高,還是redis內(nèi)存訪問與mysql數(shù)據(jù)落盤的差異導致的。內(nèi)存訪問的不足是,數(shù)據(jù)具備“易失性”,如果重啟,可能導致數(shù)據(jù)的丟失。當然redis也可以固化數(shù)據(jù),但如果每次都刷盤,redis反而性能會下降很多。

畫外音:每個工具都有自己的適用場景,不宜將緩存當數(shù)據(jù)庫用。

最后,redis用單線程來避免物理鎖,但mysql多線程也有多線程并發(fā)的優(yōu)勢。

畫外音:各有優(yōu)劣。

結論:可以使用redis的事務性扣減余額,但在CAS機制上比mysql沒有優(yōu)勢,高性能是因為其內(nèi)存存儲的原因,帶來的副作用是數(shù)據(jù)有丟失風險。

任何脫離業(yè)務的架構設計都是耍流氓。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件,轉載請聯(lián)系原作者】

專欄

戳這里,看該作者更多好文

【責任編輯:趙寧寧 TEL:(010)68476606】
推薦內(nèi)容