分布式锁全览

因Jedis设计，导致重试逻辑内部把通信异常吞掉了，并重新发出执行指令的请求。就会导致用户层看到 `SET` 返回的是空，但key 实际已存在*。我们找到应对的办法，只要判断出是自己加的锁。

分布式系统有一个特点，就是无论你学习积累多少知识点，只要在分布式的战线中，就总能遇到各种超出主观意识的神奇问题。

当线程正在执行wait()、sleep()、join()方法时线程是处于【waitting】状态，内部仍会不断地检查中断状态的值，interrupt方法会改变目标线程的中断状态

线程池定时任务可取消，但使用需注意 1. 任务中未捕获的异常能导致后续执行不再执行。 2. 任务中未捕获的异常不会外抛，外部感知不到。 3. 任务中的异常，需在任务逻辑内捕获并记录，否则无处可知。

scheduleAtFixedRate`的逻辑结论是：如果上一个任务的执行时间大于等待时间，任务结束后，下一个任务马上执行。如果上一个任务的执行时间小于等待时间，任务结束。

如果某个客户端获得锁之后处理时间超过最大约定时间，或者持锁期间内发生了故障导致无法主动释放锁，其持有的锁也能够被其他机制正确释放，并保证后续其它客户端也能加锁，整个处理流程继续正常执行。

虽然大佬Lamport 在论文 中早就证明了使用状态机（如共识算法）就能够去中心化解决多进程互斥问题，但我们还是会更偏向使用分布式锁。

虽然Kubernetes 给云原生时代带来了颠覆性的新气象，但却很少人了解被钦定作为其后端存储的 etcd ，本篇从分布式锁视角梳理etcd的各种机制，探索基于etcd的锁实现为何如此优雅。

如果认为Jedis实现分布式锁很简单，也就设置 Key 、删除Key，那系统迟早遇问题，面试必减分儿。坑虽然很多，但也有办法，除了锁本身的知识还有客户端的配置调优建议，有空记得来看

传统的分布式锁若归类为重用锁（A 持锁后，B 来抢锁只要没超时就一直重试抢锁，抢到就用），而这种防重入场景下的锁可理解为”一次性“锁（A 持锁后，B 来抢锁只要锁已存在，则立即放弃）。

ZK中创建和删除节点只能通过Leader执行，性能并不高；基于其高可用的特性，在并发量不是太高的场景，也可以使用ZK做分布式锁。