zookeeper从设计模式角度来理解，是一个基于观察者模式设计的分布式服务管理框架。它负责存储和管理大家关心的数据，然后接受观察者的注册，一旦这些数据发生变化，zookeeper就将负责通知已经在zookeeper上注册的那些观察者做出相应的反应。


zookeeper:一个领导者（leader）,多个跟随者（follower）组成的集群。

集群中只有半数以上节点，zookeeper就能正常服务。

全局数据一致。每个Server保存一份相同的数据副本，client 无论连接到哪个server，数据都是一致的。

更新请求顺序执行，来自同一个client的更新请求按其发送顺序依次执行。

数据更新原子性，一次数据要更新要么成功，要么失败。

实时性，在一定范围内，client能读到最新数据。

统一命名服务：

在分布式环境下，经常需要对应用/服务进行统一命名，便于标识。

例如：IP不容易记住，而域名容易记住。

统一配置管理：

分布式环境下，配置文件同步非常常见。

一般要求一个集群中，所有节点的配置信息是一致的，比如kafka集群。

对配置文件修改后，希望能够快速同步到各个节点上。

配置管理可交由zookeeper实现：

可将配置信息写入zookeeper上的一个zonde

各个客户端服务器监听这个znode.

一旦znode中的数据被修改，zookeeper将通知各个客户端服务器。

统一集群管理

分布式环境中，实时掌握各个节点的状态是必要的。

可根据节点实时状态做出一些调整。

zookeeper 可以实现实时监控节点的变化。

可将节点信息写入zookeeper上的一个zonde

监听这个zonde可获取它的实时状态变化。

客户端能实时洞察服务器上下线的变化。

zookeeper选举机制--第一次启动

SID：服务器id，用来标识一台zookeeper集群中的机器，每台机器不能重复，和myid一致。

zxid：事务ID.zxid是一个事务id,用来标识一次服务器状态的变更。在某一个时刻，集群中的每台机器的zxid不定完全一致，这和zookeeper服务器对于客户端更新请求的处理逻辑有关。

epoch:每个leader任期的代号:没有leader时同一轮投票过程中逻辑是相同的，每投完一次票这个数据就会增加。

（1）服务器1启动，发起一次选举，服务器1投自已一票，此时服务1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为looking.

(2)服务器2启动，再发起一次选举，服务器1和2分别投自已一票并交换选票信息，此时服务器1发现服务器2的myid比自已目前投票推荐服务器1大，更改选票为推举服务器2，此时服务器票数0票，服务器2票数为2票，没有半数以下结果，选举无法完成，服务器1，2保持looking,

（3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服

务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；

（4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为 1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；

（5）服务器5启动，同4一样当小弟。