【一、Zookeeper中的角色】
①领导者（leader）Leader服务器为客户端提供读写服务。它是集群工作机制的核心，事务请求唯一调度者和处理者，保证集群事务请求处理的顺序性。
②学习者（learner），学习者又分为跟随者和观察者：
跟随者（follower）Follower服务器为客户端提供读服务，参与Leader选举过程，参与写操作“过半写成功”策略。处理非事务请求，转发事务请求给领导者，同时参与投票。
观察者（observer）Observer服务器为客户端提供读服务，不参与Leader选举过程，不参与写操作“过半写成功”策略。用于在不影响写性能的前提下提升集群的读性能。该服务不参与投票，可有可无的。
③客户端（client）服务请求发起方。
【二、Zookeeper选举】
上面提到的服务器角色是怎么产生的呢，就是通过选举。
我这里，以一个例子的来形象说明选举的过程：
1、咱们现在有10台服务器，刚刚上线的服务器没有任何数据，崭新的。咱们给它编个号：1,2,3,4,5,6,7,8,9,10，咱们呢把这10个服务器逐个都开机了哈。
2、在服务器启动的时候啊，选举就开始了。1号服务器启动，先给自己投票，然后把自己的信息发出去，让别的也投。但是呢其他服务器还没有启动啊，于是1号服务器就收不到反馈。心情很是失落，像笔者那年一样，此时1号服务器就开始处于选举状态了（Looking左顾右盼的，焦急等待）。
3、接着2号服务器终于启动了，它也给自己投票，但是2号服务器收到了1号服务器的反馈。2号服务器暂时胜出，票数还没有大于半数，2号也得处于选举状态。
4、同理哈，3号启动，4号启动，5号启动，一直到6号。6号就不同了，它给自己先投了一票，然后收到了1,2,3,4,5的投票，6票超过半数，他就是领导者。同时也先入为主了，后续7,8,9,10号无论票数怎样，都不管了。
【三、Zookeeper各种角色作用】
1、Zookeeper中的请求
事务请求：
改变服务器状态的请求。
非事务请求：
仅仅读取数据，不修改数据的请求
2、领导者Leader
领导者会根据不同的请求，进行不同的处理。
3、跟随者Follower
①向领导者发送请求；
②接收领导者的消息并处理；
③接收客户端请求，如果是写入则需要发送给领导者进行半数投票；
④返回请求结果给客户端。
4、观察者Observer
除了不参与Leader选举和Proposal投票外，与Follower的作用相同。
【四、Zookeeper中的Zab协议】
①客户端所有的写入请求，都要转发给服务中唯一的领导者Leader，然后领导者Leader根据请求发起一个Proposal请求；
②其他的跟随服务，对该Proposal请求进行投票，看自己是否支持这个请求；
③领导者Leader对投票进行收集，票数过半时，领导者Leader会向所有的服务发送一个通知。
④客户端所连接的那个服务器收到消息，执行操作并作出对客户端的回应。
【五、Zookeeper节点】
Zookeeper有四种常用节点：
①持久：PERSISTENT，【持久化节点】；
②PERSISTENT_SEQUENTIAL，顺序自动编号【持久化节点】，这种节点会根据当前已存在的节点数自动加 1
③EPHEMERAL，【临时节点】， 客户端session超时这类节点就会被自动删除
④EPHEMERAL_SEQUENTIAL，【临时节点】临时自动编号节点。
然后这四种节点还可以分呢！
按照持久化
持久：PERSISTENT、PERSISTENT_SEQUENTIAL
临时：EPHEMERAL、EPHEMERAL_SEQUENTIAL
还可以按照类型，分呢！
目录节点：PERSISTENT、EPHEMERAL
编号目录节点：PERSISTENT_SEQUENTIAL、EPHEMERAL_SEQUENTIAL