今天给大家分享一下，zookeeper的简单使用。

1.背景介绍

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，由Client和Server构成，Server提供了一致性复制和存储服务，Client包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。
它是集群的管理者，采用树形的数据结构，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

2.知识剖析

server角色

1)leader：领导者，可以接受client请求，也接收其他server转发的写请求，负责更新系统状态。 
2)follower：可以接收client请求，如果是写请求将转发给leader来更新系统状态。
3)observer：同follower，唯一区别就是不参与选主过程。    

广播机制

Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。

session机制

client连接server成功后，server赋予该client一个sessionid，client需要不断发送心跳维持session有效，在session有效期内，可以使用Zookeeper提供的API进行操作。如果因为某些原因导致client无法正常发送心跳，在超时时长后，server会判断该client的session失效，此时client发送的任何操作都会被拒绝，并触发ExpiredException异常，此时KeeperState处于Expired状态.但client有自动重连server的机制，如果client的心跳无法正常连接server，会在session超时前尝试连接其他server，连接成功后可以继续操作。 

一致性

1)假设有2n+1个server，在同步流程中，leader向follower同步数据，当同步完成的follower数量大于 n+1时同步流程结束，系统可接受client的连接请求。如果client连接的并非同步完成的follower，那么得到的并非最新数据，但可以保证单调性。 
2)follower接收写请求后，转发给leader处理；leader完成两阶段提交的机制。向所有server发起提案，当提案获得超过半数（n+1）的server认同后，将对整个集群进行同步，超过半数（n+1）的server同步完成后，该写请求完成。如果client连接的并非同步完成的follower，那么得到的并非最新数据，但可以保证单调性。

Watch机制

1)ZooKeeper支持一种Watch操作，Client可以在某个ZNode上设置一个Watcher，来Watch该ZNode上的变化。如果该ZNode上有相应的变化，就会触发这个Watcher，把相应的事件通知给设置Watcher的Client。 
2)ZooKeeper中的Watcher是一次性的，即触发一次就会被取消，如果想继续Watch的话，需要客户端重新设置Watcher。

3.常见问题

1)zookeeper负载均衡实现原理
2)zookeeper伪集群具体配置及实现

4.编码实战

5.扩展思考

Zookeeper设计目的

1)一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。
2)可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。
3)实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据。

4)等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
5)原子性：更新只能成功或者失败，没有中间状态。
6)顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

异步Watcher处理

zookeeper的watcher实现原理也挺简单的，就是在zookeeper client和zookeeper server上都保存一份对应的watcher对象。每个zookeeper机器都会有一份完整的node tree数据和watcher数据，每次leader通知follower/observer数据发生变更后，每个zookeeper server会根据自己节点中的watcher事件推送给响应的zookeeper client，每个zk client收到后再根据内存中的watcher引用，进行回调.

1)Zookeeper选主流程是怎么样的？

服务器启动时选举：每个Server发出一个投票，接受来自各个服务器的投票，处理投票，统计投票，改变服务器状态。

服务器运行期间：比上边，开头，多了一个环节，改变服务器状态。

2)SpringCloud Eureka和zookeeper的区别

Eureka遵循AP原则，zookeeper遵循cp原则，C：一致性，A：可用性，P：分区容错性

3)是否每次节点变化的通知都能收到？原因？

如果节点数据的更新频率很高的话，不能。原因在于：当一次数据修改，通知客户端，客户端再次注册watch，在这个过程中，可能数据已经发生了许多次数据修改，因此，千万不要做这样的测试：”数据被修改了n次，一定会收到n次通知”来测试server是否正常工作。