1、基础知识
1.2、zookeeper集群
Zookeeper为了更好的实现生产的业务场景，一般都会采用分布式的集群架构。
Zookeeper集群通常由2n+1台Server节点组成，每个Server都知道彼此的存在。每个server都维护的内存状态镜像以及持久化存储的事务日志和快照。
对于2n+1台server，只要有>=(n+1)台server节点可用，整个Zookeeper系统保持可用。
为了维护集群内部所有主机信息的一致性，他们自己参考Paxos协议自己设计了一个更加轻量级的协议:Zab(Zookeeper Atomic Broadcast)来解决集群数据一致性的问题。
这个协议主要包括两部分：领导选举、日常通信，这两步就组成了Zookeeper的集群流程。
为了更好的理解集群流程，我们首先来学习一下Zookeeper集群的角色信息
1.3、集群角色
1.3.1、领导者(Leader)
领导者不直接接受client请求，负责进行投票发起和决议，更新系统状态
1.3.2、跟随者(Follower)
接收客户请求并向客户端返回结果，在选Leader过程中参与投票
1.3.3、观察者(Observer)
转交客户端写请求给leader节点，和同步leader状态，不参与选主投票
1.3.4、学习者(Learner)
和leader进行状态同步的节点统称Learner，Follower和Observer都是
1.3.5、客户端(client)
2、流程解析
2.1、集群流程
集群流程主要包括两阶段组成：Leader选举和日常操作。
Leader选举阶段：
Leader选举主要有两种场景：集群启动、Leader恢复。
集群启动：当Zookeeper集群启动时候，将会选择一台server节点为为Leader，其它的server节点就作为follower(暂不考虑observer)，接着就进入日常操作阶段。
Leader恢复：当集群Leader主机服务重启或者崩溃后，当Zookeeper集群中所有Server主机基于Zab协议选举新的Leader者，接着就进入日常操作阶段。然后其他Server主机和新的Leader主机进行数据
信息同步，当状态同步完成以后，就是
日常操作阶段：
日常操作阶段主要有两种场景：主机间心跳监测和数据操作。
主机间心跳监测：
当Leader选举完毕后，就进入日常操作阶段，第一步就是所有集群节点都互相保持通信，
然后Leader和Follower节点间进行数据同步，确保所有主机节点都是相同的状态，
当所有Follower节点和新的Leader主机完成数据信息同步以后，就开始进行日常的数据操作。
数据操作：
follower来接收client的请求，对于不改变系统一致性状态的读操作，
由follower的本地内存数据库直接给client返回结果；对于会改变Zookeeper系统状态的更新操作，
则转交由Leader进行提议处理，处理完毕后，将成功的结果给client。
2.2、主机状态
Zookeeper集群中每个Server主机在工作过程中有以下种状态：
Looking(迷茫者)：我老大是谁？
当前Server主机不知道集群中的Leader是谁，陷入深深的不安，正在搜寻主心骨。
Leading(领导者)：我是总统。
当前Server主机被集群选举策略确定的Leader，我的地盘我做主。
Following(执行者)：我是员工。
集群的Leader主机已经选举出来，当前Server主机与之同步信息，严格执行规章制度，保质保量完成任务。
Observing(观望者): 我是看客
observer会观察leader是否有改变，然后同步leader的状态，是系统扩展的一种方法
2.3、通信机制
对于Zookeeper集群来说，我们要考虑的内容主要有三大块：客户端连接、主机通信、选举Leader。
客户端连接： 客户端连接服务端功能，进行相关请求操作
主机通信： 集群各服务节点进行信息交流的功能
选举Leader： 集群中各服务节点共同选举主节点的功能
格式：
server.<myid>=<server_ip>:<LF_Port>:<L_Port>
为了同时满足这三者的要求，Zookeeper分别将这三种功能以三个常见端口对外提供服务：
客户端操作： 2181
主机通信： 2182
选举Leader： 2183
注意：
这三端口都是自定义的，在生产中，因为每台主机都有独立的ip，所以三个端口一般都设置一样。
