1.1 zookeeper 是什么？
–ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务
1.2 ZooKeeper能干什么哪？
–ZooKeeper是用来保证数据在集群间的事务性一致
1.3 •zookeeper 应用场景
–集群分布式锁
–集群统一命名服务
–分布式协调服务
1.4 zookeeper 角色与特性
–Leader：
–接受所有Follower的提案请求并统一协调发起提案的投票，负责不所有的Follower迚行内部的数据交换
–Follower：
–直接为客户端服务并参不提案的投票，同时与Leader进行数据交换
–Observer：
–直接为客户端服务但并不参与提案的投票，同时也与Leader进行数据交换
1.5zookeeper 角色与选举
–服务在启动的时候是没有角色的（LOOKING）
–角色是通过选举产生的
–选举产生一个leader，剩下的是follower
–选举leader 原则：
–集群中超过半数机器投票选择leader.
–假如集群中拥有n台服务器，那么leader必须得到n/2+1台服务器投票
–如果leader 死亡，从新选举leader
–如果死亡的机器数量达到一半，集群挂起
–如果无法得到足够的投票数量，就重新发起投票，如果参不投票的机器不足n/2+1 集群停止工作
–如果follower 死亡过多，剩余机器不足n/2+1 集群也会停止工作
–observer 不计算在投票总设备数量里面
1.6 zookeeper 可伸缩扩展性原理与设计
–leader 所有写相关操作
–follower 读操作与响应leader提议
–在Observer出现以前，ZooKeeper的伸缩性由Follower来实现，我们可以通过添加Follower节点的数量来保证ZooKeeper服务的读性能。但是随着Follower节点数量的增加，ZooKeeper服务的写性能受到了影响。为什么会出现这种情况？在此，我们需要首先了解一下这个"ZK服务"是如何工作的。
–客户端提交一个请求，若是读请求，则由每台Server的本地副本数据库直接响应。若是写请求，需要通过一致性协议（Zab）来处理
–Zab协议规定：来自Client的所有写请求，都要转发给ZK服务中唯一的Leader，由Leader根据该请求发起一个Proposal。然后，其他的Server对该Proposal迚行Vote。之后，Leader对Vote迚行收集，当Vote数量过半时Leader会吐所有的Server发送一个通知消息。最后，当Client所连接的Server收到该消息时，会把该操作更新到内存中并对Client的写请求做出回应
–ZooKeeper服务器在上述协议中实际扮演了两个职能。它们一方面从客户端接受连接不操作请求，另一方面对操作结果迚行投票。这两个职能在ZooKeeper集群扩展的时候彼此制约
–从Zab协议对写请求的处理过程中我们可以发现，增加follower的数量，则增加了对协议中投票过程的压力。因为Leader节点必须等待集群中过半Server响应投票，于是节点的增加使得部分计算机运行较慢，从而拖慢整个投票过程的可能性也随之提高，随着集群变大，写操作也会随之下降
–所以，我们不得不，在增加Client数量的期望和我们希望保持较好吞吏性能的期望间进行权衡。要打破这一耦合关系，我们引入了不参与投票的服务器，称为Observer。Observer可以接受客户端的连接，并将写请求转发给Leader节点。但是，Leader节点不会要求Observer参加投票。相反，Observer不参与投票过程，仅仅在上述第3歩那样，和其他服务节点一起得到投票结果
–Observer的扩展，给ZooKeeper的可伸缩性带来了全新的景象。我们现在可以加入很多Observer 节点，而无须担心严重影响写吞吐量。但他并非是无懈可击的，因为协议中的通知阶段，仍然不服务器的数量呈线性关系。但是，这里的串行开销非常低。因此，我们可以认为在通知服务器阶段的开销丌会成为瓶颈
–Observer提升读性能的可伸缩性
–Observer提供了广域网能力