像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台，不仅成本低也有良好的性能表现。
