亚洲熟女综合色一区二区三区,亚洲精品中文字幕无码蜜桃,亚洲va欧美va日韩va成人网,亚洲av无码国产一区二区三区,亚洲精品无码久久久久久久

  1. 馬哥教育官網(wǎng)首頁
  2. 技術(shù)干貨
  3. Linux云計算

細(xì)說Redis分布式鎖

Linux云計算, 技術(shù)干貨 4683
談起Redis鎖，下面三個，算是出現(xiàn)最多的高頻詞匯：
  • Setnx
  • Redlock
  • Redisson

Setnx

其實目前通常所說的Setnx命令，并非單指Redis的setnx key value這條命令。
一般代指Redis中對set命令加上nx參數(shù)進(jìn)行使用，set這個命令，目前已經(jīng)支持這么多參數(shù)可選：
細(xì)說Redis分布式鎖
當(dāng)然了，就不在文章中默寫API了，基礎(chǔ)參數(shù)還有不清晰的，可以蹦到官網(wǎng)：https://redis.io/commands/set
細(xì)說Redis分布式鎖
上圖是筆者畫的Setnx大致原理，主要依托了它的key不存在才能set成功的特性，進(jìn)程A拿到鎖，在沒有刪除鎖的Key時，進(jìn)程B自然獲取鎖就失敗了。
那么為什么要使用PX 30000去設(shè)置一個超時時間？
是怕進(jìn)程A不講道理啊，鎖沒等釋放呢，萬一崩了，直接原地把鎖帶走了，導(dǎo)致系統(tǒng)中誰也拿不到鎖。
細(xì)說Redis分布式鎖
就算這樣，還是不能保證萬無一失。
如果進(jìn)程A又不講道理，操作鎖內(nèi)資源超過筆者設(shè)置的超時時間，那么就會導(dǎo)致其他進(jìn)程拿到鎖，等進(jìn)程A回來了，回手就是把其他進(jìn)程的鎖刪了，如圖：
細(xì)說Redis分布式鎖
還是剛才那張圖，將T5時刻改成了鎖超時，被Redis釋放。
進(jìn)程B在T6開開心心拿到鎖不到一會，進(jìn)程A操作完成，回手一個del，就把鎖釋放了。
當(dāng)進(jìn)程B操作完成，去釋放鎖的時候（圖中T8時刻）：
細(xì)說Redis分布式鎖
找不到鎖其實還算好的，萬一T7時刻有個進(jìn)程C過來加鎖成功，那么進(jìn)程B就把進(jìn)程C的鎖釋放了。
以此類推，進(jìn)程C可能釋放進(jìn)程D的鎖，進(jìn)程D……（禁止套娃），具體什么后果就不得而知了。
所以在用Setnx的時候，key雖然是主要作用，但是value也不能閑著，可以設(shè)置一個唯一的客戶端ID，或者用UUID這種隨機數(shù)。
當(dāng)解鎖的時候，先獲取value判斷是否是當(dāng)前進(jìn)程加的鎖，再去刪除。偽代碼：
細(xì)說Redis分布式鎖
這回看起來是不是穩(wěn)了。
相反，這回的問題更明顯了，在finally代碼塊中，get和del并非原子操作，還是有進(jìn)程安全問題。
細(xì)說Redis分布式鎖
為什么有問題還說這么多呢？
第一，搞清劣勢所在，才能更好的完善。
第二點，其實上文中最后這段代碼，還是有很多公司在用的。
大小項目悖論：大公司實現(xiàn)規(guī)范，但是小司小項目雖然存在不嚴(yán)謹(jǐn)，可并發(fā)倒也不高，出問題的概率和大公司一樣低。——魯迅
細(xì)說Redis分布式鎖
那么刪除鎖的正確姿勢之一，就是可以使用Lua腳本，通過Redis的eval/evalsha命令來運行：
細(xì)說Redis分布式鎖
通過Lua腳本能保證原子性的原因說的通俗一點：
就算你在Lua里寫出花，執(zhí)行也是一個命令（eval/evalsha）去執(zhí)行的，一條命令沒執(zhí)行完，其他客戶端是看不到的。
那么既然這么麻煩，有沒有比較好的工具呢？就要說到Redisson了。
介紹Redisson之前，筆者簡單解釋一下為什么現(xiàn)在的Setnx默認(rèn)是指set命令帶上nx參數(shù)，而不是直接說是Setnx這個命令。
因為Redis版本在2.6.12之前，set是不支持nx參數(shù)的，如果想要完成一個鎖，那么需要兩條命令：
細(xì)說Redis分布式鎖
即放入Key和設(shè)置有效期，是分開的兩步，理論上會出現(xiàn)1剛執(zhí)行完，程序掛掉，無法保證原子性。
但是早在2013年，也就是7年前，Redis就發(fā)布了2.6.12版本，并且官網(wǎng)（set命令頁[1]），也早早就說明了“SETNX，SETEX，PSETEX可能在未來的版本中，會棄用并永久刪除”。
筆者曾閱讀過一位大佬的文章，其中就有一句指導(dǎo)入門者的面試小套路，具體文字忘記了，大概意思如下：
說到Redis鎖的時候，可以先從Setnx講起，最后慢慢引出set命令的可以加參數(shù)，可以體現(xiàn)出自己的知識面。
如果有緣你也閱讀過這篇文章，并且學(xué)到了這個套路，作為本文的筆者我要加一句提醒：
請注意你的工作年限！首先回答官網(wǎng)表明即將廢棄的命令，再引出set命令七年前的“新特性”，如果是剛畢業(yè)不久的人這么說，面試官會以為自己穿越了。
你套路面試官，面試官也會套路你?！獀t?沃茲基碩德

