Raft on 你怂你mua

Mit lab3B个人笔记

Wed, 01 Apr 2026 00:00:00 +0000

lab3B实验中主要实现的功能是raft的日志复制功能，建议多看几遍关于raft日志复制功能的过程。

原文pdf:http://nil.csail.mit.edu/6.5840/2024/papers/raft-extended.pdf

源码地址：https://github.com/liusir521/mit6.5840

实验要求

实现领导者和追随者代码以追加新的日志条目，以便go test -run 3B测试通过。

实验中的要求看似就一句话并不多，但是我们需要考虑很多细节上的东西，以及针对日志不同步的情况的处理等等。个人感觉3B难就难在细节太多，不是一下子就可以想全面的，所以这里才说需要多看几遍raft的日志复制功能的讲解。

我之前的关于分布式共识算法中也有关于raft日志复制相关的描述，这里再粘贴一下：

Raft 算法中，领导者通过广播消息（AppendEntries RPC）将日志条目复制到所有跟随者。AppendEntries RPC 的示例如下：

{
  "term": 5, // 领导者的任期号
  "leaderId": "leader-123",
  "prevLogIndex": 8, // 前一日志条目的索引
  "prevLogTerm": 4, // 前一日志条目的任期
  "entries": [
    { "index": 9, "term": 5, "command": "set x=4" }, // 要复制的日志条目
  ],
  "leaderCommit": 7// Leader 的“已提交”状态的日志条目索引号
}

当 Raft 集群收到客户端请求（例如 set x=4）时，日志复制的过程如下：

若当前节点非领导者，将请求转发至领导者；
领导者接收请求后：
- 将请求转化为日志条目，写入本地存储系统，初始状态为“未提交”（uncommitted）；
- 生成日志复制消息（AppendEntries RPC），并广播至所有跟随者；
跟随者收到日志复制消息后，验证任期（确保本地任期不大于领导者任期）、日志一致性（通过 prevLogIndex 检查日志是否匹配）。若验证通过，跟随者将日志条目追加至本地存储系统，并发送确认响应；
领导者确认日志条目已成功复制至多数节点后，将其状态标记为“已提交”（committed），并向客户端返回结果。已提交的日志条目不可回滚，指令永久生效，且可安全地“应用”（apply）至状态机。

领导者向客户端返回结果，并不意味着日志复制过程已完全结束，跟随者尚不清楚日志条目是否已被大多数节点确认。Raft 的设计通过心跳或后续日志复制请求中携带更新的提交索引（leaderCommit），通知跟随者提交日志。此机制将“达成共识的过程”优化为一个阶段，减少了客户端约一半的等待时间。

我们来看日志复制的另一种情况。在上述例子中，只有 follower-1 成功追加日志，follower-2 因为日志不连续，追加失败。日志的连续性至关重要，如果日志条目没有按正确顺序应用到状态机，各个 follower 节点的状态肯定不一致。

日志不连续的问题是这样解决的：follower-2 收到日志复制请求后，它会通过 prevLogIndex 和 prevLogTerm 检查本地日志的连续性。如果日志缺失或存在冲突，follower-2 返回失败响应，指明与领导者日志不一致的部分。

{
  "success": false,
  "term": 4,
  "conflictIndex": 4, // 表示发生缺失的日志索引，Follower 的日志中最大索引为 3，所以缺失的索引是 4。
  "conflictTerm": 3//缺失日志的“上一个有效日志条目”的任期号
}

当领导者收到失败响应，根据 conflictIndex 和 conflictTerm 找到与跟随者日志的最大匹配索引（例如，6）。随后，领导者从该索引开始重新向跟随者（如 follower-2）发送日志条目，逐步修复日志的不一致性，直至同步完成。

OK，再看一遍raft的日志复制流程，才发现需要实现的功能确实不少。感觉3B确实可以算hard。

代码设计

好的，接下来讲讲我的代码设计。

首先，我本来准备延用3A中的设计思路，但是思考之下发现了一些问题，比如心跳机制，我在3A中设计的是当节点成为领导者之后再启动这个协程，但是在3B中，心跳函数中还需要实现一些额外的功能，如推进日志的应用等，再把心跳放到选举之后反而会增加代码的复杂度。

所以，我在Make函数初始化时便启动了这个心跳函数，如果当前节点是领导者时，会进行日志检测、同步日志的功能。

初始化

