分布式锁redlock 之 看大佬们吹牛皮

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

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 之 看大佬们吹牛皮的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。