从小工到专家：网络分区看这个就够来了

什么是“脑裂”

“脑裂” 就是双master

你的 cluster 里面有两个节点，两个结点都会觉得现在没有 master，所以每个都把自己选举成 master

观点1：1 集群奇数2 投票过半和3 任期大小

1、zooKeeper默认采用了Quorums这种方式来防止"脑裂"现象。

即只有集群中超过半数节点投票才能选举出Leader。

这样的方式可以确保leader的唯一性,要么选出唯一的一个leader,要么选举失败。在zookeeper中Quorums作用如下： 1] 集群中最少的节点数用来选举leader保证集群可用。 2] 通知客户端数据已经安全保存前集群中最少数量的节点数已经保存了该数据。

一旦这些节点保存了该数据，客户端将被通知已经安全保存了，可以继续其他任务。而集群中剩余的节点将会最终也保存了该数据。

假设某个leader假死，其余的followers选举出了一个新的leader。

这时，旧的leader复活并且仍然认为自己是leader，这个时候它向其他followers发出写请求也是会被拒绝的。

因为每当新leader产生时，会生成一个epoch标号(标识当前属于那个leader的统治时期)，这个epoch是递增的，followers如果确认了新的leader存在，知道其epoch，就会拒绝epoch小于现任leader epoch的所有请求。

那有没有follower不知道新的leader存在呢，有可能，但肯定不是大多数，否则新leader无法产生。

Zookeeper的写也遵循quorum机制，因此，得不到大多数支持的写是无效的，旧leader即使各种认为自己是leader，依然没有什么作用。

https://raft.github.io/

【当问到这个问题时候，现在还是一片空白，感觉很难回答，其实你思路就是基本流程，不需要特别处理】

假死：由于心跳超时（网络原因导致的）认为master死了，但其实master还存活着假死导致脑裂的一个根源问题就是假死。timeout
脑裂：由于假死会发起新的master选举，选举出一个新的master，但旧的master网络又通了，导致出现了两个master ，有的客户端连接到老的master 有的客户端链接到新的master。

zk quorum（半数机制）机制解决脑裂，但是timeout造成正常情况下误判？？？如何解决

超时机制：

[源码解析] 从TimeoutException看Flink的心跳机制
ubbo的超时机制和重试机制
Hystrix超时机制
Netty HashedWheelTimer时间轮源码学习好多概念，这里只说一个轮盘定时器 HashedWheelTimer

从小工到专家：设计循环队列也提到了。

俄罗斯轮盘

Kafka中的时间轮（TimingWheel）是一个存储定时任务的环形队列，底层采用数组实现，数组中的每个元素可以存放一个定时任务列表（TimerTaskList）。TimerTaskList是一个环形的双向链表，链表中的每一项表示的都是定时任务项（TimerTaskEntry），其中封装了真正的定时任务TimerTask

其实时间轮就是一个不存在hash冲突的数据结构就拿秒表来说，它总是落在 0 - 59 秒，每走一圈，又会重新开始。

观点2: 对假死现象

选举是保证raft安全性的基础，心跳是保证集群能够尽快从Leader宕机或者网络分区中恢复的关键。etcd中将心跳和计时做了集成，抽象成tick

为什么需要预选 添加预选的原因是为了在网络状况不佳时，减少选举次数。

举个具体场景，当集群中的网络不稳定时，会有部分Follower不能及时地收到Leader的心跳，这时候就会有Follower发起选举。

但是网络原因，它自身也很难拿到超过半数选票当选，或者当选之后也很快就会有别的节点因为收不到心跳而再次发起选举，这就导致了集群经常处于选举状态而不可用。

为了防止这种情况的频繁发生，添加预选阶段，等于把Leader挂掉这件事从单个节点自己判断，变成了半数节点一起判断，大大减少了误判。凡事都有利有弊，当Leader虽然没挂掉，但性能有问题时，可能只影响了不到一半的节点。添加预选之后可能会导致性能不佳的Leader很难被选下去，从而影响读写性能。