在3B中，也需要在raft结构体中添加一些额外的字段，来满足日志同步的需求，对领导者和跟随者来说，二者都需要已提交的日志的索引字段和已应用的日志的索引字段，对领导者来说，还需要额外定义一个切片来记录对每个跟随者下一个要发送的日志的索引，同时还需要另外一个切片来实现记录每个跟随者已经匹配的最大日志的索引。

初始化时便启动计时器和心跳函数。选举流程基本和3A没什么变动。

type Raft struct {
	mu        sync.Mutex          // Lock to protect shared access to this peer's state
	peers     []*labrpc.ClientEnd // RPC end points of all peers
	persister *Persister          // Object to hold this peer's persisted state
	me        int                 // this peer's index into peers[]
	dead      int32               // set by Kill()

	currentTerm       int           // 当前任期
	votedFor          int           // 投票给的节点
	log               []LogEntry    // 日志
	state             int           // 当前节点状态：跟随者、候选者、领导者
	applyCh           chan ApplyMsg // 应用通道
	lastAppliedID     int           // 已应用的 ID
	commitIndex       int           // 已提交的索引
	lastheartbeattime time.Time     // 最后一次收到心跳的时间
	nextIndex         []int         // 对每个 follower，下一个要发送的 log index
	matchIndex        []int         // 对每个 follower，已经匹配的最大 index
}

type LogEntry struct {
	Command any // 命令
	Term    int // 日志的任期
}

const (
	FOLLOWER  = iota // 跟随者
	CANDIDATE        // 候选者
	LEADER           // 领导者
)

const (
	UnCommitted = iota // 未提交
	Committed          // 已提交
	Applied            // 已应用
)

func Make(peers []*labrpc.ClientEnd, me int,
	persister *Persister, applyCh chan ApplyMsg) *Raft {
	rf := &Raft{}
	rf.peers = peers
	rf.persister = persister
	rf.me = me

	// Your initialization code here (3A, 3B, 3C).
	rf.currentTerm = 0
	rf.votedFor = -1
	rf.state = FOLLOWER // 初始状态都为跟随者
	rf.lastheartbeattime = time.Now()
	rf.applyCh = applyCh
	rf.lastAppliedID = 0 // 已应用的索引，从0开始（表示还没有应用任何日志）
	rf.commitIndex = 0   // 已提交的索引，从0开始（表示还没有提交任何日志）
	rf.log = make([]LogEntry, 1)
	rf.log[0] = LogEntry{Term: 0}
	// 初始化领导者状态
	rf.nextIndex = make([]int, len(peers))
	rf.matchIndex = make([]int, len(peers))
	for i := range rf.nextIndex {
		rf.nextIndex[i] = len(rf.log) // 初始下一个要发送的索引是当前日志长度
		rf.matchIndex[i] = 0          // 初始已匹配的索引是0
	}

	// initialize from state persisted before a crash
	rf.readPersist(persister.ReadRaftState())

	// 计时器守护进程，检测到超时后，开始选举，投自己
	go rf.ticker()
	go rf.heartbeatLoop()

	return rf
}

// 心跳循环
func (rf *Raft) heartbeatLoop() {
	for !rf.killed() {
		time.Sleep(100 * time.Millisecond)

		rf.mu.Lock()
		if rf.state == LEADER {
			term := rf.currentTerm

			// 持续推进 commitIndex
			rf.updateCommitIndex()

			rf.mu.Unlock()

			for i := range rf.peers {
				if i != rf.me {
					go rf.sendAppendEntriesToPeer(i, term)
				}
			}
		} else {
			rf.mu.Unlock()
		}
	}
}

日志同步

设置日志的入口函数其实是Start函数，在Start函数中，如果当前节点是领导者，就将新日志写入到日志存储字段中，然后触发广播复制日志的函数，将复制日志的消息广播给跟随者，根据返回消息的情况进行处理。

不过触发日志复制的时机在心跳函数中也存在，所以其实是否在Start函数中推进commitIndex都可以，当时在这里推进是想到可能刚好写完日志之后遇到心跳检测将这个日志进行了同步，然后这里直接推进并应用能更省事，其实这里是否推进并没有太大的关系，因为这个刚好写完就遇到心跳检测毕竟是小概率，两种情况测试都能通过的。

在日志同步的过程中，会有许多细节上的问题，首先，需要进行二次状态检测，防止信息发送未执行时发生了选举，其次在构建entry切片时，如果当前没有新的日志，就发送空切片，代表心跳。然后在发送append rpc请求前是需要释放锁的，防止rpc阻塞导致的死锁。然后根据响应查看是否存在缺失日志，存在则修改下标，在下次发送时进行同步。

