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

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