<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          細(xì)說(shuō)Redis分布式鎖

          共 4035字,需瀏覽 9分鐘

           ·

          2021-10-16 14:52


          談起Redis鎖,下面三個(gè),算是出現(xiàn)最多的高頻詞匯:

          • Setnx

          • Redlock

          • Redisson


          Setnx


          其實(shí)目前通常所說(shuō)的Setnx命令,并非單指Redis的setnx key value這條命令。

          一般代指Redis中對(duì)set命令加上nx參數(shù)進(jìn)行使用,set這個(gè)命令,目前已經(jīng)支持這么多參數(shù)可選:

          SET?key?value?[EX?seconds|PX?milliseconds]?[NX|XX]?[KEEPTTL]

          當(dāng)然了,就不在文章中默寫(xiě)API了,基礎(chǔ)參數(shù)還有不清晰的,可以蹦到官網(wǎng):https://redis.io/commands/set


          上圖是筆者畫(huà)的Setnx大致原理,主要依托了它的key不存在才能set成功的特性,進(jìn)程A拿到鎖,在沒(méi)有刪除鎖的Key時(shí),進(jìn)程B自然獲取鎖就失敗了。

          那么為什么要使用PX 30000去設(shè)置一個(gè)超時(shí)時(shí)間?

          是怕進(jìn)程A不講道理啊,鎖沒(méi)等釋放呢,萬(wàn)一崩了,直接原地把鎖帶走了,導(dǎo)致系統(tǒng)中誰(shuí)也拿不到鎖。


          就算這樣,還是不能保證萬(wàn)無(wú)一失。

          如果進(jìn)程A又不講道理,操作鎖內(nèi)資源超過(guò)筆者設(shè)置的超時(shí)時(shí)間,那么就會(huì)導(dǎo)致其他進(jìn)程拿到鎖,等進(jìn)程A回來(lái)了,回手就是把其他進(jìn)程的鎖刪了,如圖:


          還是剛才那張圖,將T5時(shí)刻改成了鎖超時(shí),被Redis釋放。

          進(jìn)程B在T6開(kāi)開(kāi)心心拿到鎖不到一會(huì),進(jìn)程A操作完成,回手一個(gè)del,就把鎖釋放了。

          當(dāng)進(jìn)程B操作完成,去釋放鎖的時(shí)候(圖中T8時(shí)刻):


          找不到鎖其實(shí)還算好的,萬(wàn)一T7時(shí)刻有個(gè)進(jìn)程C過(guò)來(lái)加鎖成功,那么進(jìn)程B就把進(jìn)程C的鎖釋放了。

          以此類(lèi)推,進(jìn)程C可能釋放進(jìn)程D的鎖,進(jìn)程D……(禁止套娃),具體什么后果就不得而知了。

          所以在用Setnx的時(shí)候,key雖然是主要作用,但是value也不能閑著,可以設(shè)置一個(gè)唯一的客戶(hù)端ID,或者用UUID這種隨機(jī)數(shù)。

          當(dāng)解鎖的時(shí)候,先獲取value判斷是否是當(dāng)前進(jìn)程加的鎖,再去刪除。偽代碼:
          String?uuid?=?xxxx;
          //?偽代碼,具體實(shí)現(xiàn)看項(xiàng)目中用的連接工具
          //?有的提供的方法名為set,有的叫setIfAbsent
          set?Test?uuid?NX?PX?3000
          try{
          //?biz?handle....
          }?finally?{
          ????//?unlock
          ????if(uuid.equals(redisTool.get('Test')){
          ????????redisTool.del('Test');
          ????}
          }
          這回看起來(lái)是不是穩(wěn)了。

          相反,這回的問(wèn)題更明顯了,在finally代碼塊中,get和del并非原子操作,還是有進(jìn)程安全問(wèn)題。


          為什么有問(wèn)題還說(shuō)這么多呢?

          第一,搞清劣勢(shì)所在,才能更好的完善。

          第二點(diǎn),其實(shí)上文中最后這段代碼,還是有很多公司在用的。

          大小項(xiàng)目悖論:大公司實(shí)現(xiàn)規(guī)范,但是小司小項(xiàng)目雖然存在不嚴(yán)謹(jǐn),可并發(fā)倒也不高,出問(wèn)題的概率和大公司一樣低。——魯迅


          那么刪除鎖的正確姿勢(shì)之一,就是可以使用Lua腳本,通過(guò)Redis的eval/evalsha命令來(lái)運(yùn)行:
          -- Lua刪除鎖:
          -- KEYS和ARGV分別是以集合方式傳入的參數(shù),對(duì)應(yīng)上文的Test和uuid。
          --?如果對(duì)應(yīng)的value等于傳入的uuid。
          if?redis.call('get',?KEYS[1])?==?ARGV[1]?
          ????then?
          ?--?執(zhí)行刪除操作
          ????????return?redis.call('del',?KEYS[1])?
          ????else?
          ?--?不成功,返回0
          ????????return?0?
          end
          通過(guò)Lua腳本能保證原子性的原因說(shuō)的通俗一點(diǎn):

          就算你在Lua里寫(xiě)出花,執(zhí)行也是一個(gè)命令(eval/evalsha)去執(zhí)行的,一條命令沒(méi)執(zhí)行完,其他客戶(hù)端是看不到的。

          那么既然這么麻煩,有沒(méi)有比較好的工具呢?就要說(shuō)到Redisson了。

          介紹Redisson之前,筆者簡(jiǎn)單解釋一下為什么現(xiàn)在的Setnx默認(rèn)是指set命令帶上nx參數(shù),而不是直接說(shuō)是Setnx這個(gè)命令。

          因?yàn)镽edis版本在2.6.12之前,set是不支持nx參數(shù)的,如果想要完成一個(gè)鎖,那么需要兩條命令:

          1.?setnx?Test?uuid
          2.?expire?Test?30

          即放入Key和設(shè)置有效期,是分開(kāi)的兩步,理論上會(huì)出現(xiàn)1剛執(zhí)行完,程序掛掉,無(wú)法保證原子性。

          但是早在2013年,也就是7年前,Redis就發(fā)布了2.6.12版本,并且官網(wǎng)(set命令頁(yè)[1]),也早早就說(shuō)明了“SETNX,SETEX,PSETEX可能在未來(lái)的版本中,會(huì)棄用并永久刪除”。

          筆者曾閱讀過(guò)一位大佬的文章,其中就有一句指導(dǎo)入門(mén)者的面試小套路,具體文字忘記了,大概意思如下:
          說(shuō)到Redis鎖的時(shí)候,可以先從Setnx講起,最后慢慢引出set命令的可以加參數(shù),可以體現(xiàn)出自己的知識(shí)面。
          如果有緣你也閱讀過(guò)這篇文章,并且學(xué)到了這個(gè)套路,作為本文的筆者我要加一句提醒:

          請(qǐng)注意你的工作年限!首先回答官網(wǎng)表明即將廢棄的命令,再引出set命令七年前的“新特性”,如果是剛畢業(yè)不久的人這么說(shuō),面試官會(huì)以為自己穿越了。

          你套路面試官,面試官也會(huì)套路你。——vt?沃茲基碩德


          Redisson


          Redisson是Java的Redis客戶(hù)端之一,提供了一些API方便操作Redis。

          但是Redisson這個(gè)客戶(hù)端可有點(diǎn)厲害,筆者在官網(wǎng)截了僅僅是一部分的圖:


          這個(gè)特性列表可以說(shuō)是太多了,是不是還看到了一些JUC包下面的類(lèi)名,Redisson幫我們搞了分布式的版本,比如AtomicLong,直接用RedissonAtomicLong就行了,連類(lèi)名都不用去新記,很人性化了。

          鎖只是它的冰山一角,并且從它的wiki[2]頁(yè)面看到,對(duì)主從,哨兵,集群等模式都支持,當(dāng)然了,單節(jié)點(diǎn)模式肯定是支持的。

          本文還是以鎖為主,其他的不過(guò)多介紹。

          Redisson普通的鎖實(shí)現(xiàn)源碼主要是RedissonLock這個(gè)類(lèi),還沒(méi)有看過(guò)它源碼的盆友,不妨去瞧一瞧。

          源碼中加鎖/釋放鎖操作都是用Lua腳本完成的,封裝的非常完善,開(kāi)箱即用。

          這里有個(gè)小細(xì)節(jié),加鎖使用Setnx就能實(shí)現(xiàn),也采用Lua腳本是不是多此一舉?筆者也非常嚴(yán)謹(jǐn)?shù)乃伎剂艘幌拢哼@么厲害的東西哪能寫(xiě)廢代碼?


          其實(shí)筆者仔細(xì)看了一下,加鎖解鎖的Lua腳本考慮的非常全面,其中就包括鎖的重入性,這點(diǎn)可以說(shuō)是考慮非常周全,我也隨手寫(xiě)了代碼測(cè)試一下:


          的確用起來(lái)像JDK的ReentrantLock一樣絲滑,那么Redisson實(shí)現(xiàn)的已經(jīng)這么完善,RedLock又是什么?


          RedLock



          RedLock的中文是直譯過(guò)來(lái)的,就叫紅鎖。

          紅鎖并非是一個(gè)工具,而是Redis官方提出的一種分布式鎖的算法。

          就在剛剛介紹完的Redisson中,就實(shí)現(xiàn)了redLock版本的鎖。也就是說(shuō)除了getLock方法,還有g(shù)etRedLock方法。

          筆者大概畫(huà)了一下對(duì)紅鎖的理解:


          如果你不熟悉Redis高可用部署,那么沒(méi)關(guān)系。RedLock算法雖然是需要多個(gè)實(shí)例,但是這些實(shí)例都是獨(dú)自部署的,沒(méi)有主從關(guān)系。

          RedLock作者指出,之所以要用獨(dú)立的,是避免了redis異步復(fù)制造成的鎖丟失,比如:主節(jié)點(diǎn)沒(méi)來(lái)的及把剛剛set進(jìn)來(lái)這條數(shù)據(jù)給從節(jié)點(diǎn),就掛了。

          有些人是不是覺(jué)得大佬們都是杠精啊,天天就想著極端情況。其實(shí)高可用嘛,拼的就是99.999……%中小數(shù)點(diǎn)后面的位數(shù)。

          回到上面那張簡(jiǎn)陋的圖片,紅鎖算法認(rèn)為,只要(N/2) + 1個(gè)節(jié)點(diǎn)加鎖成功,那么就認(rèn)為獲取了鎖, 解鎖時(shí)將所有實(shí)例解鎖。流程為:

          1. 順序向五個(gè)節(jié)點(diǎn)請(qǐng)求加鎖

          2. 根據(jù)一定的超時(shí)時(shí)間來(lái)推斷是不是跳過(guò)該節(jié)點(diǎn)

          3. 三個(gè)節(jié)點(diǎn)加鎖成功并且花費(fèi)時(shí)間小于鎖的有效期

          4. 認(rèn)定加鎖成功


          也就是說(shuō),假設(shè)鎖30秒過(guò)期,三個(gè)節(jié)點(diǎn)加鎖花了31秒,自然是加鎖失敗了。

          這只是舉個(gè)例子,實(shí)際上并不應(yīng)該等每個(gè)節(jié)點(diǎn)那么長(zhǎng)時(shí)間,就像官網(wǎng)所說(shuō)的那樣,假設(shè)有效期是10秒,那么單個(gè)Redis實(shí)例操作超時(shí)時(shí)間,應(yīng)該在5到50毫秒(注意時(shí)間單位)。

          還是假設(shè)我們?cè)O(shè)置有效期是30秒,圖中超時(shí)了兩個(gè)Redis節(jié)點(diǎn)。那么加鎖成功的節(jié)點(diǎn)總共花費(fèi)了3秒,所以鎖的實(shí)際有效期是小于27秒的。

          即扣除加鎖成功三個(gè)實(shí)例的3秒,還要扣除等待超時(shí)Redis實(shí)例的總共時(shí)間。

          看到這,你有可能對(duì)這個(gè)算法有一些疑問(wèn),那么你不是一個(gè)人。

          回頭看看Redis官網(wǎng)關(guān)于紅鎖的描述[3]。

          就在這篇描述頁(yè)面的最下面,你能看到著名的關(guān)于紅鎖的神仙打架事件。


          即Martin Kleppmann和Antirez的RedLock辯論。一個(gè)是很有資歷的分布式架構(gòu)師,一個(gè)是Redis之父。

          官方掛人,最為致命。

          開(kāi)個(gè)玩笑,要是質(zhì)疑能被官方掛到官網(wǎng),說(shuō)明肯定是有價(jià)值的。

          所以說(shuō)如果項(xiàng)目里要使用紅鎖,除了紅鎖的介紹,不妨要多看兩篇文章,即:

          • Martin Kleppmann的質(zhì)疑貼:http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

          • Antirez的反擊貼:http://antirez.com/news/101


          總結(jié)


          看了這么多,是不是發(fā)現(xiàn)如何實(shí)現(xiàn),都不能保證100%的穩(wěn)定。

          程序就是這樣,沒(méi)有絕對(duì)的穩(wěn)定,所以做好人工補(bǔ)償環(huán)節(jié)也是重要的一環(huán),畢竟:技術(shù)不夠,人工來(lái)湊~

          相關(guān)鏈接:

          1. https://redis.io/commands/set

          2. https://github.com/redisson/redisson/wiki/Table-of-Content

          3. https://redis.io/topics/distlock


          原文鏈接:https://juejin.cn/post/6844904082860146695




          瀏覽 52
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評(píng)論
          圖片
          表情
          推薦
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  淫色大吊人妖乱伦视频 | 少妇精品久久久久久久久久 | 一级a一级a爱片免费免免高潮 | 四虎AⅤ免费影院 | 爱爱网免费视频 |