关键代码如下：

// 领导者向其他节点发送 AppendEntries 请求，server代表跟随者节点
func (rf *Raft) sendAppendEntriesToPeer(server int, term int) {
	rf.mu.Lock()

	// 二次检查状态，不是领导者直接退出
	if rf.state != LEADER || term != rf.currentTerm {
		rf.mu.Unlock()
		return
	}

	// 确保 nextIndex 不越界
	if rf.nextIndex[server] > len(rf.log) {
		rf.nextIndex[server] = len(rf.log)
	}

	nextIdx := rf.nextIndex[server]
	prevLogIndex := nextIdx - 1

	// 获取 prevLogTerm
	prevLogTerm := 0
	if prevLogIndex >= 0 && prevLogIndex < len(rf.log) {
		prevLogTerm = rf.log[prevLogIndex].Term
	}

	// 构建 entries 切片
	var entries []LogEntry
	if nextIdx < len(rf.log) {
		entries = append([]LogEntry{}, rf.log[nextIdx:]...)
	} else {
		entries = []LogEntry{}
	}

	args := AppendEntriesArgs{
		Term:         rf.currentTerm,
		LeaderId:     rf.me,
		PrevLogIndex: prevLogIndex,
		PrevLogTerm:  prevLogTerm,
		Entries:      entries,
		LeaderCommit: rf.commitIndex,
	}

	rf.mu.Unlock()

	// 在发送rpc请求时，需要先解锁，避免死锁
	reply := AppendEntriesReply{}
	ok := rf.sendAppendEntries(server, &args, &reply)

	if !ok {
		return
	}

	rf.mu.Lock()
	defer rf.mu.Unlock()

	// 再次检查状态
	if rf.state != LEADER || term != rf.currentTerm {
		return
	}

	// term 过期
	if reply.Term > rf.currentTerm {
		rf.currentTerm = reply.Term
		rf.state = FOLLOWER
		rf.votedFor = -1
		rf.persist()
		return
	}

	if reply.Success {
		rf.matchIndex[server] = args.PrevLogIndex + len(args.Entries)
		rf.nextIndex[server] = rf.matchIndex[server] + 1
	} else {
		if reply.ConflictIndex != -1 {
			rf.nextIndex[server] = reply.ConflictIndex
		} else {
			rf.nextIndex[server]--
		}

		if rf.nextIndex[server] < 1 {
			rf.nextIndex[server] = 1
		}
	}

	// 更新 commitIndex
	rf.updateCommitIndex()
}

// 更新 commitIndex
func (rf *Raft) updateCommitIndex() {
	for N := len(rf.log) - 1; N > rf.commitIndex; N-- {
		count := 1

		// 统计日志索引 N 是否被大多数节点提交
		for i := range rf.peers {
			if i != rf.me && rf.matchIndex[i] >= N {
				count++
			}
		}

		// 如果大多数节点都已提交到 N 索引位置，且 N 索引位置的日志任期与当前任期相同，则推进 commitIndex
		if count > len(rf.peers)/2 && rf.log[N].Term == rf.currentTerm {
			rf.commitIndex = N
			go rf.applyLogs()
			break
		}
	}
}

// 日志进行应用
func (rf *Raft) applyLogs() {
	for {
		rf.mu.Lock()

		// 如果 lastAppliedID 已经大于等于 commitIndex，则没有日志需要应用
		if rf.lastAppliedID >= rf.commitIndex {
			rf.mu.Unlock()
			return
		}

		rf.lastAppliedID++
		msg := ApplyMsg{
			CommandValid: true,
			Command:      rf.log[rf.lastAppliedID].Command,
			CommandIndex: rf.lastAppliedID,
		}

		rf.mu.Unlock()

		rf.applyCh <- msg
	}
}

// 领导者发送日志请求结构体
// AppendEntriesreq
type AppendEntriesArgs struct {
	Term         int
	LeaderId     int
	PrevLogIndex int
	PrevLogTerm  int
	Entries      []LogEntry // 日志条目
	LeaderCommit int        // Leader 的“已提交”状态的日志条目索引号
}

// AppendEntriesReply
type AppendEntriesReply struct {
	Term          int
	Success       bool
	ConflictIndex int // 表示发生缺失的日志索引
	ConflictTerm  int // 缺失日志的“上一个有效日志条目”的任期号
}

