Mit 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()
}

测试结果

测试如图所示

Mit lab1个人笔记

Wed, 25 Mar 2026 00:00:00 +0000

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

前言

久闻mit6.824大名，一直没找到合适的时机进行实操，最近在工作之余对此课程进行了学习。这篇文章总结一下个人学习lab1时的一些心得体会。

lab1简介

在本实验中，你将构建一个 MapReduce 系统。你将实现一个工作进程，该进程调用应用程序的 Map 和 Reduce 函数并处理文件的读写操作；以及一个协调器进程，该进程将任务分配给工作进程并处理故障的工作进程。

实验中给出了很多细节上的方案与提示，建议先多看几遍实验任务。

流程介绍：我们需要通过多个Map任务去读取系统给出的文件中的单词，并根据单词的key的hash值将其归入指定的中间文件中(mr-X-Y)，当所有的Map任务均处理完毕之后，启动Reduce任务，每个Reduce任务会找到自己对应的中间文件并对内部的单词进行统计，最后输出到对应的文件中(mr-out-Y)。

流程图如下：

其中X代表的是map任务的编号，Y代表的是reduce任务的编号

总体设计

总体需要我们来实现的其实并不是关于KeyValue键值对的处理，这部分可以参考示例中给出的代码，无需我们再次实现，只需在原本单机场景之下改写为多任务模式即可。主要需要我们实现的是关于任务的分配处理代码。主要包括三部分：

rpc：定义实验中所需要的关于rpc通讯用到的相关结构体
Worker：定义工作进程相关的代码
Coordinator：起到协调作用，定义关于任务分配等相关的具体实现

具体实现

Coordinator

Coordinator中需要我们定义整体任务分配相关的结构体，从原有的函数中可以看出还需要我们实现rpc被调用方的相关函数，包括获取任务、完成任务以及Coordinator初始化。同时官方给出需要进行超时校验(10s)，我们还需要在获取任务时进行超时校验。

关于Coordinator结构体我们需要定义的关键内容有：

files：文件数组，用于分配给各个map任务执行，每个map对应一个文件，所以map的总任务数其实就是文件总数
nReduce：系统指定的reduce任务的总数
mapTasks：map的任务列表
reduceTasks：reduce的任务列表
isMapFinished：map任务是否全部完成的标志
isReduceFinished：reduce任务是否全部完成的标志，只有map任务全部完成之后才会启动reduce任务，reduce任务全部完成之后也就标志的整体流程结束
sync.Mutex：同理需要一个锁对象来控制流程（也可以对map和reduce分别设置，这里简便实现只设置一个）

关于Task任务结构体我们需要定义的关键内容有：

TaskType：任务类型，map or reduce
TaskStatus：任务状态，等待中、运行中、已完成
NReduce：系统NReduce变量，用于map任务中对应的key流向哪个文件（hash之后对NReduce取余）
MapTaskIndex：如果是map任务，当前map任务的编号
ReduceTaskIndex：如果是reduce任务，当前reduce任务的编号
FileName：如果是map任务，当前map任务要处理的文件名

我这里只是一个粗略的设计，有很多地方可以进行优化，比如可以添加map、reduce还未完成的数量，通过原子类操作数量的方式会比我这里使用遍历的方式更加的合理。锁也可以设计为两个，在超时校验时或许可以再节省一些时间。

获取任务

在获取任务时，需要首先判断是否存在超时文件，然后接着首先判断是否需要分配map任务，先把map任务分配完毕，然后才是reduce任务，当reduce任务也执行完毕，就返回退出标志。（当map任务都在执行，reduce任务尚未开启，此时返回等待标志。reduce任务都在执行时也是）

关键代码如下：

type Coordinator struct {
	// Your definitions here.
	mu               sync.Mutex // 共用锁
	files            []string
	nReduce          int
	mapTasks         []Task // map任务列表
	reduceTasks      []Task // reduce任务列表
	isMapFinished    bool   // map任务是否完成
	isReduceFinished bool   // reduce任务是否完成
	nextTaskId       int
}

// 任务结构体
type Task struct {
	TaskID          int
	TaskType        int
	TaskStatus      int // 当前任务状态
	NReduce         int // map任务需要知道分配到多少个reduce任务
	MapTaskIndex    int
	ReduceTaskIndex int
	FileName        string
	StartTime       time.Time // 用于判断超时
}

