2023年 mit 6.824 lab2D-快照机制

最新推荐文章于 2024-10-17 20:29:41 发布
最新推荐文章于 2024-10-17 20:29:41 发布
阅读量356 收藏
点赞数
分类专栏： mit 6.824分布式系统实现 mit6.824 lab1~lab4 文章标签： golang 后端 分布式 共识算法
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_57467091/article/details/134897666
版权

lab2D

到现在实现的最艰难的一个lab

论文总结

直接看论文, 论文算是精华了.

实现思路

lab2D中需要我们实现的东西如下：

实现Snapshot()方法

  • 注意点1：快照点不能超过应用点

    该方法由应用层调用，应用层来决定何时对节点进行快照，而测试脚本中是每隔10条日志就进行一次快照。快照时需要注意，在lab2D前面的实现中，是把已提交和已应用的两个阶段通过条件变量分开的，中间这个间隙可能会被快照然后裁减掉未应用未提交甚至已提交的日志，这样可能会少了一些日志。为了保证在快照时，论文中的“已提交的日志一定会被应用到状态机”的特性，在快照时需要判断当前快照点是否超过了应用点，如果没有超过，说明可以快照；如果超过了应用点，就不能裁减log，防止前面提到的问题发生。

  • 注意点2：如果当前快照点小于等于上一次快照点，没有必要快照了

  • 注意点3：持久化的过程中，需要保证最新的快照和最新的raft持久化状态，一起持久化，保证原子性.

    这点在persist()方法的注释中有提到。为此我给raft添加了snapshot字段用来表示raft持有的最新快照，调用persist()方法的时候，将快照一并持久化，从而保证原子性。

func (rf *Raft) Snapshot(index int, snapshot []byte) {
	// Your code here (2D).
	rf.mu.Lock()
	defer rf.mu.Unlock()
	defer func() {
		Debug(dSnap, "after Snapshot, S%d status{currentTerm:%d,commitIndex:%d,applied:%d,snapshotIndex:%d,lastIncludedIndex:%d,log_len:%d}",
			rf.me, rf.currentTerm, rf.commitIndex, rf.lastApplied, index, rf.lastIncludedIndex, len(rf.log)-1)
	}()

	if rf.lastApplied < index /*快照点超过应用点无效,必须等待日志被应用过后才能对其快照，防止应用日志前被裁减了*/ ||
		rf.lastIncludedIndex >= index /*快照点如果小于前一次快照点，没有必要快照*/ {
		return
	}

	defer rf.persist()
	// 丢弃被快照了的日志，同时修改其他状态
	// last: snap{nil,1,2,3} {nil}
	// now:  snap{nil,1,2,3,4,5} {nil,4,5}
	split := rf.logIndex(index)
	rf.lastIncludedIndex = index
	rf.log = append([]Logt{{Term: rf.log[split].Term}}, rf.log[split+1:]...)
	rf.snapshot = snapshot
}
实现InstallSnapshot()方法

这个方法的时候，论文已经说的很明白了，实现起来问题不大。只是有些coner case可能在实现的时候会与论文说的有差别（这种只有debug了）。lab2D的要求我们去除安装快照的分片实现，只需要单次发送就可以了。这里总结一下实现步骤：

  1. 如果term < currentTerm就立即回复（过期leader请求没必要处理）

  2. 创建一个新的快照

  3. 保存快照文件，丢弃具有较小索引的任何现有或部分快照

    这句话的意思是: 比较对等点的快照和leader发过来的安装快照. 要丢弃较小的快照点, 保留最大的快照点.

  4. 如果现存的日志条目与快照中最后包含的日志条目具有相同的索引值和任期号，则保留其后的日志条目并进行回复

    这句话的意思是: 可能包含了leader的安装快照之后的新的状态变化，我们需要保留这些, 并且return.（中文翻译的bug…qwq，不注意看可能会理解错误）

  5. 丢弃整个日志

    如果在第4步没有return的话, 说明现存的日志条目与快照中最后不包含的日志条目具有相同的索引值和任期号, 也就是说, 当前log是过期的. 没有必要留存,直接删除掉

  6. 使用快照重置状态机（并加载快照的集群配置）

除了论文和lab tips中的实现点以外，还有一些小的coner case需要注意：

  • leader安装快照的过程请求了对等点, 算是一次ping/pong, 可以刷新选举计时器以及重新置为follower
  • 如果对等点任期落后, 那么依然可以继续后面的步骤, 但是需要重置旧任期的选票和更新任期
  • 使用Copy-on-Write的技术优化
// 不分片
type InstallSnapshotArgs struct {
	Term              int    // 领导人的任期号
	LeaderId          int    // 领导人的 ID，以便于跟随者重定向请求
	LastIncludedIndex int    // 快照中包含的最后日志条目的索引值
	LastIncludedTerm  int    // 快照中包含的最后日志条目的任期号
	Data              []byte // 从偏移量开始的快照分块的原始字节
}