// 领导者发送日志请求
func (rf *Raft) sendAppendEntries(server int, args *AppendEntriesArgs, reply *AppendEntriesReply) bool {
	ok := rf.peers[server].Call("Raft.AppendEntries", args, reply)
	return ok
}

// 在3A中只需要实现心跳功能即可，3B中需要实现日志复制
func (rf *Raft) AppendEntries(args *AppendEntriesArgs, reply *AppendEntriesReply) {
	rf.mu.Lock()
	defer rf.mu.Unlock()

	reply.Term = rf.currentTerm
	reply.Success = false

	// 初始化
	reply.ConflictIndex = -1
	reply.ConflictTerm = -1

	// term 检查
	if args.Term < rf.currentTerm {
		return
	}

	// 更新为 follower
	if args.Term > rf.currentTerm {
		rf.currentTerm = args.Term
		rf.votedFor = -1
		rf.state = FOLLOWER
	}

	rf.lastheartbeattime = time.Now()

	// prevLogIndex 不存在，返回缺失的日志索引
	if args.PrevLogIndex >= len(rf.log) {
		reply.ConflictIndex = len(rf.log)
		return
	}

	// term 不匹配，寻找错误日志的索引和任期
	if args.PrevLogIndex >= 0 &&
		rf.log[args.PrevLogIndex].Term != args.PrevLogTerm {

		reply.ConflictTerm = rf.log[args.PrevLogIndex].Term

		i := args.PrevLogIndex
		for i > 0 && rf.log[i-1].Term == reply.ConflictTerm {
			i--
		}
		reply.ConflictIndex = i
		return
	}

	// append entries

	index := args.PrevLogIndex + 1 // 跟随者开始对齐的位置
	i := 0                         // 领导者发送的日志条目下标

	// 寻找冲突日志的索引位置
	for ; i < len(args.Entries); i++ {
		if index+i < len(rf.log) {
			if rf.log[index+i].Term != args.Entries[i].Term {
				// 如果存在任期不匹配的日志，进行截断
				rf.log = rf.log[:index+i]
				break
			}
		} else {
			break
		}
	}

	// 将剩余的日志条目添加到跟随者日志中
	if i < len(args.Entries) {
		rf.log = append(rf.log, args.Entries[i:]...)
	}

	// 更新 commitIndex 和 lastAppliedID 索引并应用日志
	if args.LeaderCommit > rf.commitIndex {
		rf.commitIndex = min(args.LeaderCommit, len(rf.log)-1)
		go rf.applyLogs()
	}

	reply.Success = true
	rf.persist()
}

func (rf *Raft) Start(command interface{}) (int, int, bool) {
	rf.mu.Lock()
	defer rf.mu.Unlock()

	if rf.state != LEADER {
		return -1, rf.currentTerm, false
	}

	index := len(rf.log)
	term := rf.currentTerm

	rf.log = append(rf.log, LogEntry{
		Command: command,
		Term:    term,
	})

	// leader 自己的 matchIndex 必须更新
	rf.matchIndex[rf.me] = len(rf.log) - 1

	rf.persist()

	// 立即尝试 commit
	// rf.updateCommitIndex()

	// 触发复制
	go rf.broadcastAppendEntries()

	return index, term, true
}

// 触发复制
func (rf *Raft) broadcastAppendEntries() {
	rf.mu.Lock()
	term := rf.currentTerm
	rf.mu.Unlock()

	for i := range rf.peers {
		if i == rf.me {
			continue
		}
		go rf.sendAppendEntriesToPeer(i, term)
	}
}

其中需要对某个节点发送的日志的下标是在rf.nextIndex[server]中，包括如果说某个server的日志不匹配，修改的也是rf.nextIndex[server]的值，在发送时根据此下标进行获取相关日志。

运行结果

测试结果如下：

Mit lab3A个人笔记

Mon, 30 Mar 2026 00:00:00 +0000

对raft算法不熟悉的可以参考我之前记录过的分布式共识算法文章

https://liusir521.github.io/p/%E5%88%86%E5%B8%83%E5%BC%8F%E5%85%B1%E8%AF%86%E7%AE%97%E6%B3%95/

源码地址：https://github.com/liusir521/mit6.5840

实验要求

Lab3实验中要我们复刻raft算法，并由易到难的分为了4个部分，对应着raft算法中的三个关键点，领导者选举、日志复制以及安全性，当前是3A部分，对应的是领导者选举的部分。

