NacosRaft分布式共识算法

Nacos/Raft分布式共识算法 Nacos/Raft分布式共识算法 概念

用于实现分布式共识的协议

保证集群的一致性

动画流程 官方：http://thesecretlivesofdata.com/raft/

（tip:以下内容参照官方动画流程总结）

1.单节点情况（次要）

假设有个单节点系统A

可以把节点视为 存储单个值的 数据库服务器

客户端CLIENT 发送一个值X到服务器

一个节点就很容易就这个值X达成一致或达成共识A=X

2.多节点情况

这是个分布式共识问题，分为两部分： 节点的角色状态 和 流程（两步走）

节点的角色状态

1. Follower追随者
  · 负责响应来自Leader或者Candidate的请求

2. Candidate候选人
  · 用于选举Leader的一种角色

3. Leader领导人
  · 负责接收客户端的请求

流程
1. 领导人选举过程
2. 日志复制过程

2.1. 领导人选举过程（主要）

领导人选举过程

初始化时，所有节点都是追随者状态如果追随者没有收到领导人信息他们自己会变成候选人
. 在各自随机分配的时间（150ms-300ms）内等待，先等完的成为候选人候选人发送给其他节点请求投票节点回复他们的投票如果候选人获得大多数节点票数就会变成领导人

选举超时（选举时间）
1. 追随者等待成为候选人的时间
. 1.1 随机分配在150ms-300ms之间的时间内等待
. 1.2 先结束等待的追随者成为候选人
2. 候选人等待成为领导人的时间
· 2.1投票给自己
· 2.2向其他节点发送请求投票信息
· 2.3其他节点在此期间尚未投票的就会给候选人投票
· 2.4其他节点投票后会重置选举超时（选举时间）
· 2.5候选人获得大多数投票，就会成为领导人
3. 可能出现的情况 - 分裂投票
· 3.1 如果两个节点同时成为候选者，则可以进行分裂投票
· 3.2 同一周期里，两个候选人同时开始选举
· 3.3 若两个候选人的票相同
· 3.4 就会进入随机时间的等待
· 3.5 先结束等待的候选人继续发起投票
· 3.6 成为领导人后，将系统所有的更改复制到所有节点

选举周期（重要）
1. 领导人以心跳超时为间隔向追随者发送附加条目信息
2. 追随者响应每条附加条目信息，并且重置追随者等待成为候选人的时间
3. 过程持续到某个追随者没有收到心跳，追随者就会在 追随者等待成为候选人的时间 结束后成为候选人
4. 要求大多数选票保证每个周期都只能选出一个领导人

2.3. 日志复制过程

	1. 系统的所有更改都要通过领导人
	2. 每次更改都添加一条当前未提交的节点日志，因此不会更新节点的值
	3. 先将日志复制到其他追随者节点
	4. 领导人等收到大部分节点都写入日志的消息，才提交日志，当前存储的值才发生改变
	5. 领导人提交日志后通知追随者，追随者就跟着提交日志
	6. 该集群就系统状态达成共识

2.4. 网络分区

优势：可在网络分区面前保持一致，达到数据一致性特点：
.1. 有几个分区就有几个领导人
.2. 条目少的那个分区无法提交日志
.3. 直到修复分区
.4. 保留最高领导人，其他领导人自动变成追随者并且回滚