Raft协议--概述--01

Raft协议–概述–01

---

1、Raft 算法概述

1. 是分布式系统开发首选的共识算法
2. Raft算法是经过一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致。
3. 用于管理日志一致性的协议。
4. 将分布式一致性分解为多个子问题：
   1. Leader选举(Leader election)
   2. 日志复制(Log replication)
   3. 安全性(Safety)
   4. 日志压缩(Log compaction)

2、基本术语解释

1. 大多数：(服务器节点总数/2)+1
2. term：任期
3. 选举超时
4. 心跳超时

2.1、随机选举超时（这是巧妙的设计）

1. 从Follower状态成为Candidate状态需要等待的时间
2. 这个时间是随机的
3. 选举超时的作用
   1. 防止多个节点同时发起投票
   2. 在大多数情况下只有一个服务器节点先发起选举，而不是同时发起选举，减少了因选票瓜分导致选举失败的情况。

2.2、心跳超时（heartbeat timeout）

1. leader节点会固定间隔时间向Follower节点发送心跳消息，这个固定间隔时间被称为心跳超时。
2. Follower节点收到每一条日志信息都需要向Leader节点响应这条日志复制的结果

2.3、任期逻辑时钟

1. 时间被划分为一个个任期(term)，term id 按时间轴单调递增
2. 每一个任期的开始都是 leader 选举，选举成功之后，leader 在任期内管理整个集群，也就是 “选举 + 常规操作”
3. 每个任期最多一个leader，可能没有leader(spilt-vote 导致)
   1. 没有leader：同一个任期，2个flooer同时选举，且有相同票数

3、Raft 角色

1. 领导者(Leader)
2. 跟从者(Follower)
3. 候选者(Candidate)

3.1、跟随者(Follower)

1. 普通群众
2. 完全被动，不能发送任何请求，只接受并响应来自 leader 和 candidate的消息
3. 每个节点启动后的初始状态一定是follower
4. 接收Leader的日志消息，并持久化Leader同步的日志，在Leader告诉日志可以提交之后，提交日志。
5. 当领导者心跳信息超时的时候，就主动站出来，推荐本身当候选人。

3.2、候选人(Candidate)

1. 候选人将向其余节点发送RPC消息，通知其余节点来投票
   1. 赢得投票，晋升为领导者
   2. 其他候选人赢得投票，降低为跟随者
   3. 这一回合所有的候选人都没赢，开启下一回合,重复1的的过程。且任期会加1。
2. Leader选举过程中的临时角色，用来竞选一个新leader
3. candidate 由 follower 触发超时而来

3.3、领导者(Leader)

1. 霸道总裁，一切以我为准。
2. 系统中必须存在且同一时刻只能有一个 leader
3. 只有 leader 可以接受 clients 发过来的请求，并向Follower同步请求日志，当日志同步到大多数节点上后告诉Follower提交日志。
4. 不断地发送心跳信息，通知所有Follower节点"我是领导者,我还活着,不要发起新的选举"。

3.4、跟随者、候选人和领导者图示

3.5、角色关系

1. Raft要求系统在任意时刻最多只有一个Leader
2. 正常工作期间只有Leader和Followers
3. Raft 算法将时间划分成为任意不同长度的任期(term)
   1. 任期用连续的数字进行表示
   2. 每一个term的开始都是Leader选举，一个或多个候选人会试图成为领导人。
      1. 在成功选举Leader之后，Leader会在整个term内管理整个集群。
      2. 如果Leader选举失败(候选人票数相同)
         1. 将会开始另一个任期，并且立刻开始下一次选举。

4、Message(RPC)的3种类型

Raft 算法中服务器节点之间通信使用远程过程调用(RPC)，且有3种

4.1、RequestVote RPC

1. 由 follower 发出
2. 用于发送投票请求

4.2、AppendEntries(Heartbeat) RPC

1. 由 leader 发出
2. 用于 leader 向 followers 复制日志条目
3. 用于 leader 向 followers 进行Heartbeat
   1. 日志条目为空即为 Heartbeat

4.3、InstallSnapshot RPC

1. 由 leader 发出
2. 用于快照传输，虽然多数情况都是每个服务器独立创建快照，但是leader有时候必须发送快照给一些落后太多的 follower，这通常发生在 leader 已经丢弃了下一条要发给该follower 的日志条目(Log Compaction 时清除掉了) 的情况下

5、分布式一致性问题

假设有一个单节点的数据库服务器，且存储了一个值为 X。

左边绿色是客户端，右边蓝色是节点 a(Node a)。Term表明任期，后面会讲到

客户端向单节点服务器发送了一条更新操做，设置数据库中存的值为 8。单个服务器节点下，客户端从服务器拿到的值也是 8。一致性很是容易保证。

但若是有多个服务器节点，怎么保证一致性呢？

1. 假设三个节点：a，b，c。这三个节点组成一个数据库集群。
2. 客户端对这三个节点进行更新操做，如何保证三个节点中存的值一致？
	1. 这个就是分布式一致性问题
	2. Raft 算法就是来解决这个问题的

在多节点集群中，在节点故障、分区错误等异常状况下，Raft 算法如何保证在同一个时间，集群中只有一个领导者呢？下面就开始讲解 Raft 算法选举领导者的过程。

6、Raft 算法的几个关键机制

通过以下几个关键机制，保证了一个任期只有一位领导，极大减少了选举失败的情况。

任期
领导者心跳信息
随机选举超时时间
先来先服务的投票原则
大多数选票原则

7、写的很好的文章

---

https://zhuanlan.zhihu.com/p/404786050