像Mysql的主从模式会分master主节点和slave从节点一样，在zookeeper集群中，节点也有不同的角色，承担着不同角色。

zookeeper有三种角色：老大Leader(领导者）   2、老二Follower （跟随者） 3、老三Observer（观察者）。其中，Follower和Observer归类为Learner（学习者）

按重要性排序是Leader > Follower > Observer

老大领导者Leader。

Leader在集群中只有一个节点，可以说是老大No.1，是zookeeper集群的中心，负责协调集群中的其他节点。从性能的角度考虑，leader可以选择不接受客户端的连接。

主要作用有：

1、发起与提交写请求。

所有的跟随者Follower与观察者Observer节点的写请求都会转交给领导者Leader执行。Leader接受到一个写请求后，首先会发送给所有的Follower，统计Follower写入成功的数量。当有超过半数的Follower写入成功后，Leader就会认为这个写请求提交成功，通知所有的Follower commit这个写操作，保证事后哪怕是集群崩溃恢复或者重启，这个写操作也不会丢失。

2、与learner保持心跳

3、崩溃恢复时负责恢复数据以及同步数据到Learner

 

老二跟随者Follower。

Follow在集群中有多个，主要的作用有：

1、与老大Leader保持心跳连接

2、当Leader挂了的时候，经过投票后成为新的leader。leader的重新选举是由老二Follower们内部投票决定的。

3、向leader发送消息与请求

4、处理leader发来的消息与请求

 

老三观察者Observer

可以说Observer是zookeeper集群中最边缘的存在。Observer的主要作用是提高zookeeper集群的读性能。通过leader的介绍我们知道zookeeper的一个写操作是要经过半数以上的Follower确认才能够写成功的。那么当zookeeper集群中的节点越多时，zookeeper的写性能就 越差。为了在提高zookeeper读性能（也就是支持更多的客户端连接）的同时又不影响zookeeper的写性能，zookeeper集群多了一个儿子Observer，只负责：

1、与leader同步数据

2、不参与leader选举，没有投票权。也不参与写操作的提议过程。

3、数据没有事务化到硬盘。即Observer只会把数据加载到内存。

 

下图是zookeeper官方文档中不同节点的zookeeper集群的性能表现（节点角色只有leader和follower）：

竖轴是每秒请求量，横轴是读请求的占比，不同颜色的曲线代表了不同数量的zookeeper节点，分别是3个节点，5个节点，7个节点，9个节点，13个节点。

可以看到，随着读请求所占的比例越来越多，zookeeper所能处理的请求数量是指数级得提升。除了三个节点的zookeeper集群外，当读请求占比达到100%时，从曲线上看其他数量的集群能够处理的请求几乎无穷大。

当读请求达到80%时，由于follower数量的增大导致写请求的耗时增长，节点数量越多的zookeeper吞吐量越小（三个节点的集群是个例外）。吞吐量排序是：5>7>3>9>13。

正常情况下所有的请求都是读请求是不可能的，肯定含有写请求。所以建议zookeeper集群的读写比例为7:3或8:2最好，机器数量为5或者7台，不仅成本低也有良好的性能表现。