之前看到有人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的人，以上。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 123.195.0.183 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1647023457.A.48B.html 有 challenge1只要在完成shard migration後直接把原本的shard删了就好 migration的方式有主动push或是自己pull push在完成push後就可以删了 pull要在puller完成pull後再通知pullee做gc (pull的rpc被call不代表对面真的完成migration) 所以pull需要两个rpc，但push只要一个，所以当时是做push challenge2只要确保正在migrate的shard不会被lock锁住不能回应get/put/append即可， 简单的作法: 调整lock的位置 更绝一点: 每个shard都给一个lock 这堂比较难，因为比较难debug，在这里debug只有log，但6.S081还有gdb可以用，有错，qemu连shell都进不去或是直接panic。 这里如果有错可能是测好几次出现一次，或是看起来有在动其实没有(leader选不出来或是shard推不出去)。 但log很~~~~~~~长，要在脑中replay这些主机到底在干嘛才能知道到底哪里错了。 然而还有一种情况是log没有印到关键状态，就只好加log再反覆跑，祈祷bug早点出现。 ※ 编辑: s9041200 (123.195.0.183 台湾), 03/12/2022 11:00:43 在哪阿? 麻烦大大指点一下 ※ 编辑: s9041200 (123.195.0.183 台湾), 03/12/2022 12:31:14 上课: 一个礼拜 lab: 刚刚看了一下commit，大概一个月 我是前面有去看过其他课的材料与DDIA，才感受到课程安排的逻辑 一切尽在不言之中 ※ 编辑: s9041200 (123.195.0.183 台湾), 03/12/2022 20:49:10