raft协议数据结构和RPC设计

1. 状态机

从中我们可以得到几个我们需要实现的过程

不论是一个节点位于哪种形态，都必须具备这些数据结构，其中一些是该节点独有的信息，而更多是关于集群的日志同步相关的

参数	解释
currentTerm	服务器当前已知最新的term，初始化为0，单调增加
voteFor	当前任期内收到选票的候选人id，如果不投票则为-1
NodeID	当前节点在集群中的ID，全局唯一
[]log	日志条目，每个条目包含了用于状态机的命令，以及领导者接收到该条目的term、index信息
commitIndex	已知已提交的最高的日志条目的索引（提交到大多数节点），单调递增
lastApplied	已经被应用到状态机的最高的日志条目的索引，单调递增

其实 commitIndex 和 lastApplied 可以看做是 []log 数组中的两个指针，表明了有多少日志被集群提交了，有多少已经被应用到状态机了

其实在这里可以发现，已经应用到状态机的日志是不必继续保存的，后面会有一个快照机制，既可以压缩数据又可以迅速向新节点同步数据

我们可以简单梳理一下 []log 的结构：

观察 []log 的结构，我们可以发现一个日志所包含的基础字段，分别是 command、term、index

term就是同步这条日志的 leader 的 term ，index是一个全局单调递增的数字，用于和 term 标识唯一的 leader，并配合 lastApplied 和 commitIndex 使用

那么 lastApplied和commitIndex 是什么关系呢？

lastAppiled <= commitIndex，二者中间日志就是已经提交到集群，但还没有应用到状态机的

这里就会有一个关于更新lastApplied的问题，当 lastApplied < commitIndex 时，lastApplied +1，并把 log[lastApplied] 应用到状态机

以上的这些数据基本都记录的是单机信息，raft 中最重要的日志同步，也就是 leader 向 follower 同步日志时需要怎么做呢？

其实每个 leader，或者说每个节点，因为每个节点都有可能成为 leader，都会存在两个数组，用于向 follower 同步日志

参数	解释
[]nextIndex	对于每一台服务器，发送到该服务器的下一个日志条目的索引（初始值为领导者最后的日志条目索引+1）
[]matchIndex	对于每一台服务器，已知的已经复制到该服务器的最高日志条目的索引（初始值为0，单调递增）

其实简单来说就是：对于每一个follower，leader应该知道它要发给这个节点哪些日志

最简单的 raft 算法实现需要两个RPC：日志追加/心跳RPC和选举投票RPC

其中日志追加RPC是由 leader 发送给 follower，选举投票RPC是由 candidate 发送给 candidate 和 follower

在选举定时器超时后，follower 会转为 candidate，然后开启选举投票RPC

这个RPC请求的关键是让其他节点给自己投票，那么需要的请求参数就必须要表明该 candidate有成为一个 leader 的资格

发起投票请求的简单逻辑如下：

candidate 的请求参数主要包括了：

在其他节点收到投票请求后，主要会做一下term和index的校验：

那么响应结构应该怎么设计？最简单的响应只需要两个返回值

参数	解释
term	当前任期号，以便于candidate发现更大的term从而转为follower，不要影响投票
voteGranted	是否为该candidate投票

日志追加和心跳可以何合为一个RPC是因为当日志中没有 command 就可以当成心跳来发送

leader 调用该RPC的时机主要有以下几个情况：

下面只简单说一下日志追加的过程

一旦成为 leader，发送空的附加日志RPC给其他所有的服务器，在一定的空余时间之后不停地重复发送，阻止 follower 选举定时器超时
如果接收到客户端写请求，附加条目到本地日志中，在条目被应用到状态机后响应客户端
如果对一个跟随者，最后日志条目的索引大于或者等于 nextIndex，那么 leader 会发送从nextIndex开始的所有日志条目
如果成功，更新 follower 的nextIndex 和 matchIndex
如果因为日志不一致而失败，减小 nextIndex 重试
如果存在一个满足 N > commitIndex 的 N，并且大多数的matchIndex[i] >= N 成立，并且 log[N].term == currentTerm 成立，那么令 commitIndex等于这个N

在请求参数中，需要包含以下几个部分：

参数	解释
term	当前leader的任期
leaderID	当前leader的id，主要用于跟随者对客户端进行重定向
prevLogIndex	紧邻新日志条目之前的那个条目的索引
prevLogTerm	紧邻新日志条目之前的那个条目的任期
[]entries	需要被保存的日志条目
leaderCommit	领导者的已知已提交的最高的日志条目的索引

当 follower 收到日志追加或者心跳RPC时，会进行日志相关的操作

如果 leader 的任期小于自己，那么返回自己的任期，并拒绝日志，之后就会开始新一轮的 leader 选举了
在 follower 日志中，如果能找到一个和 prevLogIndex 和 prevLogTerm 匹配的日志条目，则继续执行，否则拒绝日志，做冲突处理
如果一个已经存在的条目和新条目发生了冲突，则删除这个已经存在的条目以及它之后的所有条目
追加日志中尚未存在的任何新条目
如果 leader 的已知的已经提交的最高日志索引 leaderCommit 大于自己的，则 follower 把已知的已经提交的最高日志条目索引 commitIndex重置为 leaderCommit和最新日志条目索引的最小值

所以在响应结构的设计中，主要包括了以下几部分：

参数	解释
term	当前已知的最大任期
success	是否匹配index和term，并接受了日志
conflictLogIndex	和prevLogIndex不匹配的的log index
conflictLogTerm	和prevLogTerm不匹配的的log term