// Your code here -- RPC handlers for the worker to call.

// 获取任务
func (c *Coordinator) GetTask(args *GetTaskReq, reply *GetTaskReply) error {

	c.mu.Lock()
	defer c.mu.Unlock()

	// 判断是否所有任务均完成
	if c.isMapFinished && c.isReduceFinished {
		reply.TaskType = ExitTask
		return nil
	}

	// 判断是否有超时任务
	c.checkTimeoutTask()

	// 判断map任务是否都完成
	if !c.isMapFinished {
		for i, task := range c.mapTasks {
			// 如果存在map waiting任务，则将其改为running，并返回给worker执行
			if c.mapTasks[i].TaskStatus == Waiting {
				reply.TaskID = task.TaskID
				reply.TaskType = task.TaskType
				reply.FileName = task.FileName
				reply.NReduce = task.NReduce
				reply.ReduceID = task.ReduceTaskIndex
				c.mapTasks[i].TaskStatus = Running
				c.mapTasks[i].StartTime = time.Now()
				return nil
			}
		}
		reply.TaskType = WaitingTask
		return nil
	}

	// 到这里说明map任务已经完成，判断reduce任务是否都完成
	if !c.isReduceFinished {
		for i, task := range c.reduceTasks {
			// 如果存在reduce waiting任务，则将其改为running，并返回给worker执行
			if c.reduceTasks[i].TaskStatus == Waiting {
				reply.TaskID = task.TaskID
				reply.TaskType = task.TaskType
				reply.AllMapNum = len(c.mapTasks)
				reply.ReduceID = task.ReduceTaskIndex
				c.reduceTasks[i].TaskStatus = Running
				c.reduceTasks[i].StartTime = time.Now()
				return nil
			}
		}

	}

	reply.TaskType = WaitingTask
	return nil
}

// 查看是否存在任务超时
func (c *Coordinator) checkTimeoutTask() {
	// 超时时间 10s
	timeout := 10 * time.Second

	// 如果 map 任务已经完成，则返回
	// if c.isMapFinished {
	// 	return
	// }
	// 这里不可以直接return，会导致下面的reduce任务无法判断

	now := time.Now()

	if !c.isMapFinished {
		for i := 0; i < len(c.mapTasks); i++ {
			task := c.mapTasks[i]
			// 判断正在执行的任务是否存在超时的
			if task.TaskStatus == Running && now.Sub(task.StartTime) > timeout {
				// 如果存在，将状态改为 waiting，等待其他 worker 来执行
				c.mapTasks[i].TaskStatus = Waiting
				// 这里不需要修改任务的time，后面检测到waiting时，会重新标记时间
				// return 不 return，继续判断下一个任务，否则每次只标记到了一个任务就返回了
			}
		}
	}

	// 如果 reduce 任务已经完成，则返回
	// 这里可以直接return，代表全部任务执行完毕
	if c.isReduceFinished {
		return
	}
	for i := 0; i < len(c.reduceTasks); i++ {
		task := c.reduceTasks[i]
		// 存在超时任务
		if task.TaskStatus == Running && now.Sub(task.StartTime) > timeout {
			// 将状态改为 waiting，等待其他 worker 来执行
			c.reduceTasks[i].TaskStatus = Waiting
			// 这里不需要修改任务的time，后面检测到waiting时，会重新标记时间
			// return
		}
	}
}

func MakeCoordinator(files []string, nReduce int) *Coordinator {

	c := Coordinator{
		files:            files,
		nReduce:          nReduce,
		mapTasks:         make([]Task, len(files)),
		reduceTasks:      make([]Task, nReduce),
		nextTaskId:       0,
		isMapFinished:    false,
		isReduceFinished: false,
	}

	// map任务初始化
	for i, file := range files {
		c.mapTasks[i] = Task{
			TaskID:       i,
			TaskType:     MapTask,
			TaskStatus:   Waiting,
			NReduce:      nReduce,
			MapTaskIndex: i,
			FileName:     file,
			StartTime:    time.Now(),
		}
		c.nextTaskId++
	}

	// reduce任务初始化
	for i := 0; i < nReduce; i++ {
		c.reduceTasks[i] = Task{
			TaskID:          i,
			TaskType:        ReduceTask,
			TaskStatus:      Waiting,
			ReduceTaskIndex: i,
		}
		c.nextTaskId++
	}

	c.server()
	return &c
}

