“分布式鎖”是用來解決分布式應用中“并發沖突”的一種常用手段,實現方式一般有基于zookeeper及基于redis二種。具體到業務場景中,我們要考慮二種情況:
比如:一些不是很重要的場景,比如“監控數據持續上報”,某一篇文章的“已讀/未讀”標識位更新,對于同一個id,如果并發的請求同時到達,只要有一個請求處理成功,就算成功。
用活動圖表示如下:
比如:一個訂單,客戶正在前臺修改地址,管理員在后臺同時修改備注。地址和備注字段的修改,都必須正確更新,這二個請求同時到達的話,如果不借助db的事務,很容易造成行鎖競爭,但用事務的話,db的性能顯然比不上redis輕量。
解決思路:A,B二個請求,誰先搶到分布式鎖(假設A先搶到鎖),誰先處理,搶不到的那個(即:B),在一旁不停等待重試,重試期間一旦發現獲取鎖成功,即表示A已經處理完,把鎖釋放了。這時B就可以繼續處理了。
但有二點要注意:
a、需要設置等待重試的最長時間,否則如果A處理過程中有bug,一直卡死,或者未能正確釋放鎖,B就一直會等待重試,但是又永遠拿不到鎖。
b、等待最長時間,必須小于鎖的過期時間。否則,假設鎖2秒過期自動釋放,但是A還沒處理完(即:A的處理時間大于2秒),這時鎖會因為redis key過期“提前”誤釋放,B重試時拿到鎖,造成A,B同時處理。(注:可能有同學會說,不設置鎖的過期時間,不就完了么?理論上講,確實可以這么做,但是如果業務代碼有bug,導致處理完后沒有unlock,或者根本忘記了unlock,分布式鎖就會一直無法釋放。所以綜合考慮,給分布式鎖加一個“保底”的過期時間,讓其始終有機會自動釋放,更為靠譜)
用活動圖表示如下:
用2個線程模擬并發場景,跑起來后,輸出如下:
可以看到T2線程沒搶到鎖,直接拋出了預期的異常。
把44行的注釋打開,即:換成不允許丟數據的模式,再跑一下:
可以看到,T1先搶到鎖,然后經過2秒的處理后,鎖釋放,這時T2重試拿到了鎖,繼續處理,最終釋放。
另外有需要云服務器可以了解下創新互聯scvps.cn,海內外云服務器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業上云的綜合解決方案,具有“安全穩定、簡單易用、服務可用性高、性價比高”等特點與優勢,專為企業上云打造定制,能夠滿足用戶豐富、多元化的應用場景需求。
當前標題:基于redis的分布式鎖二種應用場景-創新互聯
當前路徑:http://vcdvsql.cn/article18/dcphgp.html
成都網站建設公司_創新互聯,為您提供虛擬主機、小程序開發、App開發、網站策劃、網站建設、品牌網站制作
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