3A任务要求：实现 Raft 领导者选举和心跳机制（使用 AppendEntries RPC，不记录日志）。第 3A 部分的目标是：选举出一个领导者，在没有故障的情况下保持领导者地位，并在旧领导者发生故障或与旧领导者之间的数据包丢失时，由新的领导者接管。运行 go test -run 3A来测试你的第 3A 部分代码。

关键点：

要实现心跳机制，请定义一个 AppendEntries RPC 结构体（尽管您可能暂时不需要所有参数），并让领导者定期发送这些参数。编写一个 AppendEntries RPC 处理方法。
测试人员要求领导者每秒发送心跳 RPC 的次数不得超过 10 次。
测试人员要求你的 Raft 在旧领导者失效后的 5 秒钟内选出新的领导者（如果大多数同伴仍然可以沟通）。

代码设计

在写代码之前建议先结合实验要求过一下代码，加深一下对代码中定义的理解。在我第一眼看到代码的时候，我有一个很大的疑惑，就是Raft结构体是给每个节点使用的，还是说相当于是一个中间调配者的角色，在我结合着代码阅读了几遍实验要求之后，才意识到其实每个节点都是一个Raft结构体实例。（在config.go文件中也可以看出cfg.rafts = make([]*Raft, cfg.n)，用于测试文件中的初始化）

在3A中，我们需要实现的功能并不复杂，主要是领导者选举。这意味着我们只需要先定义好相关的结构体，然后在Make函数中进行初始化之后(初始化默认节点是跟随者)，等待领导者发送心跳包即可，如果在规定时间内未收到，就进入选举过程，当某个节点完成选举成为主节点后，再继续向其他节点发送心跳包确认即可。(其中心跳包暂时使用AppendEntries函数实现)

初始化

需要我们在Raft结构体中完善相关的定义，关键字段包括当前任期、当前节点的身份以及最后一次收到心跳的时间等等。然后在Make函数中进行初始化。

关键代码如下：

type Raft struct {
	mu        sync.Mutex          // Lock to protect shared access to this peer's state
	peers     []*labrpc.ClientEnd // RPC end points of all peers
	persister *Persister          // Object to hold this peer's persisted state
	me        int                 // this peer's index into peers[]
	dead      int32               // set by Kill()

	// Your data here (3A, 3B, 3C).
	// Look at the paper's Figure 2 for a description of what
	// state a Raft server must maintain.

	currentTerm       int        // 当前任期
	votedFor          int        // 投票给的节点
	log               []LogEntry // 日志
	state             int        // 当前节点状态：跟随者、候选者、领导者
	lastheartbeattime time.Time  // 最后一次收到心跳的时间
}

type LogEntry struct {
	Command any // 日志内容
	Term    int // 日志的任期
}

const (
	FOLLOWER  = iota // 跟随者
	CANDIDATE        // 候选者
	LEADER           // 领导者
)

func (rf *Raft) GetState() (int, bool) {
	rf.mu.Lock()
	defer rf.mu.Unlock()
	return rf.currentTerm, rf.state == LEADER
}

func Make(peers []*labrpc.ClientEnd, me int,
	persister *Persister, applyCh chan ApplyMsg) *Raft {
	rf := &Raft{}
	rf.peers = peers
	rf.persister = persister
	rf.me = me

	// Your initialization code here (3A, 3B, 3C).
	rf.currentTerm = 0
	rf.votedFor = -1
	rf.log = make([]LogEntry, 0)
	rf.state = FOLLOWER // 初始状态都为跟随者
	rf.lastheartbeattime = time.Now()

	// initialize from state persisted before a crash
	rf.readPersist(persister.ReadRaftState())

	// 计时器守护进程，检测到超时后，开始选举，投自己
	go rf.ticker()

	return rf
}

选举

在初始化时，起初应该都是跟随者，当某个跟随者等待心跳包超时之后就会发起选举，进入选举流程，然后通过rpc请求向除了自己之外的在peers数组中的其他节点发送选举请求，如果获得了多数派的同意，就成为领导者，成为领导者之后向其他跟随者发送心跳包，如果收到了任期比自己大的则变为跟随者。

