raft论文(四)

Safety

Safety章节主要讨论了，raft如何保证每个节点的状态机，以相同的顺序执行相同的命令。

上面的章节，关于raft的特性，已经讨论了Election Safety， Log Matching， Leader Append-only。接下来，我们首先看看Leader Completeness。

Leader Completeness

首先，再次回顾对Leader Completeness的定义：

如果一个日志entry在给定的任期已经被提交，
那么这个日志entry必然会出现在所有任期大于这个给定任期的leaders的日志中

关于Leader Completeness，会有两个约束（规则）

第一个约束

在选举的时候会有一个选举约束：

投票者不会给没有自己日志新的Candidate投选票。

Leader在RequestVote时，会携带自己最后一条entry的index和term，投票者会将这两个参数和自己的对比。
关于最新的定义：

1) 最后一个entry的term不同时，term大的为新；
2）最后一个entry的term相同时，index大的为新；

第二个约束

成为Leader后，Commit日志时：

Leader不会Commit当前任期之前任期的日志

（a）阶段 S1 为Leader，复制index = 2, term = 2日志到S2, 其他节点还没有复制成功；
（b）阶段S1发生崩溃，触发Leader选举：
term变成3，S5变成新的Leader。为什么S5可以被推选成新的Leader？
S3、S4可以投票给S5，S1、S2由于在index = 2处的日志比S5新，不会投票给S5，但S5仍然可以有3票当选。
S5当选后，收到来自于客户端的请求，此时会在index = 2, term = 3处追加日志，当时还没有来得及复制日志，发生了崩溃；
（c）由于S5的崩溃，触发选举：
同理term变成4，S1可以获取S2、S3、S4的选票而当选；
S1在index = 3, term=4处追加日志，开始日志复制；
S1将index = 2, term = 2的日志复制到S3，日志条目被复制到大多数的机器上，该日志条目可以被提交（也就是可以被执行），此时S1崩溃；
（d）由于S1的崩溃，触发选举：
term变成5，S5可以通过S2、S3、S4的选票而当选；
S5当选后，会覆盖其他server在index = 2的日志，这样错误就发生了。
为什么说错误发生了？
index = 2, term = 3的日志覆盖了大部分机器上存在的index = 2, term = 2的entry，也就是S1执行过的命令被覆盖。
对于c->d过程中可能产生的错误，raft的做法是：
对于c中index =2, term = 2的日志，因为当前的term = 4, 对于不属于当前term的entry，raft不会根据是否复制到半数以上节点原则来决定是否提交，只有对属于当前term的entry，才会采用这一原则来决定是否提交。
也就是（e）中的，index = 2, term = 2的日志被复制到多数节点后，这个日志还不会提交；只有index = 3, term = 4可以被提交时，index = 2的日志才可以被提交。这样就不会发生S1离线，日志被覆盖的情况。

问题一：

过程(b)中，S2是否会给S5投票？
不会(Election restriction)。
S5的RequestVote RPC为：

	RequestVoteArg {
		Term = 3,
    	CandidateId = me,   // me指自身的节点id
    	LastLogIndex = 1,
    	LastLogTerm = 1,
	}

S2收到S5的请求后，会做如下check：

	//如下是S2最新的日志，这个日志可能是一个committed日志，也可能是一个没有committed的日志
	lastIndex = 2;
	lastTerm = 2;
	// Election restriction
	if arg.LastLogTerm < lastTerm {
		return false;
	}
	if arg.LastLogTerm == lastTerm  && arg.LastLogIndex < lastIndex {
		return false;
	}

基于以上准则，无论S2的第二条日志是否committed，都不会投票给S5

问题二：

index = 3, term = 4可以被提交后，index = 2的日志才可以被提交是什么意思？，index = 2, term = 2是如何被应用的状态机的？

在(e)中S1重新被选举为Leader后：

nextIndex[i] = 3; // 即日志长度的下一个index；

当新的日志条目index = 3, term = 4到达后，开始复制日志，以向S3复制日志为例：

AppendEntryArg {
	term = 4,
	LeaderId = me,
	PrevLogIndex = 2, 
	PrevLogTerm = 2,
	entry = log[3],
}

即会在参数中，携带自身上次同步日志的位置。
在S3侧，自身的日志信息为：

lastIndex = 1;
if lastIndex < arg.PrevLogIndex {
	reply.ConflictIndex = lastIndex + 1;
	return fasle;
}

即会检测到日志的不一致(一致性检查， Log Matching)
S1拿到了日志不一致的问题，会重新Append Entries，且会将从冲突开始的日志，都发送给S3

AppendEntryArg {
	term = 4,
	LeaderId = me,
	PrevLogIndex = 1, 
	PrevLogTerm = 1,
	entry = log[2], log[3],
}

S3收到了新的AppenEntries后，此时一致性检查通过，会append 2条entry
到自己的日志中，且直接更新自己的commitIndex = 3, 此时自己的lastApplied = 1,因此会apply两条entry。