type InstallSnapshotReply struct {
	Term int // 当前任期号（currentTerm），便于领导人更新自己
}

func (rf *Raft) InstallSnapshot(args *InstallSnapshotArgs, reply *InstallSnapshotReply) {
	rf.mu.Lock()
	defer rf.mu.Unlock()
	defer func() {
		Debug(dSnap, "after InstallSnapshot, S%d status{currentTerm:%d,commitIndex:%d,applied:%d,lastIncludedIndex:%d,log_len:%d}",
			rf.me, rf.currentTerm, rf.commitIndex, rf.lastApplied, rf.lastIncludedIndex, len(rf.log)-1)
	}()

	//1. 如果`term < currentTerm`就立即回复
	if args.Term < rf.currentTerm /*请求的领导者过期了，不能安装过期leader的快照*/ {
		reply.Term = rf.currentTerm
		return
	}

	if args.Term > rf.currentTerm /*当前raft落后，可以接着安装快照*/ {
		rf.currentTerm, rf.votedFor = args.Term, noVote
	}

	rf.changeRole(follower)
	rf.electionTimer.Reset(withRandomElectionDuration())

	//5. 保存快照文件，丢弃具有较小索引的任何现有或部分快照
	if args.LastIncludedIndex <= rf.lastIncludedIndex /*raft快照点要先于leader时，无需快照*/ {
		reply.Term = rf.currentTerm
		return
	}

	defer rf.persist()

	rf.lastIncludedIndex = args.LastIncludedIndex
	rf.log[0].Term = args.LastIncludedTerm
	rf.commitIndex = args.LastIncludedIndex
	rf.lastApplied = args.LastIncludedIndex
	rf.snapshot = args.Data
	msg := ApplyMsg{
		SnapshotValid: true,
		Snapshot:      args.Data,
		SnapshotTerm:  args.LastIncludedTerm,
		SnapshotIndex: args.LastIncludedIndex,
	}
	//6. 如果现存的日志条目与快照中最后包含的日志条目具有相同的索引值和任期号，则保留其后的日志条目并进行回复
	for i := 1; i < len(rf.log); i++ {
		if rf.realIndex(i) == args.LastIncludedIndex && rf.log[i].Term == args.LastIncludedTerm {
			rf.log = append([]Logt{{Term: args.LastIncludedTerm}}, rf.log[i+1:]...)
			go func() {
				rf.applyMsg <- msg
			}()

			reply.Term = rf.currentTerm
			return
		}
	}
	//7. 丢弃整个日志（因为整个log都是过期的）
	rf.log = []Logt{{Term: args.LastIncludedTerm}}
	//8. 使用快照重置状态机（并加载快照的集群配置）
	go func() {
		rf.applyMsg <- msg
	}()

	reply.Term = rf.currentTerm
	return
}
调用时机

论文中说的很明确了: 有可能follower处理得太慢或者新加入集群, 由于前面的日志被快照了, 那么leader就无法在log中找到要发送给follower的日志了, 只能发送快照过去.

lab2D中给了一个tips: Even when the log is trimmed, your implemention still needs to properly send the term and index of the entry prior to new entries in AppendEntries RPCs; this may require saving and referencing the latest snapshot’s lastIncludedTerm/lastIncludedIndex (consider whether this should be persisted).

发送日志复制RPC的请求参数中的LastIncludedIndex和LastIncludedTerm在快照机制出现过后, 可能存在这样一种边界情况. 下面是心跳逻辑中处理leader该发送日志复制RPC还是快照安装RPC的代码逻辑:

if rf.nextIndex[peer] <= rf.lastIncludedIndex /*存在于快照中，发送安装快照RPC*/ {
    args := &InstallSnapshotArgs{
        Term:              rf.currentTerm,
        LeaderId:          rf.me,
        LastIncludedIndex: rf.lastIncludedIndex,
        LastIncludedTerm:  rf.log[0].Term,
        Data:              rf.snapshot,
    }

    Debug(dLog, `sendInstallSnapshot S%d -> S%d, LastIncludedIndex:%d,LastIncludedTerm:%d`,
        rf.me, peer, args.LastIncludedIndex, args.LastIncludedTerm)

    go rf.handleSendInstallSnapshot(peer, args)
} else /*存在于未裁减的log中，发起日志复制rpc*/ {
    args := &AppendEntriesArgs{
        Term:         rf.currentTerm,
        LeaderId:     rf.me,
        Entries:      make([]Logt, 0),
        PrevLogIndex: rf.nextIndex[peer] - 1,
        LeaderCommit: rf.commitIndex,
    }
    if args.PrevLogIndex > rf.lastIncludedIndex &&
        args.PrevLogIndex < rf.lastIncludedIndex+len(rf.log) /*下一个日志在leader log里，且前一个日志没在快照里，也在leader log里*/ {
        args.PrevLogTerm = rf.log[rf.logIndex(args.PrevLogIndex)].Term
    } else if args.PrevLogIndex == rf.lastIncludedIndex /*下一个日志在leader log里，但上一个日志在快照里，没在leader log里*/ {
        //args.PrevLogIndex = rf.lastIncludedIndex
        args.PrevLogTerm = rf.log[0].Term
    }
    //deep copy
    args.Entries = append(args.Entries, rf.log[rf.logIndex(rf.nextIndex[peer]):]...)

    Debug(dLog, `sendAppendEntries S%d -> S%d, lastIncludedIndex:%d args{PrevLogIndex:%d,PrevLogTerm:%d,LeaderCommit:%d,log_entries_len:%d"}`,
        rf.me, peer, rf.lastIncludedIndex, args.PrevLogIndex, args.PrevLogTerm, args.LeaderCommit, len(args.Entries))

    go rf.handleSendAppendEntries(peer, args)
}
修改readPersist()方法

