Raft 算法 - 一致性算法
Raft 算法 - 一致性算法
一、简介
Raft 是一个共识算法（consensus algorithm），所谓共识，就是多个节点对某个事情达成一致的看法，即使是在部分节点故障、网络延时、网络分割的情况下依然有效。
Raft 算法是分布式系统开发首选的共识算法，是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。
此外，类似的算法还有大名鼎鼎的 Paxos。
二、应用场景
主要用来处理容错和一致性需求的场景。比如分布式配置系统、分布式 NoSQL 存储等等，轻松突破系统的单机限制。
比如：现在流行的 Etcd、Consul。
三、Raft 角色
跟随者：Follower，普通群众，接收来自领导者的消息，当领导者心跳信息超时的时候，就主动站出来，推荐自己当候选人。
候选者：Candidate，候选人，候选者将向其他节点请求投票 RPC 消息，通知其他节点来投票，如果赢得了大多数投票选票，就晋升为领导者。
领导者：Leader，霸道总裁，一切以我为准，处理写请求、管理日志复制和不断地发送心跳信息，通知其他节点“我是领导者，我还活着，你们不要发起新的选举，不用找新领导来替代我”。
Raft 要求系统在任意时刻最多只有一个 Leader，正常工作期间只有 Leader 和 Followers。
Raft 算法是通过一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致。
注意：领导者是有任期，一个任期只有一位领导，即某个节点是某一届的领导，每一届领导都可能不同。
四、Leader 选举
选举过程
1、初始跟随者：集群中所有节点都是跟随者的状态，并且任期都为0。
2、成为候选者：Raft 算法实现了随机超时时间的特性，每个节点等待领导者节点心跳信息的超时时间间隔是随机的。
这就必然有跟随者最先发起选举，首先增加自己的任期编号，并给自己投票，从而成为候选者。
3、投票选举：
候选者向其他节点发送请求投票 RPC 信息，请他们选举自己为领导者。
其他节点收到请求后，判断在新任期内还没有进行过投票，则投票给候选者。
候选者收到超过半数的投票后，成为新的领导者。
4、心跳保持
领导者以固定时间间隔给跟随者发送心跳，告知跟随者领导者仍然存活；
跟随者发送响应给领导者告知自身状态正常。
五、关键机制
- 任期（term）
- 领导者心跳信息
- 随机选举超时时间
- 先来先服务的投票原则
- 大多数选票原则
1、任期（term）
任期（term），领导者是有任期的。
自动增加：跟随者在等待领导者心跳信息超时后，推荐自己为候选人，会增加自己的任期号。
更新为较大值：当节点发现自己的任期编号比其他节点小时，会更新到较大的编号值。
恢复为跟随者：如果一个候选人或者领导者，发现自己的任期编号比其他节点小，那么它会立即恢复成跟随者状态。这种场景出现在分区错误恢复后。
拒绝消息：如果一个节点接收到较小的任期编号值的请求，那么它会直接拒绝这个请求。
2、选举规则
- 一个任期内，领导者一直都会领导者，直到自身出现问题（如宕机），或者网络问题（延迟），其他节点才发起一轮新的选举。
- 在一次选举中，每一个服务器节点最多会对一个任期编号投出一张选票。
3、大多数选票原则
即候选者得到的选票要超过投票总数的一半以上才能晋升为领导者。
假设一个集群由 N 个节点组成，那么大多数就是至少 N/2+1。
举例：3 个节点的集群，大多数就是 2。
4、心跳超时
为了防止多个节点同时发起投票，会给每个节点分配一个随机的选举超时时间。
这个时间内，节点不能成为候选者，只能等到超时。最先超时的节点，先成为候选者。
这种巧妙的设计，能确保在大多数情况下只有一个服务器节点先发起选举，而不是同时发起选举，减少了因选票瓜分导致选举失败的情况。
参考资料
Raft Understandable Distributed Consensus
