😇 All I need to know about 6.5840
Full code on:
https://github.com/humbornjo/MIT-6.5840

Lab1

💡 虽然本次实验没有触及，但是GFS才是Map Reduce的灵魂。这也是很多MR方法局限在单机运行的根本原因。在分布式的场景中，intermediate的交换才是事实上的重点。

Difficulties & solution

• PASS LOG

Lab2

💡 What u deserve to understand is that, even raft can make mistake. When the delay is high and command flood in.

Core Idea

1. Raft RPCS is idempotent
2. Randomization causes simplicity
3. Leader takes it all
4. Logical timing instead of physical timing

$$ broadcastTime ≪ electionTimeout ≪ MTBF $$

Mind Trail

(」ﾟﾛﾟ)｣ lab2 Raft

Difficulties & solution

2A

• Term严格小的才能给Term大的server投票，但是容易出现以下情况 (忽略第三列)，即server S1和S2几乎以同一时间开始选举 (即使存在随机timeout)，导致多轮都无法选出leader。

• 观察第二列和最后一列，可以发现这里 S1 和 S6 出现了脑裂现象，但是并未得到解决。原因是两方此时的Term相同，两方互相会拒绝对方的heartbeat log而不会进行状态转换。

• PASS LOG

2B

• Server在成功append以后，竟然没有让Leader更新commitIndex

• 如果一个server掉线了，会不断StartElection()自增，当它重联时，它的Term将会很大。就会导致一个情况，当前 leader 的 AppendEntries RPCs 将会被拒绝，reply中的Term巨大，会将Leader打回Follower并更新Term,最好给Leader特权，让Leader尽快timeout,再次成为Leader；由它召开的Election也会被其他server拒绝(LastLogIndex很小)并使其他server更新Term，不用给特权通道。但是在下方log中 S0 apply msg: {true 101 1 false [] 0 0} 重复出现，且重联后，并未一直尝试Append(在第一次被拒绝后)导致没有及时更新。

• Apply massage的时候出现了顺序出错的问题

• PASS LOG

2C

• 一运行到unrealiable的test就出现out of index的错误，现在想来好像在2B中偶尔也会出现这个错误，还债了属于是。

• 有极小的概率出现问题：ApplyMsg顺序错位。

• PASS LOG

2D

在2D中，很重要的一点是，切片底层是数组实现，如果想要让GC reach到被snapshot掉的无用内存，就需要重新创建切片，原切片指针置空。

• 有概率出现问题：在更新commitIndex的时候出现out of Index问题。

• 死锁问题：一开始执行Snapshot函数就卡在获得锁的操作这里。

• AppendEntries中出现负数的Log索引

• broadcast中出现负数的Log索引

• ApplyMsg顺序错位第二弹，详循2C中的第二个问题

• 首先，可以知道，apply out of order有两种形态，一种是接收到了有延迟的信息，还有一种是接收到了未来的信息。以InstallSnapshot RPC为例，可以通过下面这段代码对延迟信息进行过滤。但是raft的Term、commitIndex和lastApplied等索引都是完备的，讲道理不会出现“未来的”信息。

• 会报莫名其妙的错误

• PASS LOG