[心得] MIT 6.824 lab心得

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

--

有 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早點出現。

在哪阿? 麻煩大大指點一下

上課: 一個禮拜 lab: 剛剛看了一下commit，大概一個月

我是前面有去看過其他課的材料與DDIA，才感受到課程安排的邏輯 一切盡在不言之中