Raft如何判断旧任期日志条目是否已提交？附场景解析

场景1：已提交日志的崩溃恢复 #

• 日志提交判定：集群共5台节点，原leader a生成的日志已复制到b、c（加上a自己共3台，超过半数），因此该日志已提交。
• 崩溃后的选举：a、b崩溃后，剩余c、d、e启动选举。c持有已提交的最新日志，根据Raft选举规则——投票者只会把票投给日志至少与自己一样新的候选人，c的日志比d、e更完整，因此能获得d或e的支持，以超过半数的票数当选新leader。
• 集群恢复：c成为leader后，会将已提交的日志复制给d、e，最终所有存活节点同步该日志，集群恢复正常服务，客户端请求结果被持久化。

场景2：未提交日志的崩溃恢复 #

• 日志提交判定：原leader a仅将日志复制到b（加上a自己共2台，未达半数），因此该日志未提交。
• 崩溃后的选举：a、e崩溃后，剩余b、c、d启动选举。b持有未提交的日志（来自原任期T），其日志最后条目任期高于c、d（c、d无该条日志，最后条目为任期T-1）。根据选举规则，c、d会给b投票，b获得3票（自身+ c + d），超过半数当选新leader。
• 日志处理：
  • b成为leader后，会尝试将未提交的日志复制给c、d，但无法直接提交该旧任期日志（Raft安全规则禁止leader直接提交旧任期日志）。
  • 若有新的客户端请求，b会生成当前任期（T+1）的日志条目，复制给c、d。当该新日志被复制到至少2台节点（c和d），满足半数以上（3/5）要求后，新日志会被提交，同时带动之前未提交的旧日志一并提交。
  • 若无新请求，b会持续尝试复制旧日志，但不会提交它，直到有当前任期的日志被提交为止。
  • 若后续a恢复上线，b会强制a同步自己的日志（包括那条未提交后被间接提交的日志），最终集群日志保持一致。

内容的提问来源于stack exchange，提问作者tlb