在豬爸爸的努力下，三個銀行網(wǎng)點能正確的選出一個主網(wǎng)點對外提供服務(wù)了。一切工作的良好，但隨著客戶的增多，一些問題漸漸暴露出來。

這天，兔小姐又叫來了豬爸爸，說到：『豬爸爸，現(xiàn)在我們碰到了一個問題。每次客戶在 Leader 網(wǎng)點進(jìn)行一筆交易，我們都需要告訴其他兩個地方，只有我們確定了交易記錄被大多數(shù)網(wǎng)點保存了，這筆交易才會真正開始執(zhí)行，處理完了，我們才能繼續(xù)服務(wù)下一個客戶。已經(jīng)有很多客戶投訴我們效率慢了?！?/p>

『是的，兔小姐，之前我們設(shè)計的機(jī)制只能保證整個系統(tǒng)在出現(xiàn)了異常的時候，能夠安全的運行，不會出現(xiàn)金錢不一致的情況?，F(xiàn)在，是時候考慮對整個系統(tǒng)進(jìn)行優(yōu)化了，而且我已經(jīng)想到了很多優(yōu)化的手段?！回i爸爸信心滿滿的說到。

『那真的是太好了』兔小姐高興的說到，『你能跟我好好的說一下嘛？』
『當(dāng)然可以！』

Pipeline 和 Batch

『首先，我們來整理下現(xiàn)在的流程，假設(shè)客戶來存錢，我們會先記錄交易，然后給其他幾個網(wǎng)點發(fā)送消息，等我們確定大部分網(wǎng)點都確認(rèn)了這筆交易記錄，就可以開始執(zhí)行這筆交易，將用戶的錢存到金庫里面了?！?br> 『是的，豬爸爸』
『現(xiàn)在，為了后面簡單說明，我將整個流程簡化說明一下，其實就是幾個步驟，也就是 Propose，Append，Broadcast 和 Apply?？蛻舭l(fā)起交易，我們叫做 Propose，然后我們記錄交易，這個叫做 Append，再就是通知其他網(wǎng)點，這個叫做 Broadcast，等我們最后知道大部分網(wǎng)點都確認(rèn)了這筆交易記錄，我們就執(zhí)行交易，也就是 Apply。希望我這么簡化不會讓你困惑，兔小姐。』豬爸爸有點擔(dān)憂的詢問到。
『雖然有點抽象了，但我想我還是能理解的，豬爸爸。麻煩你繼續(xù)。』
『好的，兔小姐，既然你理解了簡化流程，那么我下面開始說第一個優(yōu)化，就是 Pipeline?！?br> 『Pipeline？這是什么，你完全把我搞糊涂了，豬爸爸』兔小姐吃驚的說到。
『不要緊張，兔小姐。Pipeline 就是管道，你可以把我們的整個流程想成一個 Pipeline。對于客戶 A，操作是 Propose，Append，Broadcast， Apply，對于客戶 B 也是一樣的流程，之前我們必須等 A 完成了，才能處理 B。但不知道你發(fā)現(xiàn)了沒有，兔小姐，當(dāng) A 在 Append 之后，我們就可以開始處理 B 的 Propose 了。』
『為什么呢？豬爸爸，我有點不明白了』
『我們只要保證的是所有銀行網(wǎng)點的交易記錄是一致有序的，那么我們就一定能保證最終所有銀行的數(shù)據(jù)是一致的，所以只要 A Append 了，B 開始 Propose，B Append 的時候交易記錄一定在 A 的后面，這樣記錄就一定是有序的了?！?br> 『我大概有點理解了?！煌眯〗阏f到。
『所以，兔小姐，當(dāng) A 執(zhí)行完 Append 之后，我們就能立刻開始處理 B，而當(dāng) B Append 之后，我們也可以立刻處理下一個用戶 C，這樣整個流程就是一個像水流那樣源源不斷流動的了，這不就是一個 Pipeline 了?！?br> 『嗯，真的是很形象，豬爸爸?！煌眯〗阌芍缘馁潎@道。

Batch

