z13197919100的博客

先基于单机模式，基于Jedis手工造轮子实现自己的分布式锁。首先看两个命令：Redis分布式锁机制，主要借助setnx和expire两个命令完成。setnx是set的简写。将key的值设为value，当且仅当key不存在;若给定的key已经存在，则 setnx不做任何动作。expire 命令为key设置生存时间，当key过期时生存时间为0 )，它会被自动删除。其格式为：通过Redis的setnxexpire。

在单体的应用开发场景中，在多线程的环境下，涉及并发同步的时候，为了保证一个代码块在同一时间 只能由一个线程访问，我们一般可以使用 synchronized 语法和去保证，这实际上是本地锁的方式。也就是说，在同一个 JVM内部，大家往往采用或者Lock的方式来解决多线程间的安全问 题。但在分布式集群工作的开发场景中，在 JVM之间，那么就需要一种更加高级的锁机制，来处理种跨 JVM 进程之间的线程安全问题。解决方案是：使用分布式锁。

如果自己没有获得锁，则要监听前一个节点，此时需要找出前一个节点的路径，并保存在 prior_path 成员中，供后面的 await（）等待方法去监听使用。这里，仅仅去监听自己前一个节点的变动，而不是其他节点的变动，提升效率。一旦队列中的后面的节点，获得前一个子节点变更通知，则开始进行判断，判断自己是否为当前子节点列表中序号最小的子节点，如果是，则认为加锁成功；因为，在获取的远程子节点列表中的其他路径返回结果时，返回的都是短路径，都只有最后一层路径。（2）判断是否是第一个，如果是第一个，则加锁成功。

理解了经典的公平可重入锁的原理后，再来看在分布式场景下的公平可重入锁的原理。通过前面的分析，基本可以判定：ZooKeeper 的临时顺序节点，天生就有一副实现分布式锁的胚子。为什么呢？ZooKeeper的每一个节点，都是一个天然的顺序发号器。在每一个节点下面创建临时顺序节点（EPHEMERAL_SEQUENTIAL）类型，新的子节点后面，会加上一个次序编号，而这个生成的次序编号，是上一个生成的次序编号加一。例如，有一个用于发号的节点 “/test/lock”

另外，先到先得，号排在前面的人先取到水，取水之后就轮到下一个号取水，挺公平的，说明它是一种公平锁。总之，如果取水时以家庭为单位，则同一个家庭，可以直接复用排号，不用从后面排起重新取号。假定，取水时以家庭为单位，家庭的某人拿到号，其他的家庭成员过来打水，这时候不用再取号，如图。排在1号的家庭，老公取号，假设其老婆来了，直接排第一个，正所谓妻凭夫贵。故事发生在一个没有自来水的古代，在一个村子有一口井，水质非常的好，村民们都抢着取井里的水。（3）先到的排在前面，那些后到的，一个一个挨着，在井边排成一队。