当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，而且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。
在云部署环境下， 因为网络问题使得zk集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。
zookeeper
- 分布式协调 追求强一致 A系统通知B系统处理结果 负载均衡；
- 分布式锁
- 元数据/配置信息管理
- HA高可用性
为分布式应用提供一致性服务的软件，包括：配置维护、域名服务、分布式同步、组服务等。
zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。
特点：高性能可扩展，读写速度快，客户端的更新顺序与它们被发送的顺序相一致，原子性，高可用性 & 可恢复性。
测试环境可以用单个zookeeper服务器，但是不能保证高可用性 & 可恢复性。
高可用性：可以通过复制，ZooKeeper它所做的就是确保对Znode树的每一个修改都会被复制到集合体中超过半数的机器上。超过半数-所有服务器数一般取奇数。
zookeeper 存在leader,follower,observer三种角色,这三种角色在实际服务集群中都是服务节点。
leader:处理所有请求，为客户的提供读和写服务
follower:只提供读服务，有机会通过选举成为leader
observer:只提供读服务
Paxos算法就是通过投票、全局编号机制。
原理
核心是原子广播机制，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。
(1) 恢复模式
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。
(2) 广播模式（有点类似两段式提交事务）
一旦Leader已经和多数的Follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个Server加入ZooKeeper服务中，它会在恢复模式下启动，发现Leader，并和Leader进行状态同步。待到同步结束，它也参与消息广播。ZooKeeper服务一直维持在Broadcast状态，直到Leader崩溃了或者Leader失去了大部分的Followers支持。
分布式锁
（1）创建一个目录mylock；
（2）线程A想获取锁就在mylock目录下创建临时顺序节点；
（3）获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁；
（4）线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；
（5）线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。
Nacos
致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。
sh startup.sh -m standalone
http://localhost:8848/nacos/index.html页面，输入账号密码：默认账号：nacos 默然密码：nacos