主要是为了实现前面日志复制RPC可能需要最新快照的最后一个条目的任期以及索引, 所以就持久化了两个新的raft状态变量lastIncludedIndex和lastIncludedTerm. 而且前面提到, 我在实现快照的时候, 是将被应用后的日志快照, 所以如果raft实例重新启动的话, 应用点和提交点应该也是从lastIncludedIndex开始.

// restore previously persisted state.
func (rf *Raft) readPersist(data []byte) {
	if data == nil || len(data) < 1 { // bootstrap without any state?
		return
	}
	defer func() {
		Debug(dPersist, "after read persist, S%d recover to status{currentTerm:%d,commitIndex:%d,applied:%d,lastIncludedIndex:%d,log_len:%d}",
			rf.me, rf.currentTerm, rf.commitIndex, rf.lastApplied, rf.lastIncludedIndex, len(rf.log)-1)
	}()

	// Your code here (2C).
	persistentStatus := &PersistentStatus{}
	if err := labgob.NewDecoder(bytes.NewBuffer(data)).Decode(persistentStatus); err != nil {
		Debug(dError, "readPersist decode err:%v", err)
		return
	}

	// 裁减剩下的log
	rf.log = persistentStatus.Log
	rf.currentTerm = persistentStatus.CurrentTerm
	rf.votedFor = persistentStatus.VotedFor
	// 最新的快照点
	rf.lastIncludedIndex = persistentStatus.LastIncludedIndex
	rf.log[0].Term = persistentStatus.LastIncludedTerm
	// 之前被快照的数据，一定是被applied
	rf.commitIndex = persistentStatus.LastIncludedIndex
	rf.lastApplied = persistentStatus.LastIncludedIndex
	// 加载上一次的快照
	rf.snapshot = rf.persister.ReadSnapshot()
}

调试过程

调试test 1

我把初版代码写完的时候，所有测试用例都没有过（偶尔会有一次过test 1）。后面改了日志打印信息，主要减少了一些不要信息的输出，例如对于日志我们不关心具体是什么，只关心复制到哪了，所以只需要打印相关索引信息即可。

当然，后面也封装了对下标的操作，这样问题也好排查，代码也更好修改。然后，在日志中看到了：当集群所有节点的日志全部快照了，也就是说快照裁减的日志没有剩下的特殊情况，nextIndex出现了回退现象。

034063 LOG1 before sendAppendEntries S0, nextIndex:190 matchIndex:189
034064 LOG1 after sendAppendEntries S0, nextIndex:189 matchIndex:189
034071 LOG1 before sendAppendEntries S1, nextIndex:190 matchIndex:189
034072 LOG1 after sendAppendEntries S1, nextIndex:189 matchIndex:189

非常令人匪夷所思的bug，然后我在前面的日志中发现，leader发送日志复制rpc，但是follower并没有复制成功，至此问题定位到了：应该是有个地方的边界情况没有考虑到。下面是关键代码，优化nextIndex定位的部分逻辑。

/*冲突：该条目的任期在 prevLogIndex，上不能和 prevLogTerm 匹配上，则返回假*/
index := rf.logIndex(args.PrevLogIndex)
if rf.log[index].Term != args.PrevLogTerm {
    // 从后往前找冲突条目，返回最小冲突条目的索引
    conflictIndex, conflictTerm := -1, rf.log[index].Term
    for i := args.PrevLogIndex; i > rf.commitIndex; i-- {
        if rf.log[rf.logIndex(i)].Term != conflictTerm {
            break
        }
        conflictIndex = i
    }

    reply.XTerm, reply.XIndex, reply.XLen = conflictTerm, conflictIndex, rf.realLogLen()
    reply.Term, reply.Success = rf.currentTerm, false
    return
}

因为集群中所有节点的情况一致，也就是PrevLogIndex和lastIncludedIndex的值是一样的，
所以就会出现rf.log[0].Term != args.PrevLogTerm的情况，进而日志复制失败，nextIndex回退的问题。

