緩存鎖qi
前集回顧
前面兩篇文章我分別講了數據庫中的for update悲觀鎖還有樂觀鎖,都是基於項目實踐來講的,理論扯的比較少。連最常見的併發鎖機制不清楚的請看本人另外的鎖文章。
背景
普通基於mysql或oracle的鎖,在一般高併發當然夠用了,一般內部管理系統建議用這些鎖機制。但如果是像秒殺這種成千上萬人一起併發時,原來的方案肯定是扛不住的。成千上萬的請求同時落在mysql上,不卡死才怪。
業務場景
話說,現在也就阿里電商有這麼龐大的併發量,還有12306,每年高併發搶票那叫一個酸爽啊。
解決思路
緩存中間件,如流行的Redis分佈式鎖,tair緩存鎖,主要講Redis的鎖
redis鎖命令SETNX
鎖的思路是,如果 key 不存在,將 key 設置為 value 如果 key 已存在,則 SETNX 不做任何動作
偽代碼走起
原理
Redis為單進程單線程模式,採用隊列模式將併發訪問變成串行訪問,且多客戶端對Redis的連接並不存在競爭關係。其次Redis提供一些命令SETNX,GETSET,可以方便實現分佈式鎖機制。
下集預告
數據庫的悲觀鎖和樂觀鎖 ,緩存鎖都講完了,項目裡有實戰需要的同學可以參考我的思路進行code
下篇文章我來講下最原始的鎖synchronized,單機高併發情況下程序還是要靠他來鎖數據。
如果覺得對你有幫助請關注,有錯誤請指點,下篇繼續分析 【原始的鎖synchronized】
閱讀更多 程序汪汪 的文章