ZK分布式锁（未完 待续）
实现思路
公平锁：创建有序节点，判断本节点是不是序号最小的节点（第一个节点），若是，则获取锁；若不是，则监听比该节点小的那个节点的删除事件。
非公平锁：直接尝试在指定path下创建节点，创建成功，则说明该节点抢到锁了。如果创建失败，则监听锁节点的删除事件，或者sleep一段时间后再重试。
可重入：使用ThreadLocal记录加锁客户端的唯一标识。重复时先从ThreadLocal获取，获取到，这认为加锁成功，直接返回。
使用瞬时节点创建可重入公平锁
使用瞬时节点的好处是当Session失效时，该节点将被清理，从而避免使用持久节点加锁成功后，抛异常或宕机或服务器重启等原因造成的锁无法释放问题。
使用curator实现
// 假设需要加锁的订单Id
private static String orderId = "157146671409578219";
// 工程名
private static String appName = "trade_";
// 此次加锁业务处理逻辑描述
private static String operatorDesc = "updateTrade_";
// 部门，每个部门可以有自己的zk空间目录
private static String department = "zfpt" ;
// 锁前缀 应该根据业务 具有唯一性
private static String lockPrefixKey = "/" + appName + operatorDesc ;
/**
* 每个线程 创建自己的Connection ，创建自己的Session
*/
@Test
public void curator() throws Exception {
for (int i = 0 ; i < 100 ; i++) {
Thread currentThread = new Thread(() -> {
// 创建Connection
CuratorFramework client = CuratorFrameworkFactory.builder()
.connectString("master:2181,slave1:2181,slave2:2181")
.retryPolicy(new RetryOneTime(1000)) //重试策略
.namespace(department) // 可以设置自己部门缩写
.build();
client.start();
// 模拟对同一个订单加锁
InterProcessMutex lock = new InterProcessMutex(client, lockPrefixKey + orderId);
try {
// 一直尝试加锁 直到锁可用。 有点像synchronized
// lock.acquire();
if(lock.acquire(1, TimeUnit.SECONDS)) {
System.out.println(Thread.currentThread().getName() + " 抢到锁");
} else {
System.out.println(Thread.currentThread().getName() + "超时没有抢到锁");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
try {
// 如果当前线程获得到锁，则释放锁
if(lock.isAcquiredInThisProcess()) {
System.out.println(Thread.currentThread().getName() + " 释放锁");
lock.release();
} else {
System.out.println(Thread.currentThread().getName() + " 没有抢到锁,故没有释放锁");
}
} catch (Exception e) {
e.printStackTrace();
}
}
});
currentThread.setName("Lock【" + i + "】");
currentThread.start();
}
Thread.sleep(Integer.MAX_VALUE);
}
实现原理：
因为ZK不允许在临时节点下创建子节点，所以InterProcessMutex工具类会根据加锁传入path的(也就是案例中的lockPrefixKey + orderId)创建一个持久节点；然后在这个持久节点下创建瞬时节点，创建成功后，对该持久节点下的全部子节点进行降序排序，判断当前节点是否是第一个节点，如果是则获取锁，否则对前一个节点加上监听事件。然后Object.wait()，当监听事件被触发，则会调用notifyAll方法，对等待线程进行唤醒。再次尝试获取锁。
缺点：
- 传入的加锁节点会被创建为永久节点(就是lockPrefixKey + orderId)，这样zk节点数量将会急速递增。
- 临时节点不稳定：一个客户端加锁成功后，可能会因为网络抖动等原因导致Session断开，该客户端创建的临时节点被清理，导致另外一节正在监听的客户端加锁成功，同时进行操作。
使用持久节点创建可重入公平锁
上文提到的临时节点不稳定，父节点为永久节点无法释放问题。我的拙见是：
- 使用持久节点代替临时节点：释放锁的时候删除自己创建的加锁节点。
- 父节点为永久节点无法释放：可以在每个客户端释放锁的时候进行判断，如果自己是最后一个节点，则删除父节点。
- 但是需要考虑的问题：客户端加锁成功后，宕机或重启或者其他极端异常情况，无法删除加锁节点。最后一个加锁节点同样异常，也无法删除父节点。这时，可以给每个锁加过期时间，过期失效。由于zk没有提供过期自动清理，所以可以在第二次访问该节点的时候 先进行判断，判断失效先删除再创建。如果没有第二次访问的节点 可以依靠定时任务进行节点清理。
加油
