1.哨兵机制原理
1.1.三个定时任务
Sentinel 维护着三个定时任务以监测 Redis 节点及其它 Sentinel 节点的状态
1）info 任务：每个 Sentinel 节点每 10 秒就会向 Redis 集群中的每个节点发送 info 命令，以获得最新的 Redis 拓扑结构
2）心跳任务：每个Sentinel节点每1秒就会向所有Redis节点及其它Sentinel节点发送一条ping命令， 以检测这些节点的存活状态。该任务是判断节点在线状态的重要依据
3）发布/订阅任务：启动后，每个 Sentinel 节点每 2 秒就会向每个 Redis 节点发布一条_ _sentinel_ _:hello 主 题的信息，该信息是当前 Sentinel 对每个 Redis 节点在线状态的判断结果及当前 Sentinel 节 点信息。当 Sentinel 节点接收到_ _sentinel_ _:hello 主题信息后，就会读取并解析这些信息，然后如果发现有新的 Sentinel 节点加入，则记录下新加入 Sentinel 节点信息，并与其建立连接；如果发现有 Sentinel Leader 选举的选票信息，则执行 Leader 选举过程；汇总其它 Sentinel 节点对当前 Redis 节点在线状态的判断结果，作为 Redis 节点客观下 线的判断依据
1.2.Redis 节点下线判断
对于每个 Redis 节点在线状态的监控是由 Sentinel 完成的
1）主观下线：每个 Sentinel 节点每秒就会向每个 Redis 节点发送 ping 心跳检测，如果 Sentinel 在 down-after-milliseconds 时间内没有收到某 Redis 节点的回复，则 Sentinel 节点就会对该 Redis 节点做出“下线状态”的判断。这个判断仅仅是当前 Sentinel 节点的“一家之言”，所以称 为主观下线
2）客观下线：当 Sentinel 主观下线的节点是 master 时，该 Sentinel 节点会向每个其它 Sentinel 节点发 送 sentinel is-master-down-by-addr 命令，以询问其对 master 在线状态的判断结果。这些 Sentinel 节点在收到命令后会向这个发问 Sentinel 节点响应 0（在线）或 1（下线）。当 Sentinel 收到超过 quorum 个下线判断后，就会对 master 做出客观下线判断
1.3.Sentinel Leader 选举
当 Sentinel 节点对 master 做出客观下线判断后会由 Sentinel Leader 来完成后续的故障转移，Sentinel 集群的 Leader 选举是通过 Raft 算法实现
每个选举参与者都具有当选 Leader 的资格，当其完成了“客观下线”判断后，就会立 即“毛遂自荐”推选自己做 Leader，然后将自己的提案发送给所有参与者。其它参与者在收到提案后，只要自己手中的选票没有投出去，其就会立即通过该提案并将同意结果反馈给提案者，后续再过来的提案会由于该参与者没有了选票而被拒绝。当提案者收到了同意反馈数量大于等于 max(quorum，sentinelNum/2+1)时，该提案者当选 Leader
在网络没有问题的前提下，基本就是谁先做出了“客观下线”判断，谁就会首先发起 Sentinel Leader 的选举，谁就会得到大多数参与者的支持，谁就会当选 Leader；Sentinel Leader 选举会在次故障转移发生之前进行；故障转移结束后 Sentinel 不再维护这种 Leader-Follower 关系，即 Leader 不再存在
1.4.master 选择算法
在进行故障转移时，Sentinel Leader 需要从所有 Redis 的 Slave 节点中选择出新的 Master。 其选择算法为：
1）过滤掉所有主观下线的，或心跳没有响应 Sentinel 的，或 replica-priority 值为 0 的 Redis 节点
2）在剩余 Redis 节点中选择出 replica-priority 最小的的节点列表。如果只有一个节点，则直接返回，否则继续
3）从优先级相同的节点列表中选择复制偏移量最大的节点。如果只有一个节点，则直接返 回，否则继续
4）从复制偏移值量相同的节点列表中选择动态 ID 最小的节点返回
1.5.故障转移过程
1）Sentinel Leader 根据 master 选择算法选择出一个 slave 节点作为新的 master
2）Sentinel Leader 向新 master 节点发送 slaveof no one 指令，使其晋升为 master
3）Sentinel Leader 向新 master 发送 info replication 指令，获取到 master 的动态 ID
4）Sentinel Leader 向其余 Redis 节点发送消息，以告知它们新 master 的动态 ID
5）Sentinel Leader 向其余 Redis 节点发送 slaveof 指令，使它们成为新 master 的 slave
6）Sentinel Leader 从所有 slave 节点中每次选择出 parallel-syncs 个 slave 从新 master 同步数 据，直至所有 slave 全部同步完毕，故障转移完毕
1.6.节点上线
1）原 Redis 节点上线：无论是原下线的 master 节点还是原下线的 slave 节点，只要是原 Redis 集群中的节点上 线，只需启动 Redis 即可。因为每个 Sentinel 中都保存有原来其监控的所有 Redis 节点列表， Sentinel 会定时查看这些 Redis 节点是否恢复。如果查看到其已经恢复，则会命其从当前 master 进行数据同步。如果是原 master 上线，在新 master 晋升后 Sentinel Leader 会立即先将原 master 节点更新为 slave，然后才会定时查看其是否恢复
2）新 Redis 节点上线：如果需要在 Redis 集群中添加一个新的节点，其未曾出现在 Redis 集群中，则上线操作 只能手工完成。即添加者在添加之前必须知道当前 master 是谁，然后在新节点启动后运行 slaveof 命令加入集群
3）Sentinel 节点上线：如果要添加的是 Sentinel 节点，无论其是否曾经出现在 Sentinel 集群中，都需要手工完 成。即添加者在添加之前必须知道当前 master 是谁，然后在配置文件中修改 sentinel monitor 属性，指定要监控的 master。然后启动 Sentinel 即可
2.CAP 定理
2.1.概念
是在一个分布式系统中，一致性、可用性、分区容错性，三者不可兼得
1）一致性：分布式系统中多个主机之间是否能够保持数据一致的特性。即，当系统数据发生更新操作后，各个主机中的数据仍然处于一致的状态
2）可用性：系统提供的服务必须一直处于可用的状态，即对于用户的每一个请求，系统总是可以在有限的时间内对用户做出响应
3）分区容错性：分布式系统在遇到任何网络分区故障时，仍能够保证对外提供满足一 致性和可用性的服务
2.2.定理
CAP 定理的内容是：对于分布式系统，网络环境相对是不可控的，出现网络分区是不可 避免的，因此系统必须具备分区容错性。但系统不能同时保证一致性与可用性。即要么 CP， 要么 AP
2.3.BASE 理论
BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最 终一致性）三个短语的简写，BASE 是对 CAP 中一致性和可用性权衡的结果，其来源于对大 规模互联网系统分布式实践的结论，是基于 CAP 定理逐步演化而来的
核心思想：即使无法做到强一致性，但每个系统都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性
1）基本可用：分布式系统在出现不可预知故障的时候，允许损失部分可用性
2）软状态：允许系统数据存在的中间状态，并认为该中间状态的存在不会影响系统的 整体可用性，即允许系统主机间进行数据同步的过程存在一定延时。软状态，其实就是一种 灰度状态，过渡状态
3）最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到 一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要保证系统数据的实时一致性
2.4.CAP 的应用
1）Zookeeper 与 CAP：Zookeeper 遵循的是 CP 模式，即保证了一致性，但牺牲了可用性。当 Leader 节点中的数据发生了变化后，在 Follower 还没有同步完成之前，整个 Zookeeper集群是不对外提供服务的。如果此时有客户端来访问数据，则客户端会因访问超时而发生重试。不过，由于 Leader 的选举非常快，所以这种重试对于用户来说几乎是感知不到的。因此Zookeeper 保证了一致性，但牺牲了可用性
2）Consul 与 CAP：Consul 遵循的是 CP 模式，即保证了一致性，但牺牲了可用性
3）Redis 与 CAP：Redis 遵循的是 AP 模式，即保证了可用性，但牺牲了一致性
4）Eureka 与 CAP：Eureka 遵循的是 AP 模式，即保证了可用性，但牺牲了一致性
5）Nacos 与 CAP：Nacos 在做注册中心时，默认是 AP 的。但其也支持 CP 模式，但需要用户提交请求进行 转换
3.Raft 算法
3.1.概念
Raft 算法是一种通过对日志复制管理来达到集群节点一致性的算法。这个日志复制管理 发生在集群节点中的 Leader 与 Followers 之间。Raft 通过选举出的 Leader 节点负责管理日志 复制过程，以实现各个节点间数据的一致性
动画演示：https://thesecretlivesofdata.com/raft/
3.2.角色、任期及角色转变
在 Raft 中，节点有三种角色：
1）Leader：唯一负责处理客户端写请求的节点；也可以处理客户端读请求；同时负责日志 复制工作
2）Candidate：Leader 选举的候选人，其可能会成为 Leader。是一个选举中的过程角色
3）Follower：可以处理客户端读请求；负责同步来自于 Leader 的日志；当接收到其它
Cadidate 的投票请求后可以进行投票；当发现 Leader 挂了，其会转变为 Candidate 发起 Leader 选举
3.3.leader 选举
1）参加选举：若 follower 在心跳超时范围内没有接收到来自于 leader 的心跳，则认为 leader 挂了。此 时其首先会使其本地 term 增一。然后 follower 会依次完成：此时若接收到了其它 candidate 的投票请求，则会将选票投给这个 candidate；由 follower 转变为 candidate；若之前尚未投票，则向自己投一票；向其它节点发出投票请求，然后等待响应
2）参加投票：follower 在接收到投票请求后，判断是否投票：发来投票请求的 candidate 的 term 不能小于自己的 term；在自身当前 term 内，选票还没有投出去；若接收到多个 candidate 的请求，将采取 first-come-first-served 方式投票
3）等待响应：当一个 Candidate 发出投票请求后会等待其它节点的响应结果。这个响应结果：收到过半选票，成为新的 leader，然后会将消息广播给所有其它节点，以告诉大家自己是新的 Leader 了；接收到别的 candidate 发来的新 leader 通知，比较了新 leader 的 term 并不比自己的 term 小，则自己转变为 follower；经过一段时间后，没有收到过半选票，也没有收到新 leader 通知，则重新发出选举
4）选举时机：在很多时候，当 Leader 真的挂了，Follower 几乎同时会感知到，所以它们几乎同时会变 为 candidate 发起新的选举。此时就可能会出现较多 candidate 票数相同的情况，即无法选举出 Leader。为了防止这种情况的发生，Raft 算法其采用了 randomized election timeouts 策略来解决 这个问题。其会为这些 Follower 随机分配一个选举发起时间 election timeout，这个 timeout 在 150-300ms 范围内。只有到达了 election timeout 时间的 Follower 才能转变为 candidate， 否则等待。那么 election timeout 较小的 Follower 则会转变为 candidate 然后先发起选举，一 般情况下其会优先获取到过半选票成为新的 leader
3.4.数据同步
1）状态机：Raft 算法一致性的实现，是基于日志复制状态机的。状态机的最大特征是，不同 Server 中的状态机若当前状态相同，然后接受了相同的输入，则一定会得到相同的输出
2）处理流程：
a.当leader 接收到 client 的写操作请求后，leader 会将数据与 term 封装为一个 box，并随 着下一次心跳发送给所有 followers，以征求大家对该 box 的意见。同时在本地将数据封 装为日志
b.当follower 接收到来自 leader 的 box 后首先会比较该 box 的 term 与本地记录的曾接受过 的 box 的最大 term，只要不比自己的小就接受该 box，并向 leader 回复同意。同时会将 该 box 中的数据封装为日志
c.当 leader 接收到过半同意响应后，会将日志 commit 到自己的状态机，状态机会输出一 个结果，同时日志状态变为了 committed
d.同时 leader 还会通知所有 follower 将日志 commit 到它们本地的状态机，日志状态变为 了 committed
e.在 commit 通知发出的同时，leader 也会向 client 发出成功处理的响应
3）AP 支持：Log 由 term index、log index 及 command 构成。为了保证可用性，各个节点中的日志可 以不完全相同，但 leader 会不断给 follower 发送 box，以使各个节点的 log 最终达到相同。 即 raft 算法不是强一致性的，而是最终一致的
3.5.脑裂
Raft 集群存在脑裂问题。在多机房部署中，由于网络连接问题，很容易形成多个分区。而多分区的形成，很容易产生脑裂，从而导致数据不一致。由于三机房部署的容灾能力最强，所以生产环境下，三机房部署是最为常见的。下面以三机房部署为例进行分析，根据机房断网情况，可以分为五种情况：
1）不确定：B 机房中的主机是感知不到 Leader 的存在的，所以 B 机房中的主机会发起新一轮的 Leader 选举。虽然 C 机房中的 Follower 能够感知到 A 机房中的 Leader，但由于其接收到了更大 term 的投票请求，所以 C 机房的 Follower 也就放弃了 A 机房中的 Leader，参与了新 Leader 的选举。
a.若新 Leader 出现在 B 机房，A 机房是感知不到新 Leader 的诞生的，其不会自动下课， 所以会形成脑裂。由于 A 机房 Leader 处理的写操作请求无法获取到过半响应，所以无法完成写操作。但 B 机房 Leader 的写操作处理是可以获取到过半响应的，所以可以完成写操作，形成了数据的不一致。
b.若新 Leader 出现在 C 机房，A 机房中的 Leader 则会自动下课，所以不会形成脑裂。
·
2）形成脑裂
3）无脑裂：A、C 可以正常对外提供服务，但 B 无法选举出新的 Leader。由于 B 中的主机全部变为 了选举状态，所以无法提供任何服务，没有形成脑裂
4）无脑裂：A、B、C 均可以对外提供服务，不受影响
5）无脑裂：A 机房无法处理写操作请求，但可以对外提供读服务。B、C 机房由于失去了 Leader，均会发起选举，但由于均无法获取过半支持，所以均无法选举出新的 Leader
3.6.Leader 宕机处理
1）请求到达前 Leader 挂了：client 发送写操作请求到达 Leader 之前 Leader 就挂了，因为请求还没有到达集群，所以 这个请求对于集群来说就没有存在过，对集群数据的一致性没有任何影响。Leader 挂了之 后，会选举产生新的 Leader。由于 Stale Leader 并未向 client 发送成功处理响应，所以 client 会重新发送该写操作请求
2）未开始同步数据前 Leader 挂了：client 发送写操作请求给 Leader，请求到达 Leader 后，Leader 还没有开始向 Followers 发出数据 Leader 就挂了。这时集群会选举产生新的 Leader。Stale Leader 重启后会作为 Follower 重新加入集群，并同步新 Leader 中的数据以保证数据一致性。之前接收到 client 的 数据被丢弃。由于 Stale Leader 并未向 client 发送成功处理响应，所以 client 会重新发送该写操作请求
3）同步完部分后 Leader 挂了：client 发送写操作请求给 Leader，Leader 接收完数据后向所有 Follower 发送数据。在部分 Follower 接收到数据后 Leader 挂了。由于 Leader 挂了，就会发起新的 Leader 选举。
a.若 Leader 产生于已完成数据接收的 Follower，其会继续将前面接收到的写操作请求转换 为日志，并写入到本地状态机，并向所有 Flollower 发出询问。在获取过半同意响应后 会向所有 Followers 发送 commit 指令，同时向 client 进行响应
b.若 Leader 产生于尚未完成数据接收的 Follower，那么原来已完成接收的 Follower 则会放 弃曾接收到的数据。由于 client 没有接收到响应，所以 client 会重新发送该写操作请求
4）commit 通知发出后 Leader 挂了：client 发送写操作请求给 Leader，Leader 也成功向所有 Followers 发出的 commit 指令， 并向 client 发出响应后，Leader 挂了。由于 Stale Leader 已经向 client 发送成功接收响应，且 commit 通知已经发出，说明这个 写操作请求已经被 server 成功处理
