#分布式锁redis和zookeeper

Google有一个名为Chubby的粗粒度分布锁的服务，然而，Google Chubby并不是开源的，我们只能通过其论文和其他相关的文档中了解具体的细节。值得庆幸的是，Yahoo！借鉴Chubby的设计思想开发了zookeeper，并将其开源，因此本文不讨论Chubby。至于Tair，是阿里开源的一个分布式K-V存储方案。我们在工作中基本上redis使用的比较多，讨论Tair所实现的分布式锁，不具有代表性。

因此，主要分析的还是redis和zookeeper所实现的分布式锁。

本文借鉴了两篇国外大神的文章，redis的作者antirez的《Is Redlock safe?》以及分布式系统专家Martin的《How to do distributed locking》，再加上自己微薄的见解从而形成这篇文章，文章的目录结构如下:
(1)为什么使用分布式锁
(2)单机情形比较
(3)集群情形比较
(4)锁的其他特性比较

先上结论:
zookeeper可靠性比redis强太多，只是效率低了点，如果并发量不是特别大，追求可靠性，首选zookeeper。为了效率，则首选redis实现。

#为什么使用分布式锁？

使用分布式锁的目的，无外乎就是保证同一时间只有一个客户端可以对共享资源进行操作。
但是Martin指出，根据锁的用途还可以细分为以下两类
(1)允许多个客户端操作共享资源
这种情况下，对共享资源的操作一定是幂等性操作，无论你操作多少次都不会出现不同结果。在这里使用锁，无外乎就是为了避免重复操作共享资源从而提高效率。
(2)只允许一个客户端操作共享资源
这种情况下，对共享资源的操作一般是非幂等性操作。在这种情况下，如果出现多个客户端操作共享资源，就可能意味着数据不一致，数据丢失。

原文:

https://yq.aliyun.com/articles/621136?spm=a2c4e.11157919.spm-cont-list.130.302c27aeKTjsDi

注:这里的redis锁都是带时间的, 自己项目中用的,都是hsetnx 无时间, try finally最后删掉

这是全局; 普通的锁都是些正常lock syn,concurrenthashmap 那些了