刚开始时，我在校验超时时间中犯了个逻辑错误，我先校验了map任务是否都已经完成了，完成之后我直接return了，这个操作就导致了后面超时函数无法校验到reduce任务的状态(是否存在超时任务)，就导致最后一个测验一直无法通过。

完成任务

在完成任务中，我们需要判断当前完成的任务的类型，然后判断是否当前所有类型的任务都完成了。关键代码如下：

// 完成任务
func (c *Coordinator) CompleteTask(args *CompleteTaskReq, reply *CompleteTaskReply) error {
	c.mu.Lock()
	defer c.mu.Unlock()

	// 完成map任务
	switch args.TaskType {
	case MapTask:
		// map任务完成
		// 判断所有map任务是否完成

		allmapfinished := true
		for i, task := range c.mapTasks {
			if args.TaskID == task.TaskID {
				c.mapTasks[i].TaskStatus = Finished
			} else if task.TaskStatus != Finished {
				allmapfinished = false
			}
		}
		// 所有map任务完成
		c.isMapFinished = allmapfinished
	case ReduceTask:
		// 完成reduce任务
		// 检测reduce任务是否完成
		if c.isReduceFinished {
			return nil
		}

		allreducefinished := true
		for i, task := range c.reduceTasks {
			if args.TaskID == task.TaskID {
				c.reduceTasks[i].TaskStatus = Finished
			} else if task.TaskStatus != Finished {
				allreducefinished = false
			}
		}
		c.isReduceFinished = allreducefinished
	}

	return nil
}

rpc

rpc.go文件中主要是对实验中需要用到的rpc相关的请求和响应的相关结构体，关键代码如下：

// 任务类型枚举定义
const (
	MapTask = iota
	ReduceTask
	WaitingTask // 任务正在执行，此时需要task等待
	ExitTask    // map、reduce任务已经执行完毕，退出信号
)

// task任务状态枚举定义
const (
	Waiting = iota
	Running
	Finished
)

// 获取任务请求
type GetTaskReq struct {
	WorkerID int
}

// 获取任务响应
type GetTaskReply struct {
	TaskID     int
	TaskType   int // 当收到ExitTask时，结束标志
	FileName   string
	AllMapNum  int // 一共有多少map任务，用于reduce过程，其实相当于map处理文件的个数，一个map任务对应一个文件
	ReduceID   int // 当前reduce任务负责的分区编号
	NReduce    int
	TaskStatus int
}

// 完成任务请求
type CompleteTaskReq struct {
	TaskType int
	TaskID   int
}

// 完成任务响应
type CompleteTaskReply struct {
}

其中，GetTaskReply就是获取task任务的响应结构体，根据tasktype字段判断当前任务是map任务还是reduce任务，然后再从里面获取需要使用到的字段。

Worker

在worker中，需要我们通过rpc向调度器获取任务并执行具体的任务，当任务执行完毕时通过rpc向调度器汇报。其中具体的执行任务流程可以参考示例中给出的代码。关于文件的操作，可以使用课程中提示的中间文件的形式。

关键代码如下：

// 请求任务并执行
func Worker(mapf func(string, string) []KeyValue, reducef func(string, []string) string) {

	// Your worker implementation here.
	for {

		workerid := os.Getpid()
		reply := getWorkerTask(workerid)

		switch reply.TaskType {
		case MapTask:
			startMapTask(workerid, reply, mapf)
		case ReduceTask:
			startReduceTask(workerid, reply, reducef)
		case WaitingTask:
			// 休眠0.5秒
			time.Sleep(500 * time.Millisecond)
			continue
		case ExitTask:
			return
		}
	}
	// uncomment to send the Example RPC to the coordinator.
	// CallExample()

}

// for sorting by key.
type ByKey []KeyValue

// for sorting by key.
func (a ByKey) Len() int           { return len(a) }
func (a ByKey) Swap(i, j int)      { a[i], a[j] = a[j], a[i] }
func (a ByKey) Less(i, j int) bool { return a[i].Key < a[j].Key }

