看大佬們吹牛皮都有意思?
antirez: 「快來看我搞的redlock，感覺還不錯哦。」
martin: 「你這個redlock不行啊。」
antirez: 「來，我來給你說一下為什麼行。」
讀後感redlock的兩個問題
獲取鎖的過程中
基於local time來判斷鎖的過期時間，local time因為其他原因被修改， 將不能保證鎖的嚴格的正確性 (人為修改，與時間伺服器同步時間等)
獲取到鎖之後
獲取到鎖的例項，在鎖有效期期內沒幹完活，超過有效期後，另乙個例項可獲得同乙個鎖。造成同乙個鎖被多個例項持有。可以通過不設定過期時間來解決這個問題，但是不設定過期時間又會造成死鎖無法自動解決。
當然這個不是redlock特有的問題。但凡帶過期時間的鎖，應該都有這個問題。
antirez 與 martin 爭論的點:
redlock的定位比較尷尬。
相對於單節點的setnx，redlock需要多個例項節點
(官方舉例是5個)，增加了使用門檻。
相比單例項節點，雖然提高了一些正確性，但並不能保證嚴格的正確性。
個人認為 setnx or redlock
適合的使用場景
不適合的場景
redis作為快取使用還是很優秀的。
只不過可能覺得 搞個分布式鎖似乎是舉手之勞，還沒想到這麼好用，但確實沒有嚴格的正確性保證。
Redlock分布式鎖
這篇文章主要是對 redis 官方 刊登的 distributed locks with redis 部分內容的總結和翻譯。安全特性 互斥訪問，即永遠只有乙個 client 能拿到鎖 避免死鎖 最終 client 都可能拿到鎖，不會出現死鎖的情況，即使原本鎖住某資源的 client crash 了或...
redLock可靠的分布式鎖
本文是對 martin kleppmann 的文章 how to do distributed locking 部分內容的翻譯和總結，上次寫 redlock 的原因就是看到了 martin 的這篇文章，寫得很好，特此翻譯和總結。感興趣的同學可以翻看原文，相信會收穫良多。開篇作者認為現在 redis ...
由Zookeeper看分布式鎖
zookeeper是乙個分布式協調服務的開源框架。主要用來解決分布式集群中應用系統的一致性問題。zookeeper 本質上是乙個分布式的小檔案儲存系統 提供基於類似於檔案系統的目錄樹方式的資料儲存，並且可以對樹中的節點進行有效管理。從而用來維護和監控你儲存的資料的狀態變化。通過監控這些資料狀態的變化...