- 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 接收到事务提交,会广播该事务,只要超过半数节点写入成功,该事务就会被提交。