一、首先要知道zookeeper是什么？
zookeeper是一个开源的分布式应用程序协调服务，它能够保证数据在集群间的事务一致性，通俗点说就是保持集群间的数据同步。
二、zookeeper的应用场景
集群分布式锁
集群统一命令服务
分布式协调服务
三、zookeeper角色
角色与特性
Leader：接受所有Follower的提案请求并且统一协调发起提案的投票，负责所有的Follower内部数据的交换。
Follower：直接为客户端服务并参与提案的投票，同时也与Leader进行数据交换。
Observer：直接为客户端服务但不参与提案的投票，同时也与Leader进行数据交换。
角色与选举
当zookeeper服务启动时是没有角色的，是处于LOOKING状态，此时角色的产生是通过集群的选举产生的，只选出一个Leader，其余的都是Follower。
选举原则：
1.集群中超过半数的机器投票选择Leader
2.如果集群中有n台服务器，那么Leader必须得到（n/2+1）台服务器的投票。当一次选举出现票数不够的情况下，会重新选举，直到选出满足原则的Leader后，选举结束。
zookeeper的高可用
当集群中的Leader死亡（宕机或者停止服务），此时zookeeper就会自动重新选举，选举原则如上所示一样。需要注意的是Observer不参与投票。
什么情况下集群完全停止工作呢？
1.当死亡的机器达到一半。
2.当投票的数量不够（n/2+1）。
3.Follower死亡过多，满足不了机器的n/2+1。
可伸缩扩展性
Leader是与写操作相关
Follower是读操作以及响应Leader的提议
Observer出现以前，zookeeper的伸缩性是由Follower来实现，通过添加Follower的节点数量保证zookeeper的读性能，但是Follower的节点数量增加的同时，zookeeper服务的写性能也会受到影响。
写请求的处理过程
第一步，客户端发送写请求到本地的服务器。
第二步，由本地服务器发送请求到Leader，重新发送给集群中的所有服务器进行投票。
第三步，Leader收集选票，并将结果通知服务器。
第四步，服务器将操作结果发送给客户端。
当客户端提交一个请求的时候，如果是读请求，那么每台server的本地副本数据库直接响应。如果是写请求，需用通过一致性协议zab来处理，处理过程如上描述所示。
zab协议
当Leader收到一个写请求时就会发起一个提案进行投票，然后其他的server会对该提案进行投票。之后Leader收集投票的结果，当投票数量过半时Leader会向所有的server发送一个通知消息。最后当client所连接的server收到消息时，会把该操作更新并对client写请求做出回应。
写性能瓶颈
zookeeper在zab协议中实际有两个职能。一方面，从客户端接受连接与操作请求。另一方面，对操作结果进行投票。这两个方面在集群扩展的时候会相互的制约。
可以从zab协议对写请求的处理过程中可以发现，增加Follower的数量，即增加了协议投票过程的压力。因为Leader节点必须等待集群过半的Server响应投票，节点的增加就使得部分计算机运行比较慢，从而拖慢整个投票过程的可能性也随着会增高，集群越来越庞大，写操作也会随之下降。为了解决这个问题，引入了Observer角色。
Observer角色
为了在增加集群规模和保持较好吞吐性能之间进行权衡，打破这个耦合的关系，引进了不参与投票的服务器Observer。Observer可以接受Client的连接，并将写请求发给Leader节点，但是Leader节点不会要求Observer参加投票，仅仅在写请求处理过程中的第三步那样，与其他服务节点一起得到投票结果。
总结为一句话，Observer参与操作，不参与投票，相当于一个中转站。
Observer的优势是十分明显的，给zookeeper的可伸缩性带来了不一样的景象。加入Observer节点不用担心严重影响写操作的吞吐量。它不仅仅是这样，而且还提供了广域网的能力。
Observer也不是完美的，协议里面的通知阶段任然是与服务器数量呈线性关系。但是由于串行的开销非常低，因此在通知服务器的阶段，这里不会成为瓶颈。
以上就是我对zookeeper的一个初步的认识，记录下来方便学习，如果有不同的意见可以提出一起探讨！