开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第20天，点击查看活动详情
Zookeeper集群
基本啥玩意都有集群,Zookeeper也不例外。
Zookeeper集群间通过 ZAB 协议（ZooKeeper Atomic Broadcast）来保持数据的一致性。
ZooKeeper并没有采用传统的主写从读模式,而是引入了 Leader、Follower 和 Observer 三种角色
- Leader:提供读写功能,负责投票的发起和决议，更新系统状态
- Follower:提供读服务,如果是写服务则转发给 Leader。参与选举过程中的投票
- Observer:为客户端提供读服务，如果是写服务则转发给 Leader。不参与选举过程中的投票，也不参与“过半写成功”策略。在不影响写性能的情况下提升集群的读性能
看过《权力的游戏》吗,Leader就相当于国王,Follower相当于王子,而Observer则为御林铁卫。国王拥有至高无上的权力,那么当国王宕机(die)后,Follower就根据一些条件发起投票选取新一任国王,而御林铁卫(Observer)没有权力进行投票也没资格上位,对于朝廷策略也无法参与(对应不参与“过半写成功”策略)但由于相当于国王的私人秘书,了解王国的消息,提供读服务,要是要进行王国治理,则需要请示国王,王子也是如此。而御林铁卫(Observer)不管国王是谁都效忠(弑君者除外),因此王国纠纷与Observer无关,他只负责保护国王(提供读服务)和转发王国治理意见(转发写服务至国王)
选举过程
选举阶段：根据一些条件判断出先后进行选举的顺序,按顺序依次投票,超过一半则为准leader
发现阶段 ：followers 跟准 leader 进行通信，同步 followers 最近接收的事务提议。
同步阶段 :同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步followers和Observer所有的副本。同步完成之后 准 leader 成为真正的 leader。
广播阶段 :到了这个阶段，ZooKeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步
ZooKeeper 集群中的服务器状态
- LOOKING ：寻找 Leader。
- LEADING ：Leader 状态，对应的节点为 Leader。
- FOLLOWING ：Follower 状态，对应的节点为 Follower。
- OBSERVING ：Observer 状态，对应节点为 Observer，该节点不参与 Leader 选举
PS:ZooKeeper 集群最好为奇数台
为什么？这是由于ZooKeeper可用性的机制,ZooKeeper可用性是指只有ZooKeeper的活着的服务个数大于die的个数才能提供服务,那么5台就需要保证3台活着,而6台需要保证4台活着,也就是要确保die的不能超过3台,很好理解了吧
脑裂及其解决方案过半成功策略
各个服务器由于网络不顺的情况下.都以为对方下机了,因此每台服务器上对应的集群选举了一个leader,导致一个ZooKeeper服务出现了许多leader,会出现数据不一致的情况。
过半成功策略:leader在进行写服务时会对followers 进行广播,只有回复的个数大于一半才会进行写服务,可以很好的防止脑裂现象的出现
ZAB(原子广播) 协议和 Paxos 算法
ZooKeeper使用ZAB 协议作为其保证数据一致性的核心算法,ZAB 协议是专门为ZooKeeper服务的算法
一种支持崩溃恢复的原子广播协议,基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性
ZAB协议2种基本模式：崩溃恢复和消息广播
ZAB协议具体内容另开一灶