修复的方式有两种：一种是额外处理相等情况；还有一种方法就是，每次快照的时候初始化rf.log[0].Term为lastIncludedTerm即可。我采用的是第二种。采用第二种方案就不需要持久化存储lastIncludedTerm了

调试test 2

经过好几天的debug，终于把前面的test 1测试通过，但是在test 2的时候，总是遇到另一个比较奇怪的问题。

1: log map[0:<nil> 1:5926928346377738245 2:5899418714642564734 3:2523416114670145493 4:2645763998966155741 5:8669075945120996169 6:7089836692553293889 7:4329587389170088629 8:2003073101149869281 9:3121819971269749612]; 
server map[1:5926928346377738245 2:5899418714642564734 3:2523416114670145493 4:2645763998966155741 5:8669075945120996169 6:7089836692553293889 7:4329587389170088629 8:2003073101149869281 9:3121819971269749612 10:651793884186508261 11:6297140580147973579 12:7722938942633659376 13:4482676451686048456 14:2481212667518606188]
apply error: commit index=10 server=1 5926928346377738245 != server=2 651793884186508261

在上面的报错中显示日志S1的在index=10处的日志应该是651793884186508261。那么显然错误应该是出现在对rf.log的写操作中。经过排查与打印日志，最终发现问题出现在这里：

logIndex := rf.logIndex(args.LastIncludedIndex)
if rf.log[logIndex].Term == args.LastIncludedTerm {
    fmt.Println("S", rf.me, "安装快照前：", rf.log)
    rf.log = append([]Logt{{Term: args.LastIncludedTerm}}, rf.log[logIndex+1:]...)
    fmt.Println("S", rf.me, "安装快照后：", rf.log)
    go func() {
        rf.applyMsg <- msg
    }()
    reply.Term = rf.currentTerm
    return
}

上面这段代码中。当args.LastIncludedIndex等于rf.lastIncludedIndex，也就是当前对等点和leader拥有相同的快照点时，下面的代码裁减会出现问题。会把第一条日志留下来。而且实现的语义并没有完全遵从论文。下面是代码修改，主要是直接跳过index=0这个不算现存日志的判断。

//6. 如果现存的日志条目与快照中最后包含的日志条目具有相同的索引值和任期号，则保留其后的日志条目并进行回复
for i := 1; i < len(rf.log); i++ {
    if rf.realIndex(i) == args.LastIncludedIndex && rf.log[i].Term == args.LastIncludedTerm {
        rf.log = append([]Logt{{Term: args.LastIncludedTerm}}, rf.log[i+1:]...)
        go func() {
            rf.applyMsg <- msg
        }()

        reply.Term = rf.currentTerm
        return
    }
}
调试data race

lab2D使用-race测试的时候，偶尔出现下面的问题：

Test (2D): install snapshots (disconnect) ...
==================
WARNING: DATA RACE
Write at 0x00c0000f7520 by goroutine 37929:
  6.5840/raft.(*Raft).InstallSnapshot()
      /home/cold-bin/CodeProject/Go Code/6.5840/src/raft/raft.go:544 +0x548
  runtime.call32()
      /usr/local/go/src/runtime/asm_amd64.s:748 +0x42
  reflect.Value.Call()
      /usr/local/go/src/reflect/value.go:380 +0xb5
  6.5840/labrpc.(*Service).dispatch()
      /home/cold-bin/CodeProject/Go Code/6.5840/src/labrpc/labrpc.go:494 +0x484
  6.5840/labrpc.(*Server).dispatch()
      /home/cold-bin/CodeProject/Go Code/6.5840/src/labrpc/labrpc.go:418 +0x24e
  6.5840/labrpc.(*Network).processReq.func1()
      /home/cold-bin/CodeProject/Go Code/6.5840/src/labrpc/labrpc.go:240 +0x9c

Previous read at 0x00c0000f7520 by goroutine 37928:
  6.5840/raft.(*Raft).handleSendAppendEntries()
      /home/cold-bin/CodeProject/Go Code/6.5840/src/raft/raft.go:742 +0x15d
  6.5840/raft.(*Raft).heartbeatBroadcast.func2()
      /home/cold-bin/CodeProject/Go Code/6.5840/src/raft/raft.go:735 +0x4f

Goroutine 37929 (running) created at:
  6.5840/labrpc.(*Network).processReq()
      /home/cold-bin/CodeProject/Go Code/6.5840/src/labrpc/labrpc.go:239 +0x28a
  6.5840/labrpc.MakeNetwork.func1.1()
      /home/cold-bin/CodeProject/Go Code/6.5840/src/labrpc/labrpc.go:157 +0x9c

Goroutine 37928 (running) created at:
  6.5840/raft.(*Raft).heartbeatBroadcast()
      /home/cold-bin/CodeProject/Go Code/6.5840/src/raft/raft.go:735 +0xd65
  6.5840/raft.(*Raft).ticker()
      /home/cold-bin/CodeProject/Go Code/6.5840/src/raft/raft.go:654 +0x1ab
  6.5840/raft.Make.func1()
      /home/cold-bin/CodeProject/Go Code/6.5840/src/raft/raft.go:932 +0x33
