# MIT 6.824 Lab2: Raft
透過 golang 實作一個基本的 raft，分散式系統有大量鎖及併發的操作，也看了網路上一些心得文章，已經有心理準備會有滿滿的坑了，但分散式系統就是這樣才好玩對吧 XD。在開始實作前建議先看過 [3],[4] & [5]，然後 ==Figure 2. 很重要、很重要、很重要==，誠如 [TA Guide](https://thesquareplanet.com/blog/students-guide-to-raft/) 所說，請對 Figure 2. 保持敬畏之心，確保 "完整" 的理解圖中所有內容，魔鬼藏在細節裡

## Lab2A Leader Election
第一項任務是實作 Leader 選舉的機制，結構體參數的部分我直接參考論文設定，實作上有幾點比較重要的是:
1. 要在正確的時刻重設 election timer
- 轉變為 Follower 跟 Candidate 兩個狀態時，這點比較直觀
- Follower 收到 "合法" AppendEntries RPC 時，合法代表請求的 Term >= CurrentTerm，否則代表該請求是由一個過期的 Leader 發送，那重設 timer 反而會觸發不必要的重新選舉
- Follower 收到 "合法" RequestVote RPC 時，合法意味著
- 請求的 Term >= CurrentTerm
- Follower 在該 Term 還沒投過票 (rf.votedFor == -1)
- 請求的 log 跟自身比較是 up-to-date 的，代表 Candidate 的 log 至少不落於人後，up-to-date 的定義請參閱論文 5-4 Safety 章節中有關 Election Restriction 的部分
- 成為 Leader 之後應該要將 election timer 停止
2. 無論是任何 RPC 的 request or response，只要參數中 Term > CurrentTerm，就轉變身分為 Follower，因為節點已經過期了，而且這樣才能讓各個節點盡快收斂到同一個 Term
> If RPC request or response contains term T > currentTerm:
set currentTerm = T, convert to follower
3. 任何過期的請求都直接忽略即可；而 Candidate 在收選票時，要確保 peer 的 Term == CurrentTerm 才能接收選票
4. 變成 Leader 時記得要定期發送心跳包並重設 heartbeat timer
5. RPC 記得要用 goroutine 異步地發送避免卡住節點的其他操作

另外在 debug 的過程中深刻體會到 [Raft Locking Advice](https://pdos.csail.mit.edu/6.824/labs/raft-locking.txt)[4] 提到的一點，==不要用 Lock 包住任何關於 Channel or RPC 的操作==，我一開始在實作發送心跳包的時候沒注意到，測試了半天每次都是第 3 個測資沒法過，而且都只能選出 2 次 Leader，後來仔細觀察 log 內容才發現 Leader 節點幾乎在開始發送第二次心跳包之後就沒有 log 了，這才恍然大悟難怪到後面沒法選出新 Leader，因為 Leader 可能發送 RPC 給斷線的節點，等不到回應就發生 deadlock 了 XD (or 持有鎖很長一段時間沒法釋放)

### Test Result
經過 1000 測試都 Pass

## Lab2B log

## Reference
1. [6.824 Lab 2: Raft Spring-2022](http://nil.csail.mit.edu/6.824/2022/labs/lab-raft.html)
2. [Patterns and Hints for Concurrenty in GO (bilibili)](https://www.bilibili.com/video/BV1zS4y1F7xq/)
3. [Raft Structure Advice](https://pdos.csail.mit.edu/6.824/labs/raft-structure.txt)
4. [Raft Locking Advice](https://pdos.csail.mit.edu/6.824/labs/raft-locking.txt)
5. [Students' Guide to Raft](https://thesquareplanet.com/blog/students-guide-to-raft/)