分布式锁

1.互斥
2.不会死锁。
3.同个线程加锁解锁。

https://www.hollischuang.com/archives/1716
https://www.cnblogs.com/garfieldcgf/p/6380816.html

---

1.基于数据库实现。
方式一：lock方法在数据库表中插入一条记录。记录中加一个字段叫方法名，方法名作为唯一键。unlock方法释放锁。当另一个线程过来获取锁的时候，首先查询数据库是否有该方法的记录，如果没有，则获取锁。如果已有该方法，则获取锁失败。
缺点：
1.数据库单点，强依赖于数据库的可用性。
2.锁没有过期时间。某个线程释放锁失败了，其他线程无法获取到锁。
3.锁无法可重入。
4.获取锁是非阻塞的。

解决方式：
1.数据库集群。主从同步。
2.在每行记录中增加锁的过期时间。定时任务定期清理过期的锁。
3.每行记录中增加当前持有锁的机器id和线程信息，或者生成uuid保存在threadLocal中。
4.没获取到锁的线程一直重试，中间间隔一段时间。

方式二：基于数据库的排它锁。
在lock方法中开启事务，connect.setAutoCommit(false)。 执行语句 select lockName from table for update 。给该条记录加上排它锁，在unlock时connect.commit()。这样其他线程尝试加锁时，会一直等待排它锁的释放。lockName字段一定要加上索引，不然当前读加锁是没走索引，行锁将会升级成表锁，影响其他锁的获取。另外，如果数据库数据量太少，mysql会优化查询语句，直接锁表，比一定会走行锁。
解决的问题：
1.服务宕机之后，会自动释放锁。
2.没获取到锁的线程会自动阻塞。
缺点：
1.当获取到锁的线程占有较长时间时，数据库连接过多，会撑爆数据库连接池。
2.实现复杂。数据库不一定会走行锁。

---

2.基于缓存实现。
方式一：
加锁：redis.setNx(key,requestId) 缺点：无过期时间
加锁： redis.setNx(key,expireTime) 缺点：无加锁线程标识，任何线程都可以解锁
加锁 ：redis.setNx(key,requestId),redis.setExpire(key,expireTime) 不是原子操作，可能加锁锁之后，还未到设置过期时间，程序就崩溃了。
解锁：if(redis.get(key)==requestId){ redis.del(key)} 缺点：非原子操作，可能在判断了是该线程之后未释放锁之前，锁已经被别的线程占有了。

方式二：
加锁：redis.set(key,requestId,SET_IF_NOT_EXIT,EXPIRE,expireTime)
解锁：
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));
return RELEASE_SUCCESS.equals(result)) ;

---

3.基于zk实现。
利用zk的有序节点来实现。在加锁的时候，在方法对应的节点底下生成一个临时有序节点，判断是否获取到锁，只需要判断该节点的值是否是最小的。释放锁是，删除该节点。
1.死锁？当某个线程断开链接时，zk会自动删除该节点。
2.非阻塞锁？客户端在创建节点时，可以在节点上绑定监听器，当节点发生变化时，zk会通知客户端，客户端在判断自己创建的节点是否是所有节点中序号最小的，如果最小则获取锁。
3.不可重入？客户端在创建节点时，将机器信息和线程信息写入节点，再次获取锁时，判断所有节点中序号最小的节点的信息是否与当前信息一致，如果一致则直接获得锁。