Zookeeper选主流程

在Zookeeper集群中，主要分为三者角色，而每一个节点同时只能扮演一种角色，这三种角色分别是：

每个Server在工作过程中有四种状态：

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是 恢复模式（选主） 和 广播模式（同步） 。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。leader选举是保证分布式数据一致性的关键。

当zk集群中的一台服务器出现以下两种情况之一时，就会开始leader选举。

而当一台机器进入leader选举流程时，当前集群也可能处于以下两种状态。

首先第一种情况，通常是集群中某一台机器启动比较晚，在它启动之前，集群已经正常工作，即已经存在一台leader服务器。当该机器试图去选举leader时，会被告知当前服务器的leader信息，它仅仅需要和leader机器建立连接，并进行状态同步即可。

下面重点看第二种情况，即集群中leader不存在的情况下如何进行leader选举。

投票信息中包含两个最基本的信息。

集群中的每台机器发出自己的投票后，也会接受来自集群中其他机器的投票。每台机器都会根据一定的规则，来处理收到的其他机器的投票，以此来决定是否需要变更自己的投票。

规则如下：

假设当前集群中有5台机器组成。sid分别为1，2，3，4，5。zxid分别为9，9，9，8，8，并且此时sid为2的机器是leader。某一时刻，1和2的服务器挂掉了，集群开始进行选主。

redis数据淘汰原理

redis过期数据删除策略

redis server事件模型

redis cluster mget 引发的讨论

redis 3.x windows 集群搭建

redis 命令执行过程

redis string底层数据结构

redis list底层数据结构

redis hash底层数据结构

redis set底层数据结构

redis zset底层数据结构

redis 客户端管理

redis 主从同步-slave端

redis 主从同步-master端

redis 主从超时检测

redis aof持久化

redis rdb持久化

redis 数据恢复过程

redis TTL实现原理

redis cluster集群建立

redis cluster集群选主

 当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master可能会有多个slave。Failover的过程需要经过类Raft协议的过程在整个集群内达到一致， 其过程如下：

 在作为slave角色节点会定期发送ping命令来检测master的存活性，如果检测到master未响应，那么就将master节点标记为疑似下线。

 clusterHandleSlaveFailover执行重新选主的核心逻辑。

 clusterHandleSlaveFailover内部通过clusterRequestFailoverAuth方法向集群当中的所有节点发送CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST报文，通知大家slave准备执行failover。

 当节点收到超过n/2+1个master的response后即升级为主。

 在redis主从选举过程中报文相关的解析逻辑，clusterProcessPacket内部主要处理CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST和CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK报文。

redis cluster集群的源码分析(1)

Redis Cluster 实现细节

Zab协议有四个阶段

    Leader election

    Discovery (E#epoch establish)

    Synchronization (5X#sync with followers)

    Broadcast

比如3个节点选举leader：编号为1、2、3。1先启动，选择自己为leader，然后2启动首先也选择自己为leader，由于1,2都没过半，选择编号大的为leader，所以1、2都选择2为leader，然后3启动发现1，2已经协商好且数量过半，于是3也选择2为leader，leader选举结束。

1.定义

    Raft是工程上使用较为广泛的强一致、去中心化、高可用的分布式协议。是一种共识算法。

2.选主流程

    Raft算法定义了三种角色：

        Leader（领导者）

        Follower（追随者）

        Candidate（候选者）

    初始状态下集群所有节点都是Follower，每一个节点都有自己的计时器，当计时达到了超时时间（Election Timeout），该节点会转变为Candidate，成为Candidate的节点，会首先给自己投票，然后向集群中其他所有的节点发起请求，要求大家都给自己投票，其他收到投票请求且还未投票的Follower节点会向发起者投票，发起者收到反馈通知后，票数增加。

    得票数超过了集群节点数量的一半，该节点晋升为Leader节点。Leader节点会立刻向其他节点发出通知，告诉大家自己是领导者。收到通知的节点全部变为Follower，并且各自的计时器清零。如果发现有节点票数相同，那么会随机休息一段时间，再次发起投票，由于时间是随机，所以避免再次票数相同的概率

    选出 Leader 后，Leader 通过定期向所有 Follower 发送心跳信息维持其统治。若 Follower 一段时间未收到 Leader 的心跳则认为 Leader 可能已经挂了再次发起选主过程

3.数据同步

    1.由客户端提交数据到Leader节点

    2.Leader 节点接收到的数据处于未提交状态（Uncommitted）

    3.由Leader节点把数据复制到集群内所有的Follower节点

    4.Follower节点们接收到复制的数据，会反馈给Leader节点

    5.如果Leader节点接收到超过半数的Follower反馈，表明复制成功，向 Client 确认数据已接收

    6.一旦向 Client 发出数据接收 Ack 响应后，表明此时数据状态进入已提交（Committed）

    7.再由Leader节点通知集群内所有的Follower节点提交数据，从而完成数据同步流程

3.1 脑裂及解决方法

1. Quorums（法定人数）， 过半机制 ：默认方式， 比如3个节点的集群，Quorums = 2, 也就是说集群可以容忍1个节点失效，这时候还能选举出1个leader，集群还可用。比如4个节点的集群，它的Quorums = 3，Quorums要超过3，相当于集群的容忍度还是1，如果2个节点失效，那么整个集群还是无效的。

2. 冗余通信：采用多种通信方式，避免因一种通信终端导致脑裂。

    3.智能磁盘锁： 正在服务一方锁住共享磁盘，"裂脑"发生时，让对方完全"抢不走"共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动"解锁"，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了"智能"锁。即正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。

4. 设置仲裁机制： 例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下 参考IP，不通则表明断点就出在本端，不仅"心跳"、还兼对外"服务"的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。

3.2 羊群效应

    宕机的那个Broker上的Partition比较多， 会造成多个Watch被触发，造成集群内大量的调整，导致大量网络阻塞

3.3 zookeeper负载过重

    每个Replica都要为此在ZooKeeper上注册一个Watch，当集群规模增加到几千个Partition时  ZooKeeper负载会过重

---