参考视频教程: **DevOps理论+实践之路 **
- Zookeeper 非公平锁/公平锁/共享锁 =========================
1.1 非公平锁
如下实现方式在并发问题比较严重的情况下，性能会下降的比较厉害，主要原因是，所有的连接 都在对同一个节点进行监听，当服务器检测到删除事件时，要通知所有的连接，所有的连接同时 收到事件，再次并发竞争，这就是羊群效应。
非公平锁
1.2 公平锁
如下借助于临时顺序节点，可以避免同时多个节点的并发竞争锁，缓解了服务端压力。这种实现方式所有加锁请求都进行排队加锁，是公平锁的具体实现。
- 请求进来，直接在/lock节点下创建一个临时顺序节点
- 判断自己是不是lock节点下，最小的节点
- 是最小的，获得锁
- 不是。对前面的节点进行监听(watch)
- 获得锁的请求，处理完释放锁，即delete节点，然后后继第一个节点将收到通知，重复第二步判断。
公平锁
1.3 共享锁
前面这两种加锁方式有一个共同的特质，就是都是互斥锁，同一时间只能有一个请求占用，如果 是大量的并发上来，性能是会急剧下降的，所有的请求都得加锁，那是不是真的所有的请求都需要加锁呢？答案是否定的，比如如果数据没有进行任何修改的话，是不需要加锁的，但是如果读数据的请求还没读完，这个时候来了一个写请求，怎么办呢？有人已经在读数据了，这个时候是不能写数据的，不然数据就不正确了。直到前面读锁全部释放掉以后，写请求才能执行，所以需要给这个读请求加一个标识（读锁），让写请求知道，这个时候是不能修改数据的。不然数据就不一致了。如果已经有人在写数据了，再来一个请求写数据，也是不允许的，这样也会导致数据的不一致，所以所有的写请求，都需要加一个写锁，是为了避免同时对共享数据进行写操作。
共享锁实现原理:
共享锁
具体锁的实现，请参考
- 注册中心 =======
简单来讲，zookeeper可以充当一个服务注册表（Service Registry），让多个服务提供者形成一个集群，让服务消费者通过服务注册表获取具体的服务访问地址（ip+端口）去访问具体的服务提供者。
Zookeeper的设计理念是为了保持数据的强一致性，满足的是CP。
