- Zookeeper的选举过程
zookeeper的选举机制其实就是zab(原子广播)的恢复机制
选举有两种, 一种是basic paxos算法,一种是fast paxos算法
默认的半数选举机制是fast paxos算法,当有一半以上的节点选举时, 这个节点就是leader.
假如有五台节点组成的集群, 当第一台节点启动时, 他把票投给自己, 但是它发出去的报文没响应,所以它的状态是looking, 当第二台节点启动, 他们都各自把票投给自己, 这是第二台的myid 大,他的权重大, 第一台节点改票为第二台, 但是第二台的票数未过半, 所以两台都为looking状态. 第三台启动, 他们同样的选举, 最后第三台myid大,胜出,且票数过半, 当选为leader 一二台为follower. 第四台启动, 由于已经选出来了leader了, 所以第四台也只能是follower.
- Zookeeper的角色
zk提供了什么，简单的说，zookeeper=文件系统+通知机制
1、领导者（leader），负责进行投票的发起和决议，更新系统状态
2、学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票
3、Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
4、客户端（client），请求发起方
- Zookeeper的核心
核心原理（ZAB协议）
Zookeeper的核心是原子广播（Zookeeper Atomic Broadcast），这个机制保证了各个Server之间的同步。实现这个机制的协议叫做ZAB协议。
- Zab原理
Zab协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。
发现：要求zookeeper集群必须选举出一个 Leader 进程，同时 Leader 会维护一个 Follower 可用客户端列表。将来客户端可以和这些 Follower节点进行通信。
同步：Leader 要负责将本身的数据与 Follower 完成同步，做到多副本存储。这样也是提现了CAP中的高可用和分区容错。Follower将队列中未处理完的请求消费完成后，写入本地事务日志中。
广播：Leader 可以接受客户端新的事务Proposal请求，将新的Proposal请求广播给所有的 Follower。
- Zookeeper的读写请求
Zookeeper 客户端会随机的链接到 zookeeper 集群中的一个节点
如果是读请求，就直接从当前节点中读取数据；
如果是写请求，那么节点就会向 Leader 提交事务，Leader 接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交。
