之前看到有人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/m.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