I. Source
- MIT-6.824 2020 課程官網(wǎng)
- Lab2: Raft 實(shí)驗(yàn)主頁
- simviso 精品付費(fèi)翻譯 MIT 6.824 課程
- Paper - Raft extended version
II. My Code
- source code 的 Gitee 地址
- Lab2C: Persist 的 Gitee 地址
課程官網(wǎng)提供的 Lab 代碼下載地址，我沒有訪問成功，于是我從 Github 其他用戶那里 clone 到干凈的源碼，有需要可以訪問我的 Gitee 獲取
III. Motivation
提出 Raft 的主要目的，是為了解決容錯(cuò)問題，即使集群中有一些機(jī)器發(fā)生了故障，也不影響整體的運(yùn)作（對(duì)外提供的服務(wù)）
我用一個(gè) demo 來說明，假設(shè)我們的需求一直都是自己的 PC 能夠順利訪問云端的資源（HTTP 或數(shù)據(jù)庫）服務(wù)器。在服務(wù)器穩(wěn)定在線的情況下，我們?nèi)ピL問它，一點(diǎn)問題都沒有
但是，如果那唯一的一臺(tái)服務(wù)器掉線了，那么我們將無法再訪問，即對(duì)外的服務(wù)到此停止。這是我們無法忍受的，我們希望提供服務(wù)的一方能夠保持穩(wěn)定，時(shí)時(shí)刻刻為我提供訪問服務(wù)。這就是我們的需求
好，現(xiàn)在問題擺在眼前，提供服務(wù)的一方怎樣保證穩(wěn)定性？讓唯一的那臺(tái)服務(wù)器永遠(yuǎn)維持穩(wěn)定的狀態(tài)，不允許宕機(jī)？這非常地不現(xiàn)實(shí)，就好比讓一個(gè)人練成金剛不壞之身
所以，我們只能琢磨是否可以通過添加服務(wù)器的數(shù)量來確保對(duì)外服務(wù)的穩(wěn)定。更近一步，即是現(xiàn)在服務(wù)器不再只有一臺(tái)，擴(kuò)充到 3 臺(tái)，這 3 臺(tái)中有一臺(tái)是 primary 服務(wù)器，也主要由它對(duì)外提供服務(wù)；其他 2 臺(tái)是 secondary 服務(wù)器（后備力量），擁有和 primary 服務(wù)器相同的數(shù)據(jù)內(nèi)容
在 primary 服務(wù)器出現(xiàn)故障的時(shí)候，secondary 服務(wù)器頂上去，替代它的位置。這樣就可以保持穩(wěn)定的對(duì)外服務(wù)了
這就是我們應(yīng)對(duì)資源服務(wù)器崩潰的最常用最有效的法子，但是想實(shí)現(xiàn)這個(gè)想法，首先要解決數(shù)據(jù)同步的問題，即如何確保 secondary 服務(wù)器擁有和 primary 服務(wù)器同樣的內(nèi)容？
這個(gè)同步問題，在學(xué)術(shù)上被稱為共識(shí)算法，最經(jīng)典的共識(shí)算法是 Paxos，但是它太難理解了。于是，斯坦福那幫人想出了更為簡(jiǎn)便的共識(shí)算法，即 Raft
通過 Raft 算法就可以同步集群中服務(wù)器的內(nèi)容。要實(shí)現(xiàn)該算法，分三步走，5 - The Raft consensus algorithm 章節(jié)中的 Leader Election、Log Replication 和 Safety
本文主要針對(duì)第三步，Lab2C: persist 展開講解，如有 Lab2A: Leader Election 或 Lab2B: Log Replication 的需要，請(qǐng)移步
IV. Solution
Lab2C: persist 主要就是為了解決一個(gè)問題，即網(wǎng)絡(luò)中的復(fù)雜情況會(huì)導(dǎo)致集群中的機(jī)器掉線 OR 機(jī)器本身的宕機(jī)。我們希望發(fā)生此類的情況，Raft 也能很好地應(yīng)對(duì)
論文中的圖 2 也提到了要完成持久化操作，我們需要保存哪些字段放在磁盤中，最重要的莫過于 log[] 、curTerm 和 votedFor 三個(gè)字段。其他的例如 nextIdxs[] 和 matchIdxs[] 是可以通過這三個(gè)字段即時(shí)計(jì)算出來的，從工程角度上來講可以不用保存，這樣減少了讀寫磁盤的時(shí)間，從一定程度上提高了 Lab2C: persist 的效率
好，話不多說，我們可以直接開始具體的編碼工作了，只要在 Lab2B: Log Replication 確保沒有問題的情況下，Lab2C: persist 將會(huì)容易很多
S1 - 實(shí)現(xiàn)persist()
第一步，就是要實(shí)現(xiàn)持久化函數(shù)，即 raft.go:persist() ，這個(gè)函數(shù)干的事情，即是將 log[] 、curTerm 和 votedFor 三個(gè)字段寫入磁盤，具體如何寫入，這不是我們操心的事，我們只需要將其序列化交給 Encoder 即可，
func (rf *Raft) persist() {
// Your code here (2C).
// Example:
// w := new(bytes.Buffer)
// e := labgob.NewEncoder(w)
// e.Encode(rf.xxx)
// e.Encode(rf.yyy)
// data := w.Bytes()
// rf.persister.SaveRaftState(data)
w := new(bytes.Buffer)
e := gob.NewEncoder(w)
e.Encode(rf.curTerm)
e.Encode(rf.votedFor)
e.Encode(rf.log)
data := w.Bytes()
rf.persister.SaveRaftState(data)
}
就像這樣，按照上面助教已給出的例子，照貓畫虎即可
S2 - 實(shí)現(xiàn)readPersist()
我們也要實(shí)現(xiàn)讀的具體操作，同樣如何去讀取磁盤也不是我們關(guān)心的事，我們只需要調(diào)用 Decoder 分解序列化即可，
func (rf *Raft) readPersist(data []byte) {
if data == nil || len(data) < 1 { // bootstrap without any state?
return
}
// Your code here (2C).
// Example:
// r := bytes.NewBuffer(data)
// d := labgob.NewDecoder(r)
// var xxx
// var yyy
// if d.Decode(&xxx) != nil ||
// d.Decode(&yyy) != nil {
// error...
// } else {
// rf.xxx = xxx
// rf.yyy = yyy
// }
r := bytes.NewBuffer(data)
d := gob.NewDecoder(r)
var curTerm int
var votedFor int
var log []LogEntry
if d.Decode(&curTerm) != nil || d.Decode(&votedFor) != nil || d.Decode(&log) != nil {
DPrintf("read persist fail\n")
} else {
rf.curTerm = curTerm
rf.votedFor = votedFor
rf.log = log
}
}
又是一個(gè)照貓畫虎，跟著助教的寫法來就可以。每一次的 raft.go:Make() 都會(huì)調(diào)用 readPersist() 讀取已持久化的數(shù)據(jù)用以初始化，所以它不需要我們操心 OR 考慮應(yīng)該在何處調(diào)用，自帶的框架已經(jīng)幫我們安排好了
S3 - 持久化三字段
我們要在 raft.go 、appendEntries.go 和 requestVote.go 中尋找到流程中更新 log[] 、curTerm 和 votedFor 三個(gè)字段的地方，然后在它們完成操作之后持久化此類的數(shù)據(jù)
在 raft.go 中第一處出現(xiàn)在 raft.go:Start() 中，即 client 追加日志條目之后，要持久化，
func (rf *Raft) Start(command interface{}) (int, int, bool) {
// Your code here (2B).
rf.mu.Lock()
defer rf.mu.Unlock()
/*------------Lab2C Persist---------------*/
defer rf.persist()
index := -1
term := rf.curTerm
isLeader := rf.role == Leader
if isLeader {
rf.log = append(rf.log, LogEntry{Idx: rf.lastLogIdx() + 1, Term: term, Cmd: command})
index = rf.lastLogIdx()
}
return index, term, isLeader
}
第二處出現(xiàn)在 raft.go:run() 的 candidate 階段，因?yàn)?follower 成為 candidate 之后會(huì)更新 curTerm 和 votedFor ，
func (rf *Raft) run() {
for !rf.killed() {
switch rf.role {
case Follower:
...
case Candidate:
rf.mu.Lock()
rf.curTerm++
rf.votedFor = rf.me
rf.voteCount = 1
rf.persist()
rf.mu.Unlock()
...
}
time.Sleep(10 * time.Millisecond)
}
}
之后，就是 requestVote.go 中，需要在 RequestVote() 中添加持久化操作，
func (rf *Raft) RequestVote(args *RequestVoteArgs, reply *RequestVoteReply) {
// Your code here (2A, 2B).
rf.mu.Lock()
defer rf.mu.Unlock()
/*------------Lab2C Persist---------------*/
defer rf.persist()
...
}
就像上述一樣，調(diào)用 defer rf.persist() 即可，這樣就可以在離開函數(shù)之前將數(shù)據(jù)寫回磁盤，以及在 sendRequestVote() 中，
func (rf *Raft) sendRequestVote(server int, args *RequestVoteArgs, reply *RequestVoteReply) bool {
ok := rf.peers[server].Call("Raft.RequestVote", args, reply)
rf.mu.Lock()
defer rf.mu.Unlock()
if !ok {
return ok
}
term := rf.curTerm
/* 自身過期的情況下，直接不再唱票 */
if rf.role != Candidate || args.Term != term {
return ok
}
/* 碰到一個(gè)任期比自己高的人 */
if reply.Term > term {
rf.curTerm = reply.Term
rf.role = Follower /* candidate 主動(dòng)回滾至 follower */
rf.votedFor = NoBody
rf.persist()
return ok
}
if reply.VoteGranted {
rf.voteCount++
if rf.role == Candidate && rf.voteCount > len(rf.peers)/2 {
rf.role = Leader /* 至關(guān)重要 */
rf.leaderCh <- struct{}{}
}
}
return ok
}
在碰到一個(gè)任期比自己高的人之后，candidate 會(huì)更新自己的 curTerm 和 votedFor ，這里也需要注意持久化
最后來到 appendEntries.go 中，同樣在 AppendEntries() 中添上 defer rf.persist() 即可，
func (rf *Raft) AppendEntries(args *AppendEntriesArgs, reply *AppendEntriesReply) {
rf.mu.Lock()
defer rf.mu.Unlock()
/*------------Lab2C Persist---------------*/
defer rf.persist()
reply.Success = false
reply.Term = rf.curTerm
...
}
在 sendAppendEntries() 中碰見更新任期的情況下，也要持久化，
func (rf *Raft) sendAppendEntries(server int, args *AppendEntriesArgs, reply *AppendEntriesReply) bool {
ok := rf.peers[server].Call("Raft.AppendEntries", args, reply)
rf.mu.Lock()
defer rf.mu.Unlock()
if !ok {
return ok
}
term := rf.curTerm
/* 自身過期的情況下，不需要在維護(hù) nextIdx 了 */
if rf.role != Leader || args.Term != term {
return ok
}
/* 僅僅是被動(dòng)退位，不涉及到需要投票給誰 */
if reply.Term > term {
rf.curTerm = reply.Term
rf.role = Follower /* 主動(dòng)回滾至 follower */
rf.votedFor = NoBody
rf.persist()
return ok
}
/*------------Lab2B Log Replication----------------*/
if reply.Success {
...
} else {
...
}
return ok
}
至此，已經(jīng)功成大半，但測(cè)試的準(zhǔn)確率還不是 100%，是因?yàn)橛幸恍﹩栴}還需要考慮到
S4 - 在newRaft()中初始化nextIdxs和matchIdxs
記得要在 raft.go:Make() 的子函數(shù) newRaft() 中寫上定義 nextIdxs[] 和 matchIdxs[] 的代碼，不然會(huì)在 boatcastAE() 時(shí)出現(xiàn) index out of range 切片越界的問題，我想不懂為什么會(huì)這樣，因?yàn)榧词箼C(jī)器掉線了，它重新上線之后，也需要經(jīng)過選舉才能成為 leader，而成為 leader 的第一件事就是初始化 nextIdxs[] 和 matchIdxs[]
按理說，這兩個(gè)切片不可能在發(fā)送心跳包時(shí)為空，具體什么 bug，我稱之為玄學(xué)，看我代碼吧，
func newRaft(peers []*labrpc.ClientEnd, me int, persister *Persister, applyCh chan ApplyMsg) *Raft {
rf := &Raft{
peers: peers,
persister: persister,
me: me,
role: Follower,
voteCount: 0,
curTerm: 0,
votedFor: NoBody,
grantVoteCh: make(chan struct{}, ChanCap),
leaderCh: make(chan struct{}, ChanCap),
heartBeatCh: make(chan struct{}, ChanCap),
commitCh: make(chan struct{}, ChanCap),
nextIdxs: make([]int, len(peers)),
matchIdxs: make([]int, len(peers)),
applyCh: applyCh,
commitIdx: 0,
appliedIdx: 0,
}
/* 下標(biāo)從 1 開始，這非常重要，0 號(hào)位置存放默認(rèn)題目 */
rf.log = append(rf.log, LogEntry{Idx: 0, Term: 0})
for i := range rf.peers {
rf.nextIdxs[i] = rf.lastLogIdx() + 1
rf.matchIdxs[i] = 0
}
return rf
}
這樣就不會(huì)再出現(xiàn) index out of range 的情況了
S5 - 適當(dāng)縮短心跳時(shí)間
上面的幾種手段已經(jīng)能夠解決大部分錯(cuò)誤了，測(cè)試基本能夠到達(dá) 200 次只出現(xiàn)一個(gè)失敗的情況，即 one(%v) fail to agreement
這錯(cuò)誤提示的意思就是集群不能在有效的時(shí)間內(nèi)選出 leader，進(jìn)而完成日志同步的工作
很明顯，就是選主不夠快，最簡(jiǎn)單的辦法，即是縮短心跳時(shí)間，雖然在 Lab2: Raft 實(shí)驗(yàn)主頁 中建議我們心跳 1 s 中不超過十次，但是按照 100 ms 的頻率，從工程角度來看是不行的，我改成了 90 ms 就沒有此類的錯(cuò)誤了，
ElectionTimeOut = 250 * time.Millisecond /* 要遠(yuǎn)大于論文中的 150-300 ms 才有意義，當(dāng)然也要保證在 5 秒之內(nèi)完成測(cè)試 */
HeartBeatTimeOut = 90 * time.Millisecond /* 心跳 1 秒不超過 10 次 */
/* 生成隨機(jī)超時(shí)時(shí)間，在 250ms~500 ms 范圍之內(nèi) */
func randElectionTimeOut() time.Duration {
r := rand.New(rand.NewSource(time.Now().UnixNano()))
t := time.Duration(r.Int63()) % ElectionTimeOut
return ElectionTimeOut + t
}
/* 生成固定的心跳時(shí)間，固定值為 90 ms */
func fixedHeartBeatTimeOut() time.Duration {
return HeartBeatTimeOut
}
所以，我還是稱之為玄學(xué)。模型正確，不一定代表實(shí)現(xiàn)正確！
至此，已然講明白了 Lab2C: persist 整個(gè)一套流程
V. Result
golang 比較麻煩，它有 GOPATH 模式，也有 GOMODULE 模式，6.824-golabs-2020 采用的是 GOPATH，所以在運(yùn)行之前，需要將 golang 默認(rèn)的 GOMODULE 關(guān)掉，
$ export GO111MODULE="off"
隨后，就可以進(jìn)入 src/raft 中開始運(yùn)行測(cè)試程序，
$ go test -run 2C
僅此一次的測(cè)試遠(yuǎn)遠(yuǎn)不夠，可以通過 shell 循環(huán)，讓測(cè)試跑個(gè)兩百次就差不多了
$ for i in {1..200}; go test -run 2C
這樣，如果還沒錯(cuò)誤，那應(yīng)該是真的通過了。分布式的很多 bug 需要通過反復(fù)模擬才能復(fù)現(xiàn)出來的，它不像單線程程序那樣，永遠(yuǎn)是冪等的情況。也可以用我寫的腳本 test_2c.py，文章來源：http://www.zghlxwxcb.cn/news/detail-472670.html
import os
ntests = 200
nfails = 0
noks = 0
if __name__ == "__main__":
for i in range(ntests):
print("*************ROUND " + str(i+1) + "/" + str(ntests) + "*************")
filename = "out" + str(i+1)
os.system("go test -run 2C | tee " + filename)
with open(filename) as f:
if 'FAIL' in f.read():
nfails += 1
print("??fails, " + str(nfails) + "/" + str(ntests))
continue
else:
noks += 1
print("??ok, " + str(noks) + "/" + str(ntests))
os.system("rm " + filename)
我已經(jīng)跑過兩百次，無一 FAIL。之后的 Lab3: Fault-tolerant Key/Value Service 和 Lab4: Sharded Key/Value Service 都是基于 Lab2: Raft 的，要確保你實(shí)現(xiàn)的 Raft 算法沒有 bug，不然 Labs 越做到后面越難受文章來源地址http://www.zghlxwxcb.cn/news/detail-472670.html
到了這里，關(guān)于「實(shí)驗(yàn)記錄」MIT 6.824 Raft Lab2C Persist的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