作者：空挡链接：https://www.jianshu.com/p/ff6aaa66ea0f 来源：简书著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

上面看不懂就对了，现在从这个问题开始old leader根据什么来降级的，需要了解raft过程

条分缕析 Raft 算法

本文整理自 Ongaro 在 Youtube 上的视频。

系统模型

我们假设：

服务器可能会宕机、会停止运行过段时间再恢复，但是非拜占庭的（即它的行为是非恶意的，不会篡改数据等）；
网络通信会中断，消息可能会丢失、延迟或乱序；可能会网络分区；

Raft 是基于 Leader 的共识算法，故主要考虑：

Leader 正常运行
Leader 故障，必须选出新的 Leader

优点：只有一个 Leader，简单。

难点：Leader 发生改变时，可能会使系统处于不一致的状态，因此，下一任 Leader 必须进行清理；

系统正常运行时，只有一个 Leader，其余都是 Followers.

大家可以看到：

这里说明candidate状态变化，通过上面2个图

你会发现，有3个状态 1，后退 2 不变 3 前进

问题是：原则上我们可以无限重复分割选票，

假如选举同一时间开始，同一时间超时，同一时间再次选举，如此循环。

解决办法很简单：

节点随机选择超时时间，通常在 [T, 2T] 之间（T = electionTimeout）
这样，节点不太可能再同时开始竞选，先竞选的节点有足够的时间来索要其他节点的选票
T >> broadcast time(T 远大于广播时间)时效果更佳

这里对上面问题的回答，

超时设置并不少固定不变的，而是【t,2t】之内随机时间。

Raft在网络分区时leader选举的一个疑问？

共识算法-raft论文分析

Raft 作者亲自出的 Raft 试题，你能做对几道

资料

[1] MIT 6.824 Distributed Systems Spring 2020 中文翻译版合集: https://www.bilibili.com/video/av91748150

如何安全的领导选举（思考在双master也符合这个规则吗）

https://raft.github.io/raft.pdf

隐含条件：

1. vlolatile state on leaders 代表不会持久化：这个是很重要的一点。

2. 上个任期遗漏数据，不能通过上一个版本任期写入大多数来保证安全。例子1

大家可以看到，故障发送后，通过大多数判断这个原则，失效了。

因为缺少关键的“leader”，就是它下线了。【过半失效、

crash的服务，你是不知道的。无法通过个数来统计了。

大家可以看到，图c中的 s5，为什么能被选择上。最后一个任期 3大于其他节点2，s1（不统一）【任期大规则失效】

rpc请求参数隐含一个条件：单节点不知道那个是安全的，那个不是安全的。

统计个数方式不行，因此通过最新的一个记录做判断。

同样一个例子，一个写入过半数据是安全的，另外一个写入过半不是安全的。

差别在什么地方？

Case 2: Leader 试图提交之前任期的日志

如图所示的情况，在任期 2 时记录仅写在 S1 和 S2 两个节点上，由于某种原因，任期 3 的 Leader S5 并不知道这些记录，S5 创建了自己的三条记录然后宕机了，然后任期 4 的 Leader S1 被选出，S1 试图与其它服务器的日志进行匹配。因此它复制了任期 2 的日志到 S3。

此时 index=3 的记录时是不安全的。

因为 S1 可能在此时宕机，然后 S5 可能从 S2、S3、S4 获得选票成为任期 5 的 Leader。一旦 S5 成为新 Leader，它将覆盖 index=3-5 的日志，S1-S3 的这些记录都将消失。

我们还要需要一条新的规则，来处理这种情况。

观察如下：下面2个情况写入大多数节点后无法保证安全：

情况1: leader挂掉后，在当前term内：通过写入大多数节点就是安全判断失效。例如 3个节点，写入2个是安全的，其中一个节点挂掉但是写入和没有写入个数为1 无法判断【统计个数失效】
情况2:当新选举，term=4，通过先处理 tern=2的，也写入大多数节点。5个写入三个依然被覆盖的可能。【历史数据先同步失效】