持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第18天，点击查看活动详情
Raft协议
- 是什么：
- Paxos 论证了一致性协议的可操作性，只是很难理解它的论证过程，只是一个方向性的理论，缺少必要的实现细节；
- 不太容易具体实现，难度比较大, zookeeper的 zab 协议就是基于这一协议的实现。
- 虽然Paxos协议的出现为分布式强一致性提供了很好的理论基础，但是Paxos协议理解起来较为困难， 实现比较复杂。随后有了易理解的分布式一致性复制协议 Raft。
- Java， C++，Go 等都有其对应的实现之后出现的Raft相对要简洁很多。
- 具体方式为引入主节点概念，通过竞选的方式确定主节点。
- 节点类型：Follower、Candidate 和 Leader；
- Leader 会周期性的发送心跳包给 Follower。
- 每个 Follower 都设置了一个随机的竞选超时时间，如果在这个时间内没有收到 Leader 的心跳包，就会变成 Candidate，进入竞选 阶段, 通过竞选阶段的投票多的人成为Leader
- 节点介绍
- 节点状态 Leader：接受 client 更新请求，写入本地后，然后同步到其他副本中；
- Follower（从节点）：从 Leader 中接受更新请求，然后写入本地日志文件。对客户端提供读 请求
- Candidate（候选节点）：如果 follower 在一段时间内未收到 leader 心跳。则判断 leader 可能故障，发起选主提议。节点状态从 Follower 变为 Candidate 状态，直到选主结束 2
- termId：团队id号，时间被划分成一个个任期，每次选举后都会产生一个新的 termId，一个任期内 只有一个 leader。
- . RequestVote：请求投票，candidate 在选举过程中发起，收到多数派响应后，成为 leader。
选举流程
-
节点间通讯方式 Raft里，服务器节点间沟通联络采用的是远程过程调用（RPC），在领导选举中，需要用到两类RPC：
- 请求投票，由候选人在选举期间发起，通知各个节点进行投票
- 日志复制，由leader发起，用来复制日志和提供心跳检查作用；
-
Leader的作用周期
Raft算法中的Leader是存在生命周期的；存在一个投票的编号epoch，类似于选票一样
- 跟随者在等待领导者心跳信息超时后，推举自己为候选人，会增加自己的任期号。
- 一个服务器节点若检测到自己任期编号比其他节点小，更新自己的编号到较大的编号值
- 若一个候选人或者领导者检测到自己任期编号比其他节点小，会将自己恢复成跟随着状态。所以，raft不处理这种接电状态。
- 选举周期内某个节点接收到一个比自己小的编号值的请求，那么它会直接拒绝这个请求。