==================
--- FAIL: TestSnapshotInstall2D (76.80s)
    testing.go:1465: race detected during execution of test

比较令我困惑的是尽管已经对rf.lastIncludedIndex = args.LastIncludedIndex的代码加了锁，依然会出现data race的问题。报错显示的原因是，读写冲突了，看代码的742行和735行，发现是开启协程时，打印日志的时候忘记加锁了。。。加上就好了。

调试test 5
Test (2D): install snapshots (unreliable+crash) ...
panic: runtime error: index out of range [-7]

goroutine 46139 [running]:
6.5840/raft.(*Raft).AppendEntries(0xc0001c32c0, 0xc00037fb80, 0xc0001e2f60)
        /home/cold-bin/CodeProject/Go Code/6.5840/src/raft/raft.go:459 +0x5e9
reflect.Value.call({0xc0000d8550?, 0xc0003e5c50?, 0xc000213b18?}, {0x645f7e, 0x4}, {0xc000213c70, 0x3, 0xc000213b48?})
        /usr/local/go/src/reflect/value.go:596 +0xce7
reflect.Value.Call({0xc0000d8550?, 0xc0003e5c50?, 0xc0002c3598?}, {0xc000213c70?, 0xc0004e24e8?, 0xa1bbc2b4?})
        /usr/local/go/src/reflect/value.go:380 +0xb9
6.5840/labrpc.(*Service).dispatch(0xc00043a840, {0x64977f, 0xd}, {{0x5fd460, 0xc00043e580}, {0x64977a, 0x12}, {0x69bb00, 0x5f5e60}, {0xc000ab1e00, ...}, ...})
        /home/cold-bin/CodeProject/Go Code/6.5840/src/labrpc/labrpc.go:494 +0x36e
6.5840/labrpc.(*Server).dispatch(0xc0002f1a88, {{0x5fd460, 0xc00043e580}, {0x64977a, 0x12}, {0x69bb00, 0x5f5e60}, {0xc000ab1e00, 0x168, 0x200}, ...})
        /home/cold-bin/CodeProject/Go Code/6.5840/src/labrpc/labrpc.go:418 +0x1e5
6.5840/labrpc.(*Network).processReq.func1()
        /home/cold-bin/CodeProject/Go Code/6.5840/src/labrpc/labrpc.go:240 +0x3f
created by 6.5840/labrpc.(*Network).processReq in goroutine 46138
        /home/cold-bin/CodeProject/Go Code/6.5840/src/labrpc/labrpc.go:239 +0x1e5
exit status 2
FAIL    6.5840/raft     403.381s

索引越界问题，后面在AppendEntries限制了提前检测，代码如下：

if rf.lastIncludedIndex > args.PrevLogIndex /*对等点的快照点已经超过本次日志复制的点，没有必要接受此日志复制rpc了*/ {
    reply.Term, reply.Success = rf.currentTerm, false
    return
}

结果

➜  raft git:(main) VERBOSE=0 go test -race -run 2D
Test (2D): snapshots basic ...
  Passed -- real time: 4.1       number of Raft peers:3          number of RPC sends: 148        number of bytes:  51216         number of Raft agreements reported: 211
Test (2D): install snapshots (disconnect) ...
  Passed -- real time:40.5       number of Raft peers:3          number of RPC sends:1752        number of bytes: 653103         number of Raft agreements reported: 351
Test (2D): install snapshots (disconnect+unreliable) ...
  Passed -- real time:44.5       number of Raft peers:3          number of RPC sends:1926        number of bytes: 694404         number of Raft agreements reported: 318
Test (2D): install snapshots (crash) ...
  Passed -- real time:29.1       number of Raft peers:3          number of RPC sends:1048        number of bytes: 403904         number of Raft agreements reported: 271
Test (2D): install snapshots (unreliable+crash) ...
  Passed -- real time:32.9       number of Raft peers:3          number of RPC sends:1162        number of bytes: 515722         number of Raft agreements reported: 345
Test (2D): crash and restart all servers ...
  Passed -- real time: 7.4       number of Raft peers:3          number of RPC sends: 240        number of bytes:  69192         number of Raft agreements reported:  49
Test (2D): snapshot initialization after crash ...
  Passed -- real time: 2.5       number of Raft peers:3          number of RPC sends:  78        number of bytes:  21956         number of Raft agreements reported:  14
PASS
ok      6.5840/raft     162.070s

Lab2的运行结果

目前测试过百次，没有任何报错。

➜  raft git:(main) time VERBOSE=0 go test -race -run 2 
Test (2A): initial election ...
  Passed -- real time: 3.1       number of Raft peers:3          number of RPC sends:  60        number of bytes:  16534         number of Raft agreements reported:   0