func startReduceTask(workerid int, reply GetTaskReply, reducef func(string, []string) string) {
	// 根据传入的reduceNum确定所负责的任务index
	// 然后去所有map产出的文件中找到对应index的文件进行reduce

	kva := []KeyValue{}

	for i := 0; i < reply.AllMapNum; i++ {
		curfilename := fmt.Sprintf("mr-%d-%d", i, reply.ReduceID)

		file, err := os.Open(curfilename)
		if err != nil {
			log.Fatalf("reduce cannot open %v", file)
		}

		dec := json.NewDecoder(file)
		for {
			var kv KeyValue
			if err := dec.Decode(&kv); err != nil {
				break
			}
			kva = append(kva, kv)
		}
		file.Close()
	}

	// 对结果进行排序
	sort.Sort(ByKey(kva))

	tempfile, err := os.CreateTemp("", "mr-out-tmp-*")
	if err != nil {
		log.Fatal("create tempfile err", err)
	}

	// 参考示例代码处理键值对
	i := 0
	for i < len(kva) {
		j := i + 1
		for j < len(kva) && kva[j].Key == kva[i].Key {
			j++
		}
		values := []string{}
		for k := i; k < j; k++ {
			values = append(values, kva[k].Value)
		}
		output := reducef(kva[i].Key, values)

		// this is the correct format for each line of Reduce output.
		fmt.Fprintf(tempfile, "%v %v\n", kva[i].Key, output)

		i = j
	}

	tempfile.Close()

	err = os.Rename(tempfile.Name(), fmt.Sprintf("mr-out-%d", reply.ReduceID))

	if err != nil {
		log.Fatal("rename err", err)
	}

	completeTask(reply.TaskID, reply.TaskType)
}

// Map任务
func startMapTask(workerid int, reply GetTaskReply, mapf func(string, string) []KeyValue) {
	// 首先读取文件kv，并根据kv的hash分配到不同的切片中
	// 然后使用临时文件的方式，将这些kv存入对应的临时文件，最后写入对应的reduce文件中

	// 读取文件内容参考示例文件
	filename := reply.FileName

	file, err := os.Open(filename)
	if err != nil {
		log.Fatalf("map cannot open %v %v", filename, err)
	}
	content, err := io.ReadAll(file)
	if err != nil {
		log.Fatalf("cannot read %v", filename)
	}
	file.Close()
	kva := mapf(filename, string(content))
	// intermediate = append(intermediate, kva...)
	// 示例文件给出的是单机版本，这里需要实现并发版本

	intermediate := make([][]KeyValue, reply.NReduce)

	for _, kv := range kva {
		// 计算hash并分配
		index := ihash(kv.Key) % reply.NReduce
		intermediate[index] = append(intermediate[index], kv)
	}

	// 临时文件方式存储
	for i := 0; i < reply.NReduce; i++ {
		tempfile, err := os.CreateTemp("", "mr-tmp-*")
		if err != nil {
			log.Fatal("create tempfile err", err)
		}

		// 使用推荐的json包处理kv
		encoder := json.NewEncoder(tempfile)
		for _, kv := range intermediate[i] {
			err := encoder.Encode(&kv)
			if err != nil {
				log.Fatal("json write tempfile err", err)
			}
		}
		tempfile.Close()
		reducename := fmt.Sprintf("mr-%d-%d", reply.TaskID, i)
		os.Rename(tempfile.Name(), reducename)
	}
	// 汇报任务执行完成
	completeTask(reply.TaskID, MapTask)
}

// 通过rpc获取任务
func getWorkerTask(workerID int) GetTaskReply {
	// rpc获取任务
	req := GetTaskReq{
		WorkerID: workerID,
	}

	reply := GetTaskReply{}

	call("Coordinator.GetTask", &req, &reply)

	return reply
}

// 汇报任务完成
func completeTask(taskid, tasktype int) {
	req := CompleteTaskReq{
		TaskID:   taskid,
		TaskType: tasktype,
	}

	reply := CompleteTaskReply{}

	call("Coordinator.CompleteTask", &req, &reply)
}

总结

个人感觉，实验主要还是考验的思维逻辑能力，而不是一些细节实现，毕竟一些关键实现实验中已经提供了。

代码执行结果如下：

Mit lab2个人笔记

Wed, 25 Mar 2026 00:00:00 +0000

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

简介

实验二要求我们实现一个单机版的键值服务器，并实现Get\Put\Append方法。需要考虑的重点是多个客户端并发访问的问题以及由于网络原因导致的客户端请求重试问题（幂等性）。

实验二其实并不难，针对Get操作我们不需要做过多的处理，主要是Put和Append操作。我们只需要在服务端定义好存储客户端id与该客户端请求id的对应关系，以及客户端id和上次缓存的结果即可(用于Append请求)。

