Lab2 RAFT整体架构

[toc]
花了将近一个月的时间，总算做完了lab2，期间做到lab2C的Unreliable Figure8卡住了，重构了一遍代码，最终才通过。

经验教训: 回想了一下做的过程，我的方法是按着lab2的要求去读论文，并不是读完论文理解完再去做lab2，没有一种全局的理解就开始写代码，就会导致代码架构很乱，对功能的增删困难，并且一开始的一些细节一开始没有考虑到，当进行到2C的Figure8测试时，测试量和代码量太大，日志上万行，且修改后牵一发而动全身。往往改着改着lab2B就出问题了。还有就是student guide十分重要，最好看完一遍后再开始编码!

整体设计

lab2涉及的raft协议总共分为三个部分，选举模块，日志同步模块，持久化模块。后续将从这三个部分进行总结。

在开始前，需要根据论文中的Figure 2对全局结构进行一个分析。

我设计的server的组成结构如下图所示，一共有3种状态(state)，4个线程(AE，RV，Apply，新日志请求)，7个变量(state，currentTerm，voteFor，log[]，commitIndex，matchIndex[]，nextIndex[])，状态其实也是一种变量。在server中通过各个线程改变变量。

raft_server.png

Server中变量的解释

currentTerm和state变量

currentTerm永远是单调递增的，且只有两种情况会currentTerm会增加。

1. 在收到的RPC中，发现Term > currentTerm，currentTerm = Term
2. 开始新一轮选举，每一个Term内只会有一个Leader，所以在新的一轮选举中，currentTerm++。

state变量:

Follower状态

1. currentTerm变大，Term > currentTerm
   currentTerm只会受到外部server的影响，所在AE handle 和RV handle中一旦currentTerm受到改变，server的状态就进入Follower，重置选举超时。
2. 在1不成立的情况下，收到Leader发送的心跳，此时收到的Term == currentTerm，转变为Follower，重置选举超时。

Candidate状态

只有当在Follower状态经历选举超时或Candidate状态选举超时后，才会转变成Candidate状态，重置选举超时。

Leader状态

只有当Candidate获得大多数选票后才会转变为Leader状态。

状态改变的比喻描述

currentTerm相当于整个协议中的时代信息(当每个时代稳定后(选举结束)，每个server都有自己的身份在当前时代不会改变，若要改变，那么必定需要开启一个新的时代)。
在一个新的时代中(Term)，群雄并起(某些Follower成为了Candidate)，每个军阀都争取着民心(发送RV RPC请求Follower投票，每个Follower只会支持一个军阀)，当某个军阀获得了大多数民心时(获得大多数选票)，那他就顺理成章的成为了皇帝(Leader)，这时每隔一段时间就会对其他军阀(需要放弃军权)/民众进行警告，不要再想着争权并需要他们都成为跟随者(发送AE RPC告诉Follower/Candidate已经有Leader了)。
某个时候，皇帝发送的警告消息由于自然灾害在路上延迟或者丢失了，这时民众们就觉得皇帝驾崩了，就会想着开辟一个新的时代自己称王，一切从零开始(Term增加)。于是又出现了群雄并起的时代，旧皇帝的所有消息都已经是没有震慑力了，为了保命，需要归顺于一个军阀(Leader收到了Term比它大的消息，转变为Follower并投票给它)。

log相关变量(commitIndex, lastApplied, matchIndex[], nextIndex[])

nextIndex与matchIndex

在AE send中根据nextIndex[i]对server_i发送相应的同步AppendEntries RPC，AppendEntries RPC中携带着Leader需要同步的日志，如果与Follower的同步成功后，那么Leader就在AE reply中更新nextIndex[i]和matchIndex[i]。
在做到宕机之前，总会出现matchIndex[i] = nextIndex[i]-1，所以可能会觉得matchIndex没有用。但是宕机恢复后，当前服务器会丢失已经匹配的日志信息，所以会出现nextIndex[i] = len(log)，matchIndex[i] = 0，这时候matchIndex[i] != nextIndex[i]-1。

commitIndex和lastApplied

matchIndex[i]更新后，说明server_i已经同步到了第i个日志了，如果大多数server都已经同步到第i个日志，那说明该日志可以提交，commitIndex增1，对应的apply thread判断lastApplied是否小于commitIndex，来判定是否要上传该日志。这里有个细节需要注意，当前Leader不能单独提交上一个Term中的日志，需要和当前Term的日志一起提交，否则就会出现Figure 8 中 c->e的场景(已经committed的日志2丢失)。

RPC的处理

server之间通信的方式只有以下两种RPC的形式，每个RPC中都会携带Term，server永远只会处理Term >= currentTerm的RPC，若Term < currentTerm那说明该RPC是过期的RPC，可以说Term就是消息的序列号(网络延迟，过期就作废，但信息并不会因此丢失，因为一旦没有reply，那么对应的就会重发这条消息)

同步兼心跳/AppendEntries RPC

日志总是从Leader流向Follower，意思是日志的改变总是Leader来触发的，Follower本身不会去改变日志内容。

AE send

只有Leader会间断性的发送AppendEntries RPC。其中nextIndex[i]是下一串准备同步的日志的起点，因此

1. preLogIndex = nextIndex[i]-1
2. preLogITerm = log[nextIndex[i]-1].Term
3. entries = log[nextIndex[i] : ]
4. term = currentTerm，leaderId = me，leaderCommit = commitIndex。
   当 i == me时，需要特殊处理下。

AE handle

涉及Follower状态的变更和日志的同步。

AE handle流程图

AE reply

涉及Leader的nextIndex和matchIndex的修改，状态变更

AE reply流程图

选举过程 / RequestVote RPC

选举超时后，状态转变为Candidate，并且currentTerm自增，投票给自己，已获得投票数为1。

RV send

必须是Candidate状态，携带的参数如下所示:

1. term = currentTerm, candidateId = me
2. lastLogIndex = len(log)-1, lastLogTerm = log[len(log)-1].Term

对于自身就不用发送投票了。

RV handle

已经投过票这个点就包含了判断server是不是Candidate的条件，因为一旦成为Candidate就会给自己投票，当走到日志是否是最新时，Term == currentTerm。

RV handle流程图

RV reply

该过程主要是判断是否可以获得选票，注意这是个并发的过程。

RV reply流程图

Apply thread

需要特别注意当前Leader不能单独提交上一个Term的日志。否则会出现Figure 8 c->e的情况。

Apply 流程图