|
來自：掘金（作者：Vt 編輯：陶家龍）
原文鏈接：https:///post/5e61a454e51d4526f071e1df 目前通常所說的 Setnx 命令，并非單指 Redis 的 setnx key value 這條命令。一般代指 Redis 中對 Set 命令加上 NX 參數(shù)進(jìn)行使用，Set 這個命令，目前已經(jīng)支持這么多參數(shù)可選： SET key value [EX seconds|PX milliseconds] [NX|XX] [KEEPTTL]
當(dāng)然了，就不在文章中默寫 API 了，基礎(chǔ)參數(shù)還有不清晰的，可以蹦到官網(wǎng)。 
上圖是筆者畫的 Setnx 大致原理，主要依托了它的 Key 不存在才能 Set 成功的特性，進(jìn)程 A 拿到鎖，在沒有刪除鎖的 Key 時，進(jìn)程 B 自然獲取鎖就失敗了。
就算這樣，還是不能保證萬無一失。如果進(jìn)程 A 又不講道理，操作鎖內(nèi)資源超過筆者設(shè)置的超時時間，那么就會導(dǎo)致其他進(jìn)程拿到鎖，等進(jìn)程 A 回來了，回手就是把其他進(jìn)程的鎖刪了，如圖：
還是剛才那張圖，將 T5 時刻改成了鎖超時，被 Redis 釋放。進(jìn)程 B 在 T6 開開心心拿到鎖不到一會，進(jìn)程 A 操作完成，回手一個 Del，就把鎖釋放了。當(dāng)進(jìn)程 B 操作完成，去釋放鎖的時候（圖中 T8 時刻）： 
找不到鎖其實(shí)還算好的，萬一 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 這種隨機(jī)數(shù)。當(dāng)解鎖的時候，先獲取 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');
}
}
這回看起來是不是穩(wěn)了？相反，這回的問題更明顯了，在 Finally 代碼塊中，Get 和 Del 并非原子操作，還是有進(jìn)程安全問題。為什么有問題還說這么多呢？有如下兩點(diǎn)原因： 搞清劣勢所在，才能更好的完善。 上文中最后這段代碼，還是有很多公司在用的。
大小項(xiàng)目悖論： 大公司實(shí)現(xiàn)規(guī)范，但是小司小項(xiàng)目雖然存在不嚴(yán)謹(jǐn)，可并發(fā)倒也不高，出問題的概率和大公司一樣低。 -- 魯迅 
那么刪除鎖的正確姿勢之一，就是可以使用 Lua 腳本，通過 Redis 的 eval/evalsha 命令來運(yùn)行： -- lua刪除鎖：
-- KEYS和ARGV分別是以集合方式傳入的參數(shù)，對應(yīng)上文的Test和uuid。
-- 如果對應(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
通過 Lua 腳本能保證原子性的原因說的通俗一點(diǎn)：就算你在 Lua 里寫出花，執(zhí)行也是一個命令（eval/evalsha）去執(zhí)行的，一條命令沒執(zhí)行完，其他客戶端是看不到的。那么既然這么麻煩，有沒有比較好的工具呢？就要說到 Redisson 了。介紹 Redisson 之前，筆者簡單解釋一下為什么現(xiàn)在的 Setnx 默認(rèn)是指 Set 命令帶上 NX 參數(shù)，而不是直接說是 Setnx 這個命令。因?yàn)?Redis 版本在 2.6.12 之前，Set 是不支持 NX 參數(shù)的，如果想要完成一個鎖，那么需要兩條命令： 1. setnx Test uuid
2. expire Test 30
即放入 Key 和設(shè)置有效期，是分開的兩步，理論上會出現(xiàn) 1 剛執(zhí)行完，程序掛掉，無法保證原子性。但是早在 2013 年，也就是 7 年前，Redis 就發(fā)布了 2.6.12 版本，并且官網(wǎng)(Set 命令頁)，也早早就說明了“SETNX，SETEX，PSETEX 可能在未來的版本中，會棄用并永久刪除”。筆者曾閱讀過一位大佬的文章，其中就有一句指導(dǎo)入門者的面試小套路，具體文字忘記了，大概意思如下：說到 Redis 鎖的時候，可以先從 Setnx 講起，最后慢慢引出 Set 命令的可以加參數(shù)，可以體現(xiàn)出自己的知識面。如果有緣你也閱讀過這篇文章，并且學(xué)到了這個套路，作為本文的筆者我要加一句提醒：請注意你的工作年限！首先回答官網(wǎng)表明即將廢棄的命令，再引出 Set 命令七年前的“新特性”，如果是剛畢業(yè)不久的人這么說，面試官會以為自己穿越了。 Redisson 是 Java 的 Redis 客戶端之一，提供了一些 API 方便操作 Redis。但是 Redisson 這個客戶端可有點(diǎn)厲害，筆者在官網(wǎng)截了僅僅是一部分的圖： 
這個特性列表可以說是太多了，是不是還看到了一些 JUC 包下面的類名，Redisson 幫我們搞了分布式的版本。比如 AtomicLong，直接用 RedissonAtomicLong 就行了，連類名都不用去新記，很人性化了。鎖只是它的冰山一角，并且從它的 Wiki 頁面看到，對主從，哨兵，集群等模式都支持，當(dāng)然了，單節(jié)點(diǎn)模式肯定是支持的。本文還是以鎖為主，其他的不過多介紹。Redisson 普通的鎖實(shí)現(xiàn)源碼主要是 RedissonLock 這個類，還沒有看過它源碼的盆友，不妨去瞧一瞧。源碼中加鎖/釋放鎖操作都是用 Lua 腳本完成的，封裝的非常完善，開箱即用。這里有個小細(xì)節(jié)，加鎖使用 Setnx 就能實(shí)現(xiàn)，也采用 Lua 腳本是不是多此一舉？筆者也非常嚴(yán)謹(jǐn)?shù)乃伎剂艘幌拢哼@么厲害的東西哪能寫廢代碼？
其實(shí)筆者仔細(xì)看了一下，加鎖解鎖的 Lua 腳本考慮的非常全面，其中就包括鎖的重入性，這點(diǎn)可以說是考慮非常周全，我也隨手寫了代碼測試一下： 
的確用起來像 JDK 的 ReentrantLock 一樣絲滑，那么 Redisson 實(shí)現(xiàn)的已經(jīng)這么完善，RedLock 又是什么？
RedLock的中文是直譯過來的，就叫紅鎖。紅鎖并非是一個工具，而是 Redis 官方提出的一種分布式鎖的算法。 就在剛剛介紹完的 Redisson 中，就實(shí)現(xiàn)了 RedLock 版本的鎖。也就是說除了 getLock 方法，還有 getRedLock 方法。
如果你不熟悉 Redis 高可用部署，那么沒關(guān)系。RedLock 算法雖然是需要多個實(shí)例，但是這些實(shí)例都是獨(dú)自部署的，沒有主從關(guān)系。 RedLock 作者指出，之所以要用獨(dú)立的，是避免了 Redis 異步復(fù)制造成的鎖丟失，比如：主節(jié)點(diǎn)沒來的及把剛剛 Set 進(jìn)來這條數(shù)據(jù)給從節(jié)點(diǎn)，就掛了。 有些人是不是覺得大佬們都是杠精啊，天天就想著極端情況。其實(shí)高可用嘛，拼的就是 99.999...% 中小數(shù)點(diǎn)后面的位數(shù)。回到上面那張簡陋的圖片，紅鎖算法認(rèn)為，只要 2N+1 個節(jié)點(diǎn)加鎖成功，那么就認(rèn)為獲取了鎖， 解鎖時將所有實(shí)例解鎖。也就是說，假設(shè)鎖 30 秒過期，三個節(jié)點(diǎn)加鎖花了 31 秒，自然是加鎖失敗了。這只是舉個例子，實(shí)際上并不應(yīng)該等每個節(jié)點(diǎn)那么長時間，就像官網(wǎng)所說的那樣，假設(shè)有效期是 10 秒，那么單個 Redis 實(shí)例操作超時時間，應(yīng)該在 5 到 50 毫秒(注意時間單位)。還是假設(shè)我們設(shè)置有效期是 30 秒，圖中超時了兩個 Redis 節(jié)點(diǎn)。那么加鎖成功的節(jié)點(diǎn)總共花費(fèi)了 3 秒，所以鎖的實(shí)際有效期是小于 27 秒的。即扣除加鎖成功三個實(shí)例的 3 秒，還要扣除等待超時 Redis 實(shí)例的總共時間?？吹竭@，你有可能對這個算法有一些疑問，那么你不是一個人。回頭看看 Redis 官網(wǎng)關(guān)于紅鎖的描述，就在這篇描述頁面的最下面，你能看到著名的關(guān)于紅鎖的神仙打架事件。 
即 Martin Kleppmann 和 Antirez 的 RedLock 辯論。一個是很有資歷的分布式架構(gòu)師，一個是 Redis 之父。官方掛人，最為致命。開個玩笑，要是質(zhì)疑能被官方掛到官網(wǎng)，說明肯定是有價值的。所以說如果項(xiàng)目里要使用紅鎖，除了紅鎖的介紹，不妨要多看兩篇文章，即：看了這么多，是不是發(fā)現(xiàn)如何實(shí)現(xiàn)，都不能保證 100% 的穩(wěn)定。程序就是這樣，沒有絕對的穩(wěn)定，所以做好人工補(bǔ)償環(huán)節(jié)也是重要的一環(huán)，畢竟：技術(shù)不夠，人工來湊！
|
