4) zookeeper分布式锁架构
基本步骤：
a.每个服务器多次从客户端create(在/root 临时有序节点);
b.getChilder("/root")获取所有子节点;
c.如果获取到的子节点是所有节点中序号最小的，那么认为这个客户端获取了锁;
d.否则，监听比自己节点小的节点中最大的节点，等待该子节点watch机制，然后在进行cd判断逻辑;
a.对比redis分布式锁
redis分布式锁实现步骤:
a.根据key值去setnx(if key存在，不操作返回0，反之，setkey值成功，返回1)，返回1获得锁成功，end；
b.如果没有获取到锁，getkey对应的value(存储的是时间戳),为了避免死锁，网往会给超时时间，如果返回是0，接着比较时间戳是否超过当前设置超时时间，如果没超过获取锁失败,如果超过获取锁成功，并重新set当前value(时间戳);
c.然后会存在setnx失败，get为空，则说明在这之间已经释放锁，然后反复去执行一次（senx get）;
b.优缺点
并发不是很常见的话，使用redis比较好，一次就成功，但是并发多的话，redis会一直去尝试获取锁，性能损耗大;而zookeeper有watch机制，只需添加一个监听器；还有就是连接redis的客户端如果程序出问题，导致没有及时释放锁，那么只能等待超时时间，而zookeeper客户端挂了，临时znode就没了，相当于释放了锁；
个人觉得zookeeper分布式锁比较好，但是我实际项目中没用过，基本使用redisson,非常简单好用,api封装很强大,都能满足项目场景。