Zookeeper入门
Zookeeper中的角色
Leader
Leader 负责进行投票的发起和决议，更新系统状态
Follower
Follower 用于接受客户端请求并向客户端返回结果，在选主过程中参与投票。
Observer
可以接受客户端连接，将写请求转发给 Leader，但 Observer 不参加投票过程，只同步leader的状态，Observer 的目的是为了扩展系统，提高读取速度。
TIPS：在不影响写入性能的情况下扩展 ZooKeeper
尽管 Zookeeper 集群的性能已经很好了，但是在大规模应用中，要承受大量 Client，就必须扩大 Server 的数量。随着 Server 数量的增加，Zookeeper 集群的写入性能必定下降。这是由于 Zookeeper 的 ZNode 变更需要半数以上的节点同意，因此随着添加更多的投票者，投票的成本会显著增加。
Observer 是一种新型的 ZooKeeper 节点，用于解决扩大节点导致的性能下降问题。 Observer 不参与投票，仅接受投票结果，因此我们添加再多的 Observer 也不会影响集群性能。Observer 的另一个优势是，由于它不参与投票，所以 Observer 不属于 Zookeeper 集群的关键节点，即使 Observer Failed，也不会影响集群的可用性。
Client
请求发起方
Zookeeper 选举机制
在一个 Zookeeper 集群中，会选出一个 Leader 节点，若干个 Follower 和 Observer 节点。Leader 选举是保证分布式数据一致性的关键所在。当 Zookeeper 集群中的一台服务器出现以下两种情况之一时，需要进入 Leader 选举。
- Zookeeper 集群初始化启动
- Zookeeper 集群运行期间无法和 Leader 保持连接
Zookeeper 集群中选举的基本概念
节点状态
在介绍 Zookeeper 选举机制之前，先了解一下Zookeeper集群中节点的状态。
在一个 Zookeeper 集群中，节点可能具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。
- LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态
- FOLLOWING：跟随者状态。表明当前服务器角色是Follower
- LEADING：领导者状态。表明当前服务器角色是Leader
- OBSERVING：观察者状态。表明当前服务器角色是Observer
投票数据结构
每个投票中包含了两个最基本的信息，所推举服务器的 SID 和 ZXID，投票在 Zookeeper 中包含字段如下：
- myid：被推举的 Leader 的 SID
- zxid：被推举的 Leader 事务 ID
- electionEpoch：逻辑时钟，用来判断多个投票是否在同一轮选举周期中，该值在服务端是一个自增序列，每次进入新一轮的投票后，都会对该值进行加1操作
- peerEpoch：被推举的 Leader 的 epoch
- state：当前节点的状态
Zookeeper 集群初始化启动时的 Leader 选举
若进行Leader选举，则至少需要两台机器，这里选取两台机器组成的 Zookeeper 集群为例。
在集群初始化阶段，当有一台服务器 Server1 启动时，其单独无法进行和完成 Leader 选举，当第二台服务器 Server2 启动时，此时两台机器可以相互通信，每台机器都试图找到 Leader，于是进入 Leader 选举过程。
选举阶段
由于是初始情况，Server1 和 Server2 都会将自己作为 Leader 服务器来进行投票，每次投票会包含所推举的服务器的 myid 和 ZXID，使用 (myid, ZXID) 来表示，此时 Server1 的投票为 (1, 0)，Server2 的投票为 (2, 0)，然后各自将这个投票发给集群中其他机器。
接收投票
集群的每个节点收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自 LOOKING 状态的节点。
处理投票
针对每一个投票，节点都需要将别人的投票和自己的投票进行PK，PK规则如下：
- 优先检查 ZXID。ZXID 比较大的节点优先作为 Leader
- 如果 ZXID 相同，那么就比较 myid。myid 较大的节点作为 Leader 节点
对于 Server1 而言，它的投票是 (1, 0)，接收 Server2 的投票为 (2, 0)，首先会比较两者的 ZXID，均为 0，再比较 myid，此时 Server2 的 myid 最大，于是更新自己的投票为 (2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。
统计投票
每次投票后，节点都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，如果一台机器收到了超过半数的相同投票，那么这个投票对应的节点即为 Leader。
对于 Server1、Server2 而言，都统计出集群中已经有两台机器接受了 (2, 0) 的投票信息，此时便认为已经选出了 Leader
同步阶段
一旦确定了 Leader，每个节点就会更新自己的状态，如果是 Follower，那么就变更为 FOLLOWING，如果是 Leader，就变更为 LEADING
Zookeeper 集群运行期间的 Leader 选举
在 Zookeeper 运行期间，Leader 与非 Leader 节点各司其职，即便当有非 Leader 节点宕机或新加入，此时也不会影响 Leader，但是一旦 Leader 节点挂了，那么整个集群将暂停对外服务，进入新一轮 Leader 选举。
其过程和启动时期的 Leader 选举过程基本一致。假设正在运行的有 Server1、Server2、Server3 三台服务器，当前 Leader 是 Server2，若某一时刻 Leader 挂了，此时便开始 Leader 选举。
变更状态
Leader 节点宕机后，余下的非 Observer 节点都会将自己的状态变更为 LOOKING，然后开始进入 Leader 选举过程
选举阶段
在运行期间，每个服务器上的 ZXID 可能不同，此时假定 Server1 的 ZXID 为 123，Server3 的 ZXID 为 122。在第一轮投票中，Server1 和 Server3 都会投自己，产生投票 (1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。
接收投票
集群的每个节点收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自 LOOKING 状态的节点。
处理投票
针对每一个投票，节点都需要将别人的投票和自己的投票进行PK，PK规则如下：
- 优先检查 ZXID。ZXID 比较大的节点优先作为 Leader
- 如果 ZXID 相同，那么就比较 myid。myid 较大的节点作为 Leader 节点
此时，Server1 将会成为 Leader。
统计投票
每次投票后，节点都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于 Server1、Server3 而言，都统计出集群中已经有两台机器接受了 (1, 123) 的投票信息，此时便认为已经选出了 Leader
同步阶段
一旦确定了 Leader，每个节点就会更新自己的状态，如果是 Follower，那么就变更为 FOLLOWING，如果是 Leader，就变更为 LEADING
以上是 Zookeeper入门 的全部内容， 来源链接： utcz.com/a/18163.html