Redisson

Redisson是Java的Redis客戶端之一，提供了一些API方便操作Redis。
但是Redisson這個客戶端可有點厲害，筆者在官網(wǎng)截了僅僅是一部分的圖：
細(xì)說Redis分布式鎖
這個特性列表可以說是太多了，是不是還看到了一些JUC包下面的類名，Redisson幫我們搞了分布式的版本，比如AtomicLong，直接用RedissonAtomicLong就行了，連類名都不用去新記，很人性化了。
鎖只是它的冰山一角，并且從它的wiki[2]頁面看到，對主從，哨兵，集群等模式都支持，當(dāng)然了，單節(jié)點模式肯定是支持的。
本文還是以鎖為主，其他的不過多介紹。
Redisson普通的鎖實現(xiàn)源碼主要是RedissonLock這個類，還沒有看過它源碼的盆友，不妨去瞧一瞧。
源碼中加鎖/釋放鎖操作都是用Lua腳本完成的，封裝的非常完善，開箱即用。
這里有個小細(xì)節(jié)，加鎖使用Setnx就能實現(xiàn)，也采用Lua腳本是不是多此一舉？筆者也非常嚴(yán)謹(jǐn)?shù)乃伎剂艘幌拢哼@么厲害的東西哪能寫廢代碼？
細(xì)說Redis分布式鎖
其實筆者仔細(xì)看了一下，加鎖解鎖的Lua腳本考慮的非常全面，其中就包括鎖的重入性，這點可以說是考慮非常周全，我也隨手寫了代碼測試一下：
細(xì)說Redis分布式鎖
的確用起來像JDK的ReentrantLock一樣絲滑，那么Redisson實現(xiàn)的已經(jīng)這么完善，RedLock又是什么？

RedLock

細(xì)說Redis分布式鎖
RedLock的中文是直譯過來的，就叫紅鎖。
紅鎖并非是一個工具，而是Redis官方提出的一種分布式鎖的算法。
就在剛剛介紹完的Redisson中，就實現(xiàn)了redLock版本的鎖。也就是說除了getLock方法，還有g(shù)etRedLock方法。
筆者大概畫了一下對紅鎖的理解：
細(xì)說Redis分布式鎖
如果你不熟悉Redis高可用部署，那么沒關(guān)系。RedLock算法雖然是需要多個實例，但是這些實例都是獨自部署的，沒有主從關(guān)系。
RedLock作者指出，之所以要用獨立的，是避免了redis異步復(fù)制造成的鎖丟失，比如：主節(jié)點沒來的及把剛剛set進(jìn)來這條數(shù)據(jù)給從節(jié)點，就掛了。
有些人是不是覺得大佬們都是杠精啊，天天就想著極端情況。其實高可用嘛，拼的就是99.999……%中小數(shù)點后面的位數(shù)。
回到上面那張簡陋的圖片，紅鎖算法認(rèn)為，只要(N/2) + 1個節(jié)點加鎖成功，那么就認(rèn)為獲取了鎖， 解鎖時將所有實例解鎖。流程為：
  1. 順序向五個節(jié)點請求加鎖
  2. 根據(jù)一定的超時時間來推斷是不是跳過該節(jié)點
  3. 三個節(jié)點加鎖成功并且花費時間小于鎖的有效期
  4. 認(rèn)定加鎖成功
也就是說，假設(shè)鎖30秒過期，三個節(jié)點加鎖花了31秒，自然是加鎖失敗了。
這只是舉個例子，實際上并不應(yīng)該等每個節(jié)點那么長時間，就像官網(wǎng)所說的那樣，假設(shè)有效期是10秒，那么單個Redis實例操作超時時間，應(yīng)該在5到50毫秒（注意時間單位）。
還是假設(shè)我們設(shè)置有效期是30秒，圖中超時了兩個Redis節(jié)點。那么加鎖成功的節(jié)點總共花費了3秒，所以鎖的實際有效期是小于27秒的。
即扣除加鎖成功三個實例的3秒，還要扣除等待超時Redis實例的總共時間。
看到這，你有可能對這個算法有一些疑問，那么你不是一個人。
回頭看看Redis官網(wǎng)關(guān)于紅鎖的描述[3]。
就在這篇描述頁面的最下面，你能看到著名的關(guān)于紅鎖的神仙打架事件。
細(xì)說Redis分布式鎖
即Martin Kleppmann和Antirez的RedLock辯論。一個是很有資歷的分布式架構(gòu)師，一個是Redis之父。
官方掛人，最為致命。
開個玩笑，要是質(zhì)疑能被官方掛到官網(wǎ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)如何實現(xiàn)，都不能保證100%的穩(wěn)定。
程序就是這樣，沒有絕對的穩(wěn)定，所以做好人工補償環(huán)節(jié)也是重要的一環(huán)，畢竟：技術(shù)不夠，人工來湊～
相關(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

上一篇：

下一篇：

相關(guān)新聞

歷經(jīng)多年發(fā)展,已成為國內(nèi)好評如潮的Linux云計算運維、SRE、Devops、網(wǎng)絡(luò)安全、云原生、Go、Python開發(fā)專業(yè)人才培訓(xùn)機構(gòu)!