1
0
mirror of https://github.com/Snailclimb/JavaGuide synced 2025-06-20 22:17:09 +08:00

Update 如何做可靠的分布式锁,Redlock真的可行么.md

This commit is contained in:
Young Chen 2018-09-20 15:29:33 +08:00 committed by GitHub
parent 757470eecc
commit 227811711e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -3,8 +3,8 @@
开篇作者认为现在 Redis 逐渐被使用到数据管理领域,这个领域需要更强的数据一致性和耐久性,这使得他感到担心,因为这不是 Redis 最初设计的初衷(事实上这也是很多业界程序员的误区,越来越把 Redis 当成数据库在使用),其中基于 Redis 的分布式锁就是令人担心的其一。 开篇作者认为现在 Redis 逐渐被使用到数据管理领域,这个领域需要更强的数据一致性和耐久性,这使得他感到担心,因为这不是 Redis 最初设计的初衷(事实上这也是很多业界程序员的误区,越来越把 Redis 当成数据库在使用),其中基于 Redis 的分布式锁就是令人担心的其一。
Martin 指出首先你要明确你为什么使用分布式锁,为了性能还是正确性?为了帮你区分这二者,在这把锁 fail 了的时候你可以询问自己以下问题: Martin 指出首先你要明确你为什么使用分布式锁,为了性能还是正确性?为了帮你区分这二者,在这把锁 fail 了的时候你可以询问自己以下问题:
1. **要性能的:**拥有这把锁使得你不会重复劳动(例如一个 job 做了两次),如果这把锁 fail 了,两个节点同时做了这个 Job那么这个 Job 增加了你的成本。 1. **要性能的:** 拥有这把锁使得你不会重复劳动(例如一个 job 做了两次),如果这把锁 fail 了,两个节点同时做了这个 Job那么这个 Job 增加了你的成本。
2. **要正确性的:**拥有锁可以防止并发操作污染你的系统或者数据,如果这把锁 fail 了两个节点同时操作了一份数据结果可能是数据不一致、数据丢失、file 冲突等,会导致严重的后果。 2. **要正确性的:** 拥有锁可以防止并发操作污染你的系统或者数据,如果这把锁 fail 了两个节点同时操作了一份数据结果可能是数据不一致、数据丢失、file 冲突等,会导致严重的后果。
上述二者都是需求锁的正确场景,但是你必须清楚自己是因为什么原因需要分布式锁。 上述二者都是需求锁的正确场景,但是你必须清楚自己是因为什么原因需要分布式锁。
@ -91,4 +91,4 @@ Redlock 无法产生 fencing token 早该成为在需求正确性的场景下弃
Martin 认为 Redlock 实在不是一个好的选择,对于需求性能的分布式锁应用它太重了且成本高;对于需求正确性的应用来说它不够安全。因为它对高危的时钟或者说其他上述列举的情况进行了不可靠的假设,如果你的应用只需要高性能的分布式锁不要求多高的正确性,那么单节点 Redis 够了;如果你的应用想要保住正确性,那么不建议 Redlock建议使用一个合适的一致性协调系统例如 Zookeeper且保证存在 fencing token。 Martin 认为 Redlock 实在不是一个好的选择,对于需求性能的分布式锁应用它太重了且成本高;对于需求正确性的应用来说它不够安全。因为它对高危的时钟或者说其他上述列举的情况进行了不可靠的假设,如果你的应用只需要高性能的分布式锁不要求多高的正确性,那么单节点 Redis 够了;如果你的应用想要保住正确性,那么不建议 Redlock建议使用一个合适的一致性协调系统例如 Zookeeper且保证存在 fencing token。
## License ## License
* 原文 [怎样做可靠的分布式锁Redlock 真的可行么?](https://zhuanlan.zhihu.com/p/41327417) * 原文 [怎样做可靠的分布式锁Redlock 真的可行么?](https://zhuanlan.zhihu.com/p/41327417)