『我們還可以繼續(xù)優(yōu)化了，兔小姐。上面我們說到了 Pipeline，我們還可以做 Batch。』豬爸爸繼續(xù)說道。
『Batch？』兔小姐疑惑的說道。
『是的，Batch。也就是我們可以將很多單獨的操作合并到一塊處理?！?br> 『哦，這個我明白?！煌眯〗阏f道，『可哪里做 Batch 呢？』
『如果很多客戶同時要發(fā)起交易，那么我們可以將這些交易記錄，用一個消息發(fā)送過去到其他網(wǎng)點，這樣我們就不需要一個一個的發(fā)送消息了，這就是 Batch?！?br> 『哦，我明白了。因為我們各個網(wǎng)點之間距離還是有點遠(yuǎn)的，消息傳遞的時間開銷還是有點大的。所以使用 Batch 可以減少消息的發(fā)送次數(shù)，自然就能提高效率了，是吧，豬爸爸?！?br> 『非常正確，兔小姐?！?/p>

Leader 并發(fā)寫盤

上面說到了 Pipeline 和 Batch，這里我們再次說明一下整個 Raft 的流程。Leader 收到 Propose，Append Log，然后 Broadcast Log，等收到 Follower 的回復(fù)確定 Log 被 Committed 之后，開始 Apply。而對應(yīng)的 Follower，在收到 Log 之后，先 Append Log，然后給 Leader reply 消息，等下次 Leader 發(fā)過來的消息知道 Log 被 Committed 了，就可以 Apply 了，好了，我們繼續(xù)說故事吧。

『豬爸爸，有了 Pipeline 和 Batch，我們銀行的服務(wù)速度應(yīng)該會很快了?！?br> 『是的，兔小姐，不過我們還可以繼續(xù)優(yōu)化了?！?br> 『真的？』兔小姐有點不可思議。
『是的，你還記得我之前提到過的 quorum 吧。對于一筆交易記錄，如果我們知道大部分銀行網(wǎng)點都確認(rèn)了這筆記錄，我們就可以繼續(xù)處理交易了。』
『當(dāng)然記得，豬爸爸?！?br> 『當(dāng)用戶在 Leader 網(wǎng)點進(jìn)行交易的時候，原來我們的流程是 Propose，Append，然后在 Broadcast，但現(xiàn)在，我們在 Propose 之后，就可以直接 Broadcast，同時 Append，這兩個步驟在 Leader 網(wǎng)點是可以同時處理的?！?br> 『同時處理？豬爸爸，這沒什么風(fēng)險吧？』
『不會有任何風(fēng)險，即使 Broadcast 先進(jìn)行，Leader 網(wǎng)點這邊仍然需要在 Append 之后確保這筆記錄被大多數(shù)網(wǎng)點確認(rèn)了。』
『我想我有點明白了。也就是這兩個流程其實不相關(guān)，反正無論怎樣，后面 Leader 都必須等待 Follower 回復(fù)的確認(rèn)消息，才能最終確定這筆交易是否已經(jīng)被大多數(shù)網(wǎng)點接受了?！?br> 『對的，兔小姐。但這里我們需要注意，這個優(yōu)化只能在 Leader 網(wǎng)點進(jìn)行，在 Follower 網(wǎng)點這邊，我們?nèi)匀恍枰ＷC先 Append，再回復(fù)?！?br> 『哦，這又是怎么回事，豬爸爸？』
『我們上面說了，Leader 網(wǎng)點必須知道大部分網(wǎng)點都收到了交易記錄，才能認(rèn)為是 Committed，然后繼續(xù)處理。如果 Follower 網(wǎng)點這邊也直接先回復(fù)消息，在 Append，就可能出現(xiàn)一種情況，在 Append 之前，F(xiàn)ollower 網(wǎng)點出現(xiàn)了問題，導(dǎo)致 Append 不成功。那么極端情況下面就會出現(xiàn)，Leader 認(rèn)為記錄都已經(jīng)被大部分節(jié)點接受了，但實際并沒有，我們就很可能面臨數(shù)據(jù)丟失的問題了。』
『好復(fù)雜，但我貌似懂了?！煌眯〗闼妓髁艘粫f到。

小結(jié)

Raft 的 Paper 其實比較簡單，但如果實際按照 Paper 實現(xiàn)，會發(fā)現(xiàn)性能并不好，所以在實踐中，我們會做很多優(yōu)化，上面提到的只是一些優(yōu)化手段，還有一些，譬如 Leader 在發(fā)送一次 Log 之后不需要等 Follower 的回復(fù)，繼續(xù)發(fā)送后面的 Log，F(xiàn)ollower 只需要回復(fù)最近的一次 Log Index 或者 reject 就可以。

這些優(yōu)化方式在 etcd 和 TiKV 里面都有，大家可以自己去瀏覽代碼。