分布式锁的本质是在独立集群外的一个存储系统，设置一个值，并标记所有权，表明这个资源我占用了。
在分布式锁的场景中，部分失败和异步网络这两个问题是同时存在的。如果一个进程获得了锁，但是这个进程与锁服务之间的网络出现了问题，导致无法通信，那么这个情况下，如果锁服务让它一直持有锁，就会导致死锁的发生。
一般在这种情况下，锁服务在进程加锁成功后，会设置一个超时时间，如果进程持有锁超时后，将锁再颁发给其他的进程，就会导致一把锁被两个进程持有的情况出现，使锁的互斥语义被破坏。那么出现这个问题的根本原因是超时后，锁的服务自动释放锁的操作，它是建立在这样一个假设之上的：
锁的超时时间 >> 获取锁的时延 + 执行临界区代码的时间 + 各种进程的暂停（比如 GC）
对于这个假设，我们暂且认为“执行临界区代码的时间 + 各种进程的暂停”是非常小的，而“获取锁的时延”在一个异步网络环境中是不确定的，它的时间从非常小，到很大，再到因为网络隔离变得无穷大都是有可能的，所以这个假设不成立。
如果我们获得锁是为了写一个共享存储，那么有一种方案可以解决上面的问题，那就是在获得锁的时候，锁服务生成一个全局递增的版本号，在写数据的时候，需要带上版本号。共享存储在写入数据的时候，会检查版本号，如果版本号回退了，就说明当前锁的互斥语义出现了问题，那么就拒绝当前请求的写入，如果版本号相同或者增加了，就写入数据和当前操作的版本号。
但是这个方案其实只是将问题转移了，如果一个存储系统能通过版本号，来检测写入冲突，那么它已经支持多版本并发控制（MVCC）了，这本身是乐观锁的实现原理。那么我们相当于是用共享存储自身的乐观锁，来解决分布式锁在异常情况下，互斥语义失败的问题，这就和我们设计分布式锁的初衷背道而驰了。
所以，我认为对于在共享存储中写入数据等等，完全不能容忍分布式锁互斥语义失败的情况，不应该借助分布式锁从外部来实现，而是应该在共享存储内部来解决。比如，在数据库的实现中，隔离性就是专门来解决这个问题的。分布式锁的设计，应该多关注高可用与性能，以及怎么提高正确性，而不是追求绝对的正确性。
一.数据库
有性能问题。
二.zookeeper顺序临时节点
都设置顺序最小的01号节点。Zookeeper 是集群实现，可以避免单点问题，且能保证每次操作都可以有效地释放锁，这是因为一旦应用服务挂掉了，临时节点会因为 session 连接断开而自动删除掉。由于频繁地创建和删除结点，加上大量的 Watch 事件，对 Zookeeper 集群来说，压力非常大。
三.redis
单master节点模式
使用单个 Redis 节点（只有一个master）使用分布锁，如果实例宕机，那么无法进行锁操作了。那么采用主从集群模式部署是否可以保证锁的可靠性？
答案是也很难保证。如果在 master 上加锁成功，此时 master 宕机，由于主从复制是异步的，加锁操作的命令还未同步到 slave，此时主从切换，新 master 节点依旧会丢失该锁，对业务来说相当于锁失效了。
多个 Redis 节点（master节点）的 Redlock 算法
这个算法涉及的细节很多，作者在提出这个算法时，业界的分布式系统专家还与 Redis 作者发生过一场争论，来评估这个算法的可靠性，争论的细节都是关于异常情况可能导致 Redlock 失效的场景，例如加锁过程中客户端发生了阻塞、机器时钟发生跳跃等等。
使用注意：
1、使用 SET unique_val EX $second NX 命令保证加锁原子性，并为锁设置过期时间
2、锁的过期时间要提前评估好，要大于操作共享资源的时间
3、每个线程加锁时设置随机值，释放锁时判断是否和加锁设置的值一致，防止自己的锁被别人释放
4、因为在加锁操作中，每个客户端都使用了一个唯一标识，所以在释放锁操作时，我们需要判断锁变量的值，是否等于执行释放锁操作的客户端的唯一标识。所以释放锁时使用 Lua 脚本，保证操作的原子性
5、基于多个节点的 Redlock，加锁时超过半数节点操作成功，并且获取锁的耗时没有超过锁的有效时间才算加锁成功
6、Redlock 释放锁时，要对所有节点释放（即使某个节点加锁失败了），因为加锁时可能发生服务端加锁成功，由于网络问题，给客户端回复网络包失败的情况，所以需要把所有节点可能存的锁都释放掉
7、使用 Redlock 时要避免机器时钟发生跳跃，需要运维来保证，对运维有一定要求，否则可能会导致 Redlock 失效。例如共 3 个节点，线程 A 操作 2 个节点加锁成功，但其中 1 个节点机器时钟发生跳跃，锁提前过期，线程 B 正好在另外 2 个节点也加锁成功，此时 Redlock 相当于失效了（Redis 作者和分布式系统专家争论的重要点就在这）
8、如果为了效率，使用基于单个 Redis 节点的分布式锁即可，此方案缺点是允许锁偶尔失效，优点是简单效率高
9、如果是为了正确性，业务对于结果要求非常严格，建议使用 Redlock，但缺点是使用比较重，部署成本高
四.etcd
Etcd 支持以下功能，正是依赖这些功能来实现分布式锁的：
1、Lease 即租约机制（TTL，Time To Live）机制：
Etcd 可以为存储的 KV 对设置租约，当租约到期，KV 将失效删除；同时也支持续约，即 KeepAlive；
Redis在这方面很难实现，一般假设通过SETNX设置的时间10S，如果发生网络抖动，万一业务执行超过10S，此时别的线程就能回去到锁；
2、Revision 机制：
Etcd 每个 key 带有一个 Revision 属性值，每进行一次事务对应的全局 Revision 值都会加一，因此每个 key 对应的 Revision 属性值都是全局唯一的。通过比较 Revision 的大小就可以知道进行写操作的顺序。 在实现分布式锁时，多个程序同时抢锁，根据 Revision 值大小依次获得锁，可以避免 “惊群效应”，实现公平锁；
Redis很难实现公平锁，而且在某些情况下，也会产生 “惊群效应”；
3、Prefix 即前缀机制，也称目录机制：
Etcd 可以根据前缀（目录）获取该目录下所有的 key 及对应的属性（包括 key, value 以及 revision 等）；
Redis也可以的，使用keys命令或者scan，生产环境一定要使用scan；
4、Watch 机制：
Etcd Watch 机制支持 Watch 某个固定的 key，也支持 Watch 一个目录（前缀机制），当被 Watch 的 key 或目录发生变化，客户端将收到通知；
Redis只能通过客户端定时轮训的形式去判断key是否存在；
网友评论