目录
[1 基于Raft算法实现的分布式键值对存储系统](#1 基于Raft算法实现的分布式键值对存储系统)
[1.1 模块](#1.1 模块)
[2 Raft 算法](#2 Raft 算法)
[2 .1 概念](#2 .1 概念)
[2.2 raft角色（先简单了解，方便后续阅读）](#2.2 raft角色（先简单了解，方便后续阅读）)
[2.3 raft想解决什么问题？](#2.3 raft想解决什么问题？)
[2.4 选举领导](#2.4 选举领导)
[2.5 领导者故障](#2.5 领导者故障)
▐ 核心要解决的问题
- 个人学习：Raft 算法要解决的问题，以及算法机制，通过项目理解如何实现raft算法。
- 项目：深入理解 Raft 算法，深刻理解分布式环境下数据强一致性该如何实现。
▐ 有哪些典型业务场景
- 在绝大部分场景可以保证数据强一致性，比如分布式配置系统系统、分布式 NoSQL 存储等等，轻松突破系统的单机限制。
▐ 使用到的技术
- 蚂蚁金服网络通信框架 SOFA-Bolt（基于 Netty）因为TCP长连接
- RocksDB是一个高性能、可扩展、嵌入式、持久化的键值存储引擎，广泛应用于大数据领域。
1 基于Raft算法实现的分布式键值对存储系统
1.1 模块
- 一致性模块，是 Raft 算法的核心实现。重点开发
- RPC 通信：可以使用 HTTP 短连接，也可以直接使用 TCP 长连接，考虑到集群各个节点频繁通信，同时节点通常都在一个局域网内，因此我们选用 TCP 长连接。长连接框架首选Netty，选用蚂蚁金服网络通信框架 SOFA-Bolt（基于 Netty），便于快速开发。
- 日志模块：Raft 算法中，日志实现是基础，考虑到时间因素，我们选用 RocksDB 作为日志存储。
- 状态机：可以是任何实现，其实质就是将日志中的内容进行处理。可以理解为 Mysql binlog 中的具体数据。由于我们是要实现一个 KV 存储，那么可以直接使用日志模块的 RocksDB 组件。
2 Raft 算法
2 .1 概念
Raft 算法是通过一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致。 Raft 算法是分布式系统开发首选的共识算法。
总结：通过以下几种方式来进行领导选举，保证了一个任期只有一位领导，极大减少了选举失败的情况。
- 任期
- 领导者心跳信息
- 随机选举超时时间
- 先来先服务的投票原则
- 大多数选票原则
2.2 raft角色（先简单了解，方便后续阅读）
跟随者（Follower） ：普通群众，默默接收和来自领导者的消息，当领导者心跳信息超时的时候，就主动站出来，推荐自己当候选人。
候选人（Candidate） ：候选人 将向其他节点请求投票 RPC 消息，通知其他节点来投票，如果赢得了大多数投票选票，就晋升当领导者。
领导者（Leader） ：霸道总裁，一切以我为准。处理写请求、管理日志复制和不断地发送心跳信息，通知其他节点"我是领导者，我还活着，你们不要"发起新的选举，不用找新领导来替代我。
2.3 raft想解决什么问题？
情况一：只有一个服务器，客户端向单节点服务器发送了一条更新操作，一致性非常容易保证。
情况二：如果有多个服务器节点，如何保证一致性就成为问题，假设：客户端对三个服务器节点（也可以叫数据库集群）进行更新操作，如何保证三个节点中存的值一致？
上述问题就是分布式一致问题，Raft 算法就是来解决这个问题的。在多节点集群中，在节点故障、分区错误等异常情况下，Raft 算法如何保证在同一个时间，集群中只有一个领导者呢？
2.4 选举领导
（1）初始状态：集群中所有节点都是跟随者，Term表示任期，一开始都是0。
（2）成为候选者：Raft 算法具有随机超时时间特性，每个节点等待领导者节点心跳信息的超时时间间隔是随机的，可能一个50ms（节点a），一个200ms（节点b），一个300ms(节点c),先超时的人成为候选者，a节点成为候选者，并增加自己的任期编号：把Term 值从0 更新为 1，并给自己投了一票。b，c节点的Term都等于0。
（3）投票（Leader 选举）：
- 第一步 ：节点 A 成为候选者后，向其他节点发送请求投票 RPC 信息，请它们选举自己为领导者。
- 第二步 ：节点 B 和 节点 C 接收到节点 A 发送的请求投票信息后，在编号为 1 的这届任期内，还没投票，就把选票投给节点 A，并增加自己的任期编号，Term B,C += 1。
- 第三步 ：节点 A 收到 3 次投票，得到了大多数节点的投票，从候选者成为本届任期内的新的领导者。
- 第四步 ：节点 A 作为领导者，固定的时间间隔给 节点 B 和节点 C 发送心跳信息，告诉节点 B 和 C，我是领导者，组织其他跟随者发起新的选举。
- 第五步 ：节点 B 和节点 C 发送响应信息给节点 A，告诉节点 A 我是正常的。
（4）任期：领导者是有任期的
- 自动增加 ：跟随者在等待领导者心跳信息超时后，推荐自己成为候选人，会增加自己的任期号Term += 1，如上图所示，节点 A 任期为 0，推举自己为候选人时，任期编号增加为 1。
- 更新为较大值 ：当节点发现自己的任期编号比其他节点小时，会更新到较大的编号值。比如节点 A 的任期为 1，请求投票，投票消息中包含了节点 A 的任期编号，且编号为 1，节点 B 收到消息后，会将自己的任期编号更新为 1。
- 恢复为跟随者 ：如果一个候选人或者领导者，发现自己的任期编号比其他节点小，那么它会立即恢复成跟随者状态。这种场景出现在分区错误恢复后，任期为 3 的领导者受到任期编号为 4 的心跳消息，那么前者将立即恢复成跟随者状态。
- 拒绝消息 ：如果一个节点接收到较小的任期编号值的请求，那么它会直接拒绝这个请求，比如任期编号为 6 的节点 A，收到任期编号为 5 的节点 B 的请求投票 RPC 消息，那么节点 A 会拒绝这个消息。
(5)选举规则
- 一个任期内，领导者一直都会领导者，直到自身出现问题（如宕机），或者网络问题（延迟），其他节点发起一轮新的选举。
- 在一次选举中，每一个服务器节点最多会对一个任期编号投出一张选票，投完了就没了。
(6) 大多数票才行
假设一个集群由 N 个节点组成，那么大多数就是至少 N/2+1。例如：3 个节点的集群，大多数就是 2。4个也是2.
（7）心跳超时
为了防止多个节点同时发起投票，会给每个节点分配一个随机的选举超时时间。这个时间内，节点不能成为候选者，只能等到超时。比如上述例子，节点 A 先超时，先成为了候选者。这种巧妙的设计，在大多数情况下只有一个服务器节点先发起选举，而不是同时发起选举，减少了因选票瓜分导致选举失败的情况。
2.5 领导者故障
如果领导者节点出现故障，则会触发新的一轮选举。如下图所示，领导者节点 A 发生故障，节点 B 和 节点 C 就会重新选举 Leader。
- 第一步：节点 A 发生故障，节点 B 和节点 C 没有收到领导者节点 A 的心跳信息，等待超时。
- 第二步：节点 C 先发生超时，节点 C 成为候选人。
- 第三步：节点 C 向节点 A 和节点 B 发起请求投票信息。
- 第四步：节点 C 响应投票，将票投给了 C，而节点 A 因为发生故障了，无法响应 C 的投票请求。
- 第五步：节点 C 收到两票（大多数票数），成为领导者。
- 第六步：节点 C 向节点 A 和 B 发送心跳信息，节点 B 响应心跳信息，节点 A 不响应心跳信息，因为 A 故障了。
附录：
无状态服务和有状态服务区别：
造轮子 含义："造轮子"一词在软件开发领域中通常指的是重复开发已有解决方案的行为，即当面对一个问题时，明明已经有现成的、成熟的解决方案或库可以使用，但开发者仍然选择从头开始编写自己的解决方案。
RocksDB：是一个高性能、可扩展、嵌入式、持久化的键值存储引擎，广泛应用于大数据领域。
Mysql binlog ：记录所有更改数据库数据的二进制日志文件。
状态机：
组件的生命周期：组件从被创建到挂载到页面中运行，再到组件不用时卸载的过程。
为什么要管理理以上组件的生命周期：有助于理解组件的运行方式，完成对更复杂的组件功能，分析组件的错误原因；
参考文献：
图示：分布式系统必须知道的一个共识算法：Raft-腾讯云开发者社区-腾讯云