raft理論與實踐[2]-lab2a實驗說明

準備工做

一、閱讀raft論文

二、閱讀我寫的raft理論與實踐[1]-理論篇

三、因爲咱們須要模擬rpc遠程調用， 所以須要查看我寫的這篇文章： 模擬RPC遠程過程調用

四、實驗開始，咱們首先須要拉取代碼：

實驗說明

此代碼中labrpc 與 labgob 爲模擬rpc的 package。

raft文件夾爲此實驗用到的代碼框架。 在其中已經寫好了一部分代碼，還須要咱們經過實驗來完善它。

在本實驗中，咱們只須要關注raft.go文件，並實現選舉邏輯和心跳檢測邏輯。

本實驗的目標是要保證，惟一的leader可以被選舉。

當leader被選舉後，若是沒有任何失敗，其將會保持leader。

當leader被選舉後，若是leader奔潰或者to/from leader 的網絡包丟失，則新的leader將會產生。

要驗證代碼的正確性，運行go test -run 2A

實驗提示

一、raft.go 的raft結構體 補充字段。 字段應該儘可能與raft論文的Figure2接近。

二、填充RequestVoteArgs和RequestVoteReply結構。 修改Make()以建立一個後臺goroutine，該後臺goroutine將在有一段時間沒有收到其餘節點的請求時經過發出RequestVote RPC來按期啓動領導者選舉。 這樣，節點將瞭解誰是leader（若是已經有leader），或者成爲leader自己。 實現RequestVote（）RPC處理程序，以便節點之間相互投票。

三、要實現心跳檢測，請定義AppendEntries RPC結構（儘管您可能還不須要全部參數），並讓leader按期調用其餘節點此方法。 編寫AppendEntries RPC方法，該方法將重置選舉超時，以便在已經有leader時，阻止其餘節點成爲leader。

四、確保不一樣對等方的選舉超時不會老是同時觸發，不然全部節點都只會爲本身投票，而沒有人會成爲領導者。

五、測試要求leader每秒發送心跳RPC的次數不得超過十次。

六、測試要求在leader失敗後，也可以再5秒以內選出新的leader。 您必須選擇足夠短的選舉超時時間（以及所以產生的心跳間隔），

以使選舉頗有可能在不到五秒鐘的時間內完成，即便須要進行多輪選舉也是如此。

七、raft論文的5.2提到選舉超時的範圍是150到300毫秒，可是僅當領導者發送心跳的頻率大大超過每150毫秒一次的頻率時，此範圍纔有意義。

因爲測試要求您的心跳檢測爲每秒10個，所以您將必須使用大於150到300毫秒的選舉超時時間，但不能太大，由於那樣的話，您可能會在五秒鐘內沒法選舉領導者。

八、使用go的rand方法產生隨機數。

九、go的time.Timer 和 time.Ticker 很難使用正確。

十、要調試代碼，能夠將util.go 的debug設置爲1.

十一、您應該使用go test -race檢查代碼，並修復它報告的全部問題。

參考

講義

講義新