Test (2A): election after network failure ...
  Passed -- real time: 4.4       number of Raft peers:3          number of RPC sends: 120        number of bytes:  24380         number of Raft agreements reported:   0
Test (2A): multiple elections ...
  Passed -- real time: 5.5       number of Raft peers:7          number of RPC sends: 612        number of bytes: 122330         number of Raft agreements reported:   0
Test (2B): basic agreement ...
  Passed -- real time: 1.1       number of Raft peers:3          number of RPC sends:  16        number of bytes:   4450         number of Raft agreements reported:   3
Test (2B): RPC byte count ...
  Passed -- real time: 2.6       number of Raft peers:3          number of RPC sends:  50        number of bytes: 114694         number of Raft agreements reported:  11
Test (2B): test progressive failure of followers ...
  Passed -- real time: 5.1       number of Raft peers:3          number of RPC sends: 122        number of bytes:  26456         number of Raft agreements reported:   3
Test (2B): test failure of leaders ...
  Passed -- real time: 5.3       number of Raft peers:3          number of RPC sends: 194        number of bytes:  42492         number of Raft agreements reported:   3
Test (2B): agreement after follower reconnects ...
  Passed -- real time: 6.1       number of Raft peers:3          number of RPC sends: 124        number of bytes:  33152         number of Raft agreements reported:   8
Test (2B): no agreement if too many followers disconnect ...
  Passed -- real time: 3.7       number of Raft peers:5          number of RPC sends: 196        number of bytes:  42398         number of Raft agreements reported:   3
Test (2B): concurrent Start()s ...
  Passed -- real time: 1.1       number of Raft peers:3          number of RPC sends:  16        number of bytes:   4466         number of Raft agreements reported:   6
Test (2B): rejoin of partitioned leader ...
  Passed -- real time: 6.5       number of Raft peers:3          number of RPC sends: 190        number of bytes:  47097         number of Raft agreements reported:   4
Test (2B): leader backs up quickly over incorrect follower logs ...
  Passed -- real time:25.0       number of Raft peers:5          number of RPC sends:2152        number of bytes:1668628         number of Raft agreements reported: 102
Test (2B): RPC counts aren't too high ...
  Passed -- real time: 2.1       number of Raft peers:3          number of RPC sends:  40        number of bytes:  11626         number of Raft agreements reported:  12
Test (2C): basic persistence ...
  Passed -- real time: 4.4       number of Raft peers:3          number of RPC sends:  90        number of bytes:  23126         number of Raft agreements reported:   6
Test (2C): more persistence ...
  Passed -- real time:19.7       number of Raft peers:5          number of RPC sends:1064        number of bytes: 238546         number of Raft agreements reported:  16
Test (2C): partitioned leader and one follower crash, leader restarts ...
  Passed -- real time: 1.9       number of Raft peers:3          number of RPC sends:  38        number of bytes:   9641         number of Raft agreements reported:   4
Test (2C): Figure 8 ...
  Passed -- real time:27.9       number of Raft peers:5          number of RPC sends: 956        number of bytes: 199519         number of Raft agreements reported:  23
Test (2C): unreliable agreement ...
  Passed -- real time: 5.5       number of Raft peers:5          number of RPC sends: 216        number of bytes:  75706         number of Raft agreements reported: 246
Test (2C): Figure 8 (unreliable) ...
  Passed -- real time:35.3       number of Raft peers:5          number of RPC sends:3140        number of bytes:5542176         number of Raft agreements reported: 609
Test (2C): churn ...
  Passed -- real time:16.6       number of Raft peers:5          number of RPC sends: 780        number of bytes: 328623         number of Raft agreements reported: 376
Test (2C): unreliable churn ...
  Passed -- real time:16.2       number of Raft peers:5          number of RPC sends: 660        number of bytes: 225671         number of Raft agreements reported: 250
Test (2D): snapshots basic ...
  Passed -- real time: 7.0       number of Raft peers:3          number of RPC sends: 138        number of bytes:  49280         number of Raft agreements reported: 234
Test (2D): install snapshots (disconnect) ...
  Passed -- real time:66.4       number of Raft peers:3          number of RPC sends:1468        number of bytes: 531314         number of Raft agreements reported: 299
Test (2D): install snapshots (disconnect+unreliable) ...
  Passed -- real time:85.9       number of Raft peers:3          number of RPC sends:1894        number of bytes: 729100         number of Raft agreements reported: 332
Test (2D): install snapshots (crash) ...
  Passed -- real time:36.7       number of Raft peers:3          number of RPC sends: 720        number of bytes: 344056         number of Raft agreements reported: 342
Test (2D): install snapshots (unreliable+crash) ...
  Passed -- real time:41.3       number of Raft peers:3          number of RPC sends: 804        number of bytes: 429314         number of Raft agreements reported: 355
Test (2D): crash and restart all servers ...
  Passed -- real time:14.6       number of Raft peers:3          number of RPC sends: 288        number of bytes:  83488         number of Raft agreements reported:  62
