分布式锁演进过程

分布式锁从普通的redis锁到redission框架

对照着上图一段简单的业务代码来讲解，一开始执行过程中碰到业务代码挂了，造成了死锁的情况，这时候用try/catch的finally里面放del（lock）能解决一部分问题但前提是JVM还运行着但是发生某种异常请。但是要是整个JVM都挂了呢？
要是JVM整个挂掉（比如被运维kill了进程），这时候就要给锁设置超时时间，超过一定时间要自己释放，这里面要保证setnx和设置超时代码的原子性，可以用jediss把两个逻辑写一起。
这里面还存在一个雷就是比如你把超时时间设置为10秒，但有些业务真的会过了这个时间还没执行完。这时候就会产生新的问题，因为过了超时时间这把锁已经释放了，这时候代码逻辑在执行删除锁那句之前，这时候进来一个新的线程，会被删除锁代码把锁释放掉，（也就是说线程2会把线程3的锁删除掉）在高并发下这种情况会多次发生，这就意味着这把锁等于没写。
要解决这个问题，先搞清楚这个问题的本质，这个问题的本质是本线程加的锁被别的线程释放，那思路就是本线程加的锁只有本身能释放就可以了，解决方案是定义一个clientId变量，把这个变量设置为锁的value，然后在删除锁的时候判断获得的锁的value等不等于这个clientId变量，只有是相同才能判定是同一线程，这时侯才执行删除锁的，这样就解决了锁错释放的问题。代码见下图

随后发现这里还是有问题，超时情况导致错误的问题还是没解决，因为线程1业务代码走到一半超时了然后锁就释放了，这时候新进来的线程还是会拿到这把锁，这时候整个JVM里面有两个线程在执行这段业务逻辑，这就破坏了分布式原子性的原则。这时候就引出一个比较完善的框架就是redisson框架（比较完美地解决了上述问题，并且使用方便，但是不是百分百的解决），使用redisson框架代码见下图

redission框架简介

redission框架原理图

Redission框架使用时存在的问题

主从切换时这把锁还没同步到从节点，主节点就挂掉了，再选举产生新的主节点时就丢失了这把锁，这时候就又破坏了原子性。这时候就可以用ZK解决，因为ZK集群的原理。
客户端发一个消息到服务端（create node也就是创建锁数据），zookeeper不是马上给客户端返回ok，zk内部两阶段提交消息操作后才返回给客户端。第一阶段，先预提交也就是说不先写到zk磁盘，先写到日志文件，然后转发给其他follower让其他follower也写到他们的日志文件中去，这个阶段其他线程是看不到leader里面的这个数据的（因为还未最终提交）。写完日志文件的follower会发送ack给leader，当leader收到半数以上的follower的确认消息后才commit，真正的提交数据。commit之后其他的线程才能看到这个数据。最后把commit数据同步给其他follower。参考下图加深理解