看大佬們吹牛皮都有意思🐶

antirez: “快來看我搞的redlock，感覺還不錯哦。”
https://redis.io/topics/distlock

Martin: “你這個redlock不行啊。”
http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

antirez: “來，我來給你說一下為什么行。”
http://antirez.com/news/101

讀后感
redlock的兩個問題

獲取鎖的過程中

基于local time來判斷鎖的過期時間，local time因為其他原因被修改， 將不能保證鎖的嚴格的正確性 (人為修改，與時間服務器同步時間等)

獲取到鎖之后

獲取到鎖的實例，在鎖有效期期內沒干完活，超過有效期后，另一個實例可獲得同一個鎖。造成同一個鎖被多個實例持有。
可以通過不設置過期時間來解決這個問題，但是不設置過期時間又會造成死鎖無法自動解決。
當然這個不是redlock特有的問題。但凡帶過期時間的鎖，應該都有這個問題。

antirez 與 Martin 爭論的點:
redlock的定位比較尷尬。

相對于單節點的setnx，redlock需要多個實例節點
(官方舉例是5個)，增加了使用門檻。

相比單實例節點，雖然提高了一些正確性，但并不能保證嚴格的正確性。

個人認為 setnx or redlock
適合的使用場景

• 大部分的日常的業務，追求低成本，簡單易用，99%的情況下能正確使用就行，偶爾的錯誤對業務產生的影響不大。

不適合的場景

• 對于錯誤0容忍的場景，出一點點錯誤就會翻車出人命的那種。比如發火箭，自動駕駛，金錢交易。😂

redis作為緩存使用還是很優秀的。
只不過可能覺得 搞個分布式鎖似乎是舉手之勞，還沒想到這么好用，但確實沒有嚴格的正確性保證。

總結

以上是生活随笔為你收集整理的分布式锁redlock 之 看大佬们吹牛皮的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。