Test (2D): snapshot initialization after crash ...
  Passed -- real time: 3.9       number of Raft peers:3          number of RPC sends:  72        number of bytes:  20212         number of Raft agreements reported:  14
PASS
ok      6.5840/raft     456.234s
VERBOSE=0 go test -race -run 2  70.15s user 8.20s system 17% cpu 7:36.74 total

race之后的时间：约78s的CPU时间和总共7m36s的运行时间，满足lab要求的“当使用-race运行时，大约有 10 分钟的实时时间和 2 分钟的 CPU 时间。“。

至此, 终于实现了raft协议🍻

【阿冰】
关注
专栏目录
MIT6.824 Lab2-Raft(A&B&C&D)
a2269713951的博客
08-13 292
然后就是什么时候进行日志复制，查了一下大部分都是在start函数中每接收到一个日志就发起一个复制请求，这样会导致多个请求之间的appendEntries是重复包含的，比如当第一条日志还没复制完成时，后续节点又接收到了多条日志，这样就会发起多轮请求，但是此时前面的请求还没复制完成，则后面的请求appendEntries中必然是包含前面的重复日志，这样效率实属低下而且不优雅。这个实验基本是按照论文的描述进行实现的，在实验的过程中能很好地掌握和理解raft的各种细节，加深对于raft的理解。
MIT 6.824 lab ——1.项目简介
ekxavol的博客
06-25 6943
6.824个人项目简介1 项目结构图2 项目介绍3 Raft介绍 1 项目结构图 2 项目介绍 3 Raft介绍
6.824 raft Lab 2D 日志压缩
余添能的博客
10-03 668
本文简要介绍了日志压缩的实现，减少了数据量和恢复时间。日志压缩由应用层根据日志数量触发，生成snapshot并截断日志，每个peer都可以独立进行。如果某个peer的日志太过于落后就需要复制Leader的snapshot，而peer接收到snapshot后不能立刻应用和截断日志，应该由状态机先应用，raft后应用snapshot。倘若先应用到raft成功了，后应用到状态机失败了，就会导致状态机数据不完整，最好是两者保持原子性。
MIT6.824-lab2D-日志压缩(log compaction)
迷雾总会解
08-09 1893
做到显示为止，我们重启的服务器会重放完整的 Raft 日志以恢复其状态。但是，长期运行的服务永远记住完整的 Raft 日志是不切实际的。因此，我们可以做一个快照，快照存储了在某一个index之前的所有日志的一个状态， Raft 就可以看丢弃快照之前的日志条目。结果是更少量的持久数据和更快的重启。我2D部分最后一个测试没有通过，找了很久，始终没发现问题，不想搞了，暂时这样吧。大体的思路我觉得没有问题。最后一个测试没有通过，找了很久，始终没发现问题，不想搞了，暂时这样吧。.........
Mit6.824-lab2d-2022
qq_41703198的博客
09-30 855
Mit6.824-lab2d-2022实验思路与代码，以及整个lab2总结
MIT6.824 Lab2D LogCompaction 实验记录与总结
weixin_45842471的博客
08-19 150
MIT6.824 Lab2D LogCompaction 实验记录与总结
2021 MIT 6.824 Lab2D Raft算法(四)：日志压缩(log compaction)【完】
梁熙民的csdn博客
05-25 2232
0 前言 经过前面三个lab我们实现了raft算法的选举(leader election)、日志复制(log replication)与持久化(persist)的功能，在最后一个lab将实现日志压缩(log compaction)。日志压缩的诞生出于这样的考虑：在我们前面所有的代码中，日志均存在内存里，然而如果一台服务器是24×\times× 7地工作，某些时刻日志将会把内存撑爆，而且日志很多的话，持久化的时候也需要很多的IO操作时间，所以要引入日志压缩技术让服务器丢弃一些日志节省内存。所以使用什么技术丢弃
MIT 6.824 Lab2 2021 ABCD完成记录
qq_40443651的博客
04-25 6128
这里写自定义目录标题说明总体方法paper 与 实验材料阅读Debug & logTime.TimerLog Index代码逻辑概述测试时间A leader elecitonRaft 基础架构LeaderElectionAppendEntriesB log补充AApplyEntriesC persistenceD log compaction 说明 本人除了Lab1，并没有接触过GO语言。文中有写的不对，不恰当的地方，希望大佬们能及时指出。整个实验花了前后整整4，5天的时间，包括上课时间，大概有4
mit_6.824_2021_lab2C_persistence
一把健
10-15 380
mit_6.824_2021_lab2C_persistence persistence 引入持久化，持久化的相关代码已经在 persister.go 中实现，我们要做的只是调用 api 就好，相对容易的一节； 但同时也是不容易的一节，因为这一节中有两个关于 图8 的网络崩溃节点崩溃实验，基本都会出 bug，出 bug 基本都是因为 lab2A 和 lab2B 引入的 bug； 本人也因为 lab2B 引入的 bug 导致在 lab2C 卡了很久；这里阐述一下自己的心路历程 lab2C_persistenc
【MIT 6.824 Lab2】——Raft
Kaychenl的博客
06-13 645
2.如果匹配，则直接向后检索到第一个发生冲突的日志然后将日志新增在后面。3.如果都匹配但是新增日志比当前的长，则直接把新增日志添加在preLogIndex后。上述判断主要遵循raft的以下准则1.如果两个不同的日志实体有相同的index和term，则这两个日志实体存储的内容相同。（leader只能增加，不能删除和修改）2.如果两个不同的日志实体有相同的Index和term，则这两个日志前的所有日志都是相同的。（follower需要prevLogIndex对的上才能新增）......
MIT6.824-lab2D-2022（日志压缩详细讲解）
幸平的博客
06-08 5178
从paper中去讲解，并实现关于lab2D的代码。
MIT6.824 lab2C&2D实验总结
m0_63691156的博客
04-15 589
个人学习
MIT 6.824分布式 LAB2D：Raft
MarksSa的博客
11-24 1862
Lab 2D是lab2的最后阶段了，这一阶段就是加了一个快照机制，但是这种实验中这个快照是何时以及如何进行的，建议大家事前先去看一看，不然就会碰到各种问题。例如，我在测试过程中莫名其妙发现leader死锁了，以及测试显示lastapplied的index值和commandIndex值不匹配等问题。
MIT 6.824 Lab2 Raft实现总结
qq_43079236的博客
10-05 822
前言 本文的局限性在于，本文不完全按照论文(raft extended)实现，并以通过所有测试和自我满足为目的。在部分与论文不一致，或论文没有详细讨论的地方，我将以引用的格式来说明。 文本并不详细论证Raft，即不按照领导选取（leader election）、日志复制（log replication）、安全（safety）展开，并且（暂时-2020/10/4）不讨论成员变化（membership changes）。本文将把这些部分融合起来，全面展示各个部分的状态变化。 在实现Raft的时候，加锁是个难题，
mit_6.824_2021_lab2D_log_compaction
一把健
10-17 779
mit_6.824_2021_lab2D_log_compaction lab2D 主要是日志压缩功能，实验里是采用论文的最简单的方式，snapshot 压缩快照，并且更简单的是不分块的形式；感觉主要有两点需要注意： 快照功能的加入对原有逻辑的修改 快照功能的流程(InstallSnapshot, Snapshot, CondInstallSnapshot, applyCh) lab2D_log_compaction 实验内容 要实现快照功能，需要实现 Snapshot、CondInstallSnap
Golang笔记_day10
Runing_WoNiu的博客
10-16 274
1、什么是channel，为什么它可以做到线程安全。2、Golang Epoll原理。
Windows 下 golang 多版本管理
追风2019
10-17 1036
本文介绍了在Windows环境下管理多个版本的Golang的方法。首先，需要下载不同版本的Golang安装包，并修改目录名称。接着，通过添加GPPATH环境变量、配置PATH环境变量以及在命令行和Goland中设置go env环境，实现多版本共存。此外，还提到了官方建议和使用g工具进行版本管理的方法。作者通过这些步骤解决了特定框架在不同Golang版本间的兼容性问题。
15分钟学Go 第2天：安装Go环境
weixin_40780178的博客
10-16 885
通过本节的学习，你已经成功在Windows 11上安装并配置了Go语言开发环境，包括Go语言本身、VS Code和必要的插件。同时，你还创建并运行了一个简单的Go程序，熟悉了工作流程。接下来，你可以开始深入学习Go语言的基本语法与编程概念。怎么样今天的内容还满意吗？
Go-知识依赖Vendor
最新发布
a18792721831的博客
10-17 893
自 Go 1.6 起，vendor 机制正式启用，它允许把项目的依赖放到一个位于本项目的 vendor 目录中，这个 vendor 目录可以简单理解成私有的 GOPATH 目录。项目编译时，编译器会优先从 vendor 中寻找依赖包，如果 vendor 中找不到，则再到 GOPATH 中寻找。
MIT6.824 lab2D
08-08
MIT6.824 lab2D是分布式系统课程6.824的第二个实验任务。这个实验任务主要涉及一致性协议和复制状态机（Replicated State Machine）的实现。 在lab2D中，你将使用Go语言实现一个基于Raft算法的一致性协议。Raft是一种分布式共识算法，用于确保多个节点之间的一致性。你将需要实现Raft协议中的选举、日志复制和状态机应用等关键部分。 通过完成lab2D，你将深入了解一致性协议的工作原理以及如何在分布式系统中实现可靠的一致性。这对于理解分布式系统的设计和实现具有重要意义。 请注意，由于我是一个AI助手，无法直接帮助你完成lab2D的任务。如果你遇到具体的问题或困惑，可以提出来，我会尽力提供帮助和解答。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

【阿冰】

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值