Java之分布式锁的5种实现过程
作者：右手嘚温暖
1、分布式锁的基本概念
分布式锁是在分布式系统环境下，控制多个进程/服务/主机互斥访问共享资源的核心协调机制。
它解决了单机锁（如Java的synchronized、ReentrantLock）在分布式场景下失效的问题，是构建可靠分布式应用的必备工具。
解决我们在多个jvm中最终只能有一个jvm执行，从而保证了幂等性的问题。
2、业务超时，一直不释放锁如何处理？
可以采用续命设计，续命多次，如果业务还是没有执行完毕，则认为超时，应该主动释放该锁，防止其他jvm一直阻塞等待。
- （1）主动释放锁；
- （2）回滚当前业务逻辑；
- （3）主动停止该线程；
- （4）移除监听。
3、集群环境中保证定时任务执行的幂等性问题
幂等性：
- 执行结果保证唯一不能够重复。
- 当我们定时任务服务集群的情况下，有可能会同时重复执行定时任务
解决思路：
- 多个jvm集群的定时任务，在触发的时候，获取分布式锁，
- 如果能够获取到分布式锁的jvm，就能够执行定时任务，没有获取到的就不能执行定时任务。
4、基于zookeeper实现分布式锁
（1）实现分布式锁思路：
因为Zookeeper节点路径保持唯一，不允许重复，且有临时节点特性，连接关闭后当前节点会自动消失，从而实现分布式锁。
（2）实现原理：（临时节点+事件通知）
- 多个jvm请求同时创建相同的临时节点（lockPath），只要谁能够创建成功谁就能够获取到锁；
- 如果创建节点的时候，突然该节点已经被其他请求创建的话则直接等待；
- 只要能够创建节点成功，则开始进入到正常业务逻辑操作，其他没有获取到锁的jvm进行等待；
- 正常业务逻辑流程执行完后，调用zk关闭连接方式释放锁，从而使其他的请求开始进入到获取锁的资源。
疑问：如果使用zk实现分布式锁，获取锁之后业务逻辑方法一直没有执行完毕，导致其他所有的请求等待的话如何解决？
设置Session连接超时时间，在规定的时间内获取锁后超时啦~自动回滚当前数据库业务逻辑。
5、基于数据库实现分布式锁
（1）悲观锁
- 就是先select…forupdate锁住主键key_resource那个记录，如果为空，则可以插入一条记录，如果已有记录判断下状态和时间，是否已经超时。
- 这里需要注意一下哈，必须要加事务哈。
（2）搞个version字段
- 每次更新修改，都会自增加一，然后去更新余额时，把查出来的那个版本号，带上条件去更新，
- 如果是上次那个版本号，就更新，如果不是，表示别人并发修改过了，就继续重试。）
6、基于redis实现分布式锁
（1）采用Setnx
Redis中SetnX与Set命令的区别
- Setnx可以返回该key是否存在，存在返回0，不存在返回1，如果该key存在的情况下，是不能做修改的。
- Set每次直接覆盖该key对应的value。
获取锁的原理：
- 多个redis客户端执行setNx命令，设置一个相同的redis的key，谁能创建key成功，谁就能获取锁，
- 如果该key已经存在的情况下，则再创建的时候会返回false。
释放锁的原理：
- 删除该key。
7、基于redisson实现分布式锁
多个jvm同时在redis中写入一个相同的key，谁能够写入成功，谁就能获取到锁。
（1）向redis中写入key的时候使用lua脚本，不是setNx;
（2）如果写入key成功，会单独开启一个看门狗线程（续命定时任务线程），默认的情况下每隔10s时间不断续命延迟。
（3）一直不断实现续命的情况下，也会发生死锁问题，此时设定续命的次数，续命多次如果业务逻辑还没有执行完毕，主动回滚当前的mysql事务，并释放该锁。
8、基于Curator实现分布式锁（解决羊群效应问题）
核心思想：
（1）从缓存中查找是否已经创建分布式锁，如果已经创建了分布式锁，则直接复用（具有可重入性）。
（2）如果缓存中没有，则创建一个分布式锁。
（3）实现原理：创建一个临时节点，获取当前父节点下的子节点，如果是为最小的节点，则表示获取锁成功，否则获取锁失败，阻塞等待，则监听上一个节点。
（4）当上一个节点如果释放锁之后，直接进入到获取锁的状态，唤醒使用waitnotify技术。
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。