mit6.824 lec7 raft2

7.1 日志恢复

• 对于新的Leader刚刚上任时，其发送的AppendEntires RPC会存在prevLogIndex(槽位)与preLogTerm(任期号)
• 在Follower收到AppendEntries(其中包含了前一条Log的信息)之后，会检查本地的Log，并于新Leader发来的AppendEntries中的有关前一条Log的信息匹配。对于不匹配的Follower会将拒绝这个AppendEntries，并返回false给Leader
• 新的Leader记录了每个Follower的nextIndex，起初记录的是自己当前最新槽位，当收到了对应follower的拒绝之后，新的Leader会将对应的nextIndex缩小。对于新的AppendEntries会包含prevLogIndex之后所有的条目,这里使用的是一种备份机制
• 对于可以擦除的Log，都是由于它们没有得到过过半服务器的认可，所以旧的Leader不可能commit这条记录，对于没有commit的请求，客户端会从发请求，所以可以丢弃没有commit的请求
• 这个问题想问的应该是，为什么每次都是减少相应的nextIndex 1？对于S1，可不可以传送自己不为空的槽位号10？

7.2 选举约束

• 对于新Leader的选举存在限制，不是说第一个选举定时器超时并触发了选举的节点，就是Leader。就是说并非任意节点都可以成为Leader
• 在新的选举中，只有知道了之前任期的节点，才能够去进行选举
• 存在两个选举的约束，也就是说处理别的节点发送的RequestVote RPC时，提出赞成票的约束
  • 候选人最后一条Log条目的任期号大于本地最后一条Log条目的任期号
  • 或者，候选人的最后一条Log的任期号等于本地最后一条Log条目的任期号，且候选人的Log记录长度大于等于本地Log记录的长度？(长度不同，Log记录都不一样了鸭)
• Raft更喜欢拥有高任期号记录的候选人，或者是如果候选人都拥有任期号最高的旧Leader记录，那么Raft更喜欢拥有更多记录的候选人?(是怎么做到都拥有任期号最高的旧的Leader记录，但是却拥有更多的记录)

参考

参考