之前看到有人po国外CS的公开课，刚好最近把MIT 6.824的lab都写完了，来分享一下心得。
希望下面的心得可以帮助在写lab的人与让更多人一起来写lab:-)
Q1: 这堂课与其他分布式系统的课差在哪里?
一般的课就是把分布式的手法与概念介绍过去，像lamport clock, raft, 各种consistency。
6.824每堂课都是由一篇又一篇的paper组成，带大家去看遇到的问题是什么，他们是怎么处理的、优缺点是什么。
所以有人会说6.824上完后没有什么架构，但其实只是6.824没有整个列出来而已。
一开始是单纯的single leader(GFS, vmware FT)，但会有single failure；
后面有共识算法(raft)，让其他在leader死亡时可以接手，但是performance不好，也不能处理transaction；
为了处理transaction，就有了distributed transaction(2 phases-commit)，performance当然不好，但目前没有什么好方法；
但如果不追求强一致性，可以换来性能的提升(zookeeper, casual consistency)；
不追求读写的效能提升，只追求read-only效能提升，就有了spanner与aurora；
前面的情境都是建立在彼此可信任不会有造假的前提(非拜占庭)，面对有恶意、不能信任的user，fork consistency与blockchain应运而生。
另外还有上锁，在cache consistency中介绍悲观锁，在FaRM介绍乐观锁。
这让我想起读little schemer与seasoned schemer的时光，都是不明讲的。
Q2: lab在做什么?
lab1是做一个单机版的MapReduce。
lab2是根据raft paper做一个具有log compaction、log fast backtrack、基本raft功能的raft lib。
lab3是用lab2的raft做一个容错、线性一致的key-value database。
lab4是一个简化版的etcd，可以当成是做了shard的lab3。
Q3: lab做完会得到什么?
1. 用golang实现一个raft与简化的etcd
2. 设计log与用log除错的能力
3. 会用lock
4. 成就感与耐心
Q3: lab1要注意什么?
注意reducer的定义，剩下很简单(与后面的比)。
话说这lab可以只用atomic完成。
Q4: lab2要注意什么?
1. 读raft paper，要知道raft的正确性来自哪里
2. 一开始只用一个lock就好，慢慢发展自然会看到哪边还需要lock
3. log的操作要做好抽象，不然做log compaction会改到吐
4. log要把所有改变的state印出来，lab到后面开始测unreliable会看到好几次才出现一次的bug
5. 写到一定程度要去读前TA的student guide
6. log fast backtrack有很多作法，教授有提供一种在raft2那一篇
7. lab页面上有raft结构与上锁的建议，也许可以参考看看(我没看)，个人是
- 上lock要按照一定顺序
- 没有被lock保护的method可以加一些字表示没有上lock
- 写到后面会忘记到底哪边有上lock，之后就默默deadlock
一般来说难以重现的bug出自下面3种情况:
1. rpc条件给错 => 回去看paper的figure 2
a. HeartBeat并不特别，heartbeat就是AppendEntries
b. RequestVote的条件有没有错
- lab2a的投票没有涉及log，但是log是投票中很重要的条件，在lab2b的测试中lab2a没做好的部分会暴露出来
2. timer没有在对的时机reset => 回去看paper的figure 2
3. heartbeat或是election的时间太近 => 两者不能太近
另外丢log到client的部分可以拉出一个applier做，因为tester的channel是unbuffer，会撞student guide中提到的4-way deadlock。
还有写个脚本跑test，善用background job一次跑好几个test，自己写或是找TA的脚本都好。
在前往下一个lab之前，先把自己的raft多测几遍，越早找到bug越好。
Q5: lab3要注意什么?
1. student guide中提到的re-appearing index，底下的raft可能经历换leader，要确认拿到的commit的term是对的
- 同时还要做timeout retry
2. 去重，rpc会有延迟、多次重试这要处理，其实就是加个sequence number
3. lab3有测试performance的部分，注意raft的persist有没有在不对的时候persist
Q6: lab4要注意什么?
1. lab4a的产生config算法一定要是确定性的，同样的input同样的output(map的走访会变!!)
2. shard的分配config会有index，这是有意义的，利用它才能正确的做shard migration
3. challenge1虽然说是做gc，但我一直吃因timeout而产生的FAIL(明明都print passed了QQ)，最后是调timeout的时间才ok的
Q8: golang有没有要注意的?
可以先看Russ Cox在2018的slide。
http://nil.csail.mit.edu/6.824/2018/notes/gopattern.pdf
这里的golang是1.17.x版。
1. map中struct的field是unaddressable，不能改
2. mutex没有tryLock
3. log可以直接用%v去印
4. goroutine中会变动的值(index之类)一定要从参数传进去，有的时候风格检查找不到
5. 传到rpc的东西要先copy一份，不然会有奇怪的panic
6. slice的copy是取两者最小的长度
7. slice的slice不一定会copy来产生新的slice
8. race detector要开，先修data race
9. built-in timer不是不能用，要去找正确用法
Q9: 个人而言做完lab有什么收获?
1. 好的架构可以在扩展功能时会带领你到对的地方
2. lock怎么与object融合在一起
Q10: 能不能公开code?
不行，他们还在上课。
Q11: 整个做完有什么感想?
能修到这门课的学生是幸福的，lab很有趣。
也感谢MIT 6.824能公开这堂课。
另外同实验室的6.S081也是很棒的课，lab也有趣同时还有几乎是明示的暗示。
Q12: 推荐大家来写吗?
所有测试与scaffold都有，舞台就在那边，还不上吗?
希望这篇能帮到想写lab的人，以上。