// 发送心跳的sendHeartbeat函数忘记粘贴了，建议自己实现一下。
func (rf *Raft) ticker() {
	for rf.killed() == false {
		// pause for a random amount of time between 50 and 350
		// milliseconds.
		ms := 50 + (rand.Int63() % 300)
		time.Sleep(time.Duration(ms) * time.Millisecond)

		rf.mu.Lock()

		// Your code here (3A)
		// Check if a leader election should be started.

		// 只有 follower 和 candidate 才需要检查选举超时
		if rf.state == FOLLOWER || rf.state == CANDIDATE {
			electionTimeout := 150 + rand.Int63n(150) // 150-300ms 随机超时
			if time.Since(rf.lastheartbeattime) > time.Duration(electionTimeout)*time.Millisecond {
				// 超时，开始选举
				rf.startElection()
				// startElection 会重置 electionStart，所以这里不需要重复设置
			}
		}

		rf.mu.Unlock()

	}
}

func (rf *Raft) startElection() {
	// 任期+1，状态为候选者
	rf.currentTerm++
	rf.state = CANDIDATE
	rf.votedFor = rf.me               // 投给自己
	rf.lastheartbeattime = time.Now() // 重置选举超时时间
	rf.persist()

	// 获取最后一条日志的索引和任期
	lastLogIndex := len(rf.log) - 1
	lastLogTerm := 0
	if lastLogIndex >= 0 {
		lastLogTerm = rf.log[lastLogIndex].Term
	}

	args := &RequestVoteArgs{
		Term:         rf.currentTerm,
		CandidateId:  rf.me,
		LastLogIndex: lastLogIndex,
		LastLogTerm:  lastLogTerm,
	}

	votesReceived := 1 // 记录收到的投票数
	var mu sync.Mutex

	// 向除了自己之外的所有节点发送投票请求
	for i := 0; i < len(rf.peers); i++ {
		if i == rf.me {
			continue
		}

		go func(server int) {
			reply := &RequestVoteReply{}
			ok := rf.sendRequestVote(server, args, reply)

			mu.Lock()
			defer mu.Unlock()

			if !ok {
				return
			}

			// 如果成功且收到投票，则记录
			if reply.VoteGranted {
				rf.mu.Lock()
				if args.Term == rf.currentTerm && rf.state == CANDIDATE {
					votesReceived++

					// 获得大多数的投票，转换成领导者
					if votesReceived > len(rf.peers)/2 {
						rf.state = LEADER
						rf.lastheartbeattime = time.Now()
						go rf.sendHeartbeat()
					}
				}
				rf.mu.Unlock()
			}

			// 如果收到新的任期大于当前任期，则转换成跟随者
			if reply.Term > rf.currentTerm {
				rf.mu.Lock()
				if reply.Term > rf.currentTerm {
					rf.currentTerm = reply.Term
					rf.state = FOLLOWER
					rf.votedFor = -1
					rf.lastheartbeattime = time.Now()
					rf.persist()
				}
				rf.mu.Unlock()
				return
			}

		}(i)
	}
}

// 共用发送投票请求
func (rf *Raft) sendRequestVote(server int, args *RequestVoteArgs, reply *RequestVoteReply) bool {
	ok := rf.peers[server].Call("Raft.RequestVote", args, reply)
	return ok
}

// 选举rpc函数
func (rf *Raft) RequestVote(args *RequestVoteArgs, reply *RequestVoteReply) {
	rf.mu.Lock()
	defer rf.mu.Unlock()

	reply.Term = rf.currentTerm
	reply.VoteGranted = false
	rf.lastheartbeattime = time.Now()

	// 如果请求中的任期小于当前任期，拒绝投票
	if args.Term < rf.currentTerm {
		return
	}

	// 如果当前任期小于请求的任期，更新任期并转为跟随者
	if args.Term > rf.currentTerm {
		rf.currentTerm = args.Term
		rf.votedFor = -1
		rf.state = FOLLOWER
	}

	// 如果尚未投票，或者是已经投给CandidateId，则校验日志进行投票
	if args.Term == rf.currentTerm &&
		(rf.votedFor == -1 || rf.votedFor == args.CandidateId) {

		// 检查日志
		lastLogIndex := len(rf.log) - 1
		lastLogTerm := 0
		if lastLogIndex >= 0 {
			lastLogTerm = rf.log[lastLogIndex].Term
		}

		candidateLogUpToDate := (args.LastLogTerm > lastLogTerm) ||
			(args.LastLogTerm == lastLogTerm && args.LastLogIndex >= lastLogIndex)

		if candidateLogUpToDate {
			reply.VoteGranted = true
			rf.votedFor = args.CandidateId
		}
	}

	rf.persist()
}

测试结果

测试如图所示