代码实现

客户端

客户端的代码主要在client.go文件中，该文件中需要我们完善Clerk客户端结构体，其中我们需要添加clientID以及requestID即可，文件中已经提供了相关的函数，我们只需要在每次Put请求和Append请求成功时增加requestID即可。


type Clerk struct {
	server *labrpc.ClientEnd
	clientID  int64
	requestID int64
	mu        sync.Mutex
}

func nrand() int64 {
	max := big.NewInt(int64(1) << 62)
	bigx, _ := rand.Int(rand.Reader, max)
	x := bigx.Int64()
	return x
}

func MakeClerk(server *labrpc.ClientEnd) *Clerk {
	ck := &Clerk{
		clientID:  nrand(),
		requestID: 0,
	}
	ck.server = server
	return ck
}

func (ck *Clerk) Get(key string) string {

	args := GetArgs{Key: key}
	var reply GetReply
	for {
		ok := ck.server.Call("KVServer.Get", &args, &reply)
		if ok {
			return reply.Value
		} else {
			time.Sleep(100 * time.Millisecond)
		}
	}
}

func (ck *Clerk) PutAppend(key string, value string, op string) string {
	args := PutAppendArgs{
		ClientId:  ck.clientID,
		Key:       key,
		Value:     value,
		RequestId: ck.requestID,
	}
	var reply PutAppendReply
	for {
		ok := ck.server.Call("KVServer."+op, &args, &reply)
		if ok {
			ck.mu.Lock()
			ck.requestID++
			ck.mu.Unlock()
			return reply.Value
		} else {
			time.Sleep(100 * time.Millisecond)
		}
	}
}

func (ck *Clerk) Put(key string, value string) {
	ck.PutAppend(key, value, "Put")
}

func (ck *Clerk) Append(key string, value string) string {
	return ck.PutAppend(key, value, "Append")
}

rpc定义

关于rpc的定义位于common.go文件中，代码如下：

// Put or Append
type PutAppendArgs struct {
	Key   string
	Value string
	// You'll have to add definitions here.
	// Field names must start with capital letters,
	// otherwise RPC will break.
	ClientId  int64
	RequestId int64
}

type PutAppendReply struct {
	Value string
}

type GetArgs struct {
	Key string
	// You'll have to add definitions here.
}

type GetReply struct {
	Value string
}

服务端

服务端需要我们修改KVServer结构体来满足Append请求，具体代码如下：


type KVServer struct {
	mu sync.Mutex

	// Your definitions here.
	data                map[string]string
	lastclientrequestid map[int64]int64
	lastclientresponse  map[int64]string // 记录每个客户端上次请求的返回值，只用于Append方法
}

func (kv *KVServer) Get(args *GetArgs, reply *GetReply) {
	// Your code here.
	kv.mu.Lock()
	defer kv.mu.Unlock()
	reply.Value = kv.data[args.Key]
}

func (kv *KVServer) Put(args *PutAppendArgs, reply *PutAppendReply) {
	// Your code here.
	kv.mu.Lock()
	defer kv.mu.Unlock()
	lastReqId, exists := kv.lastclientrequestid[args.ClientId]
	if !exists || args.RequestId > lastReqId {
		kv.lastclientrequestid[args.ClientId] = args.RequestId
		kv.data[args.Key] = args.Value
	}
}

func (kv *KVServer) Append(args *PutAppendArgs, reply *PutAppendReply) {
	// Your code here.
	kv.mu.Lock()
	defer kv.mu.Unlock()
	lastReqId, exists := kv.lastclientrequestid[args.ClientId]
	if !exists || args.RequestId > lastReqId {
		// 新请求，执行追加
		oldvalue := kv.data[args.Key]
		kv.lastclientrequestid[args.ClientId] = args.RequestId
		kv.data[args.Key] += args.Value
		reply.Value = oldvalue
		// 更新记录值
		kv.lastclientresponse[args.ClientId] = oldvalue
	} else {
		// 重复请求，返回上次记录的响应值
		reply.Value = kv.lastclientresponse[args.ClientId]
	}
}

func StartKVServer() *KVServer {
	kv := &KVServer{
		data:                make(map[string]string),
		lastclientrequestid: make(map[int64]int64),
		lastclientresponse:  make(map[int64]string),
	}

	return kv
}

测试结果

结果如下