深入淺出 Raft - 基本概念

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

引子

因為一直在跟 Raft 打交道，雖然對 Raft 很熟悉了，但如果你要我去給一個完全不知道什麼是 Raft 的人講 Raft，我覺得難度還是非常大的。所以我決定使用我一貫羅裡吧嗦，用比喻和講故事的方式，來嘗試說說 Raft。

如果你跟你孩子一起看過小豬佩奇，你大概就能知道我為啥用了這麼怪的取名。如果沒看過的，強烈推薦你去看看，這真的是一部很不錯的兒童動畫。

日誌和狀態機器

兔小姐準備在泥坑小鎮成立一家銀行（就叫泥坑銀行吧）。對於銀行儲蓄系統的設計，兔小姐找來了豬爸爸。

兔小姐：『豬爸爸，我們要保證，無論怎樣使用者的金錢不能有錯誤。假如客戶存了 100 塊錢，那麼他的賬戶就會多出來 100 塊錢，不會是 101，也不會是 99。』
豬爸爸：『好的，兔小姐，我覺得我們可以這樣。如果一個客戶來存錢，那麼，首先我們可以將交易依次順序記錄下來，然後兔先生再把客戶實際的錢放到金庫對應的保險柜裡面。當兔先生把錢放好之後，我們就可以告訴客戶這筆交易完成了』
兔小姐：『好主意，豬爸爸，不過為什麼要先將交易記錄下來呢？直接放到金庫不就可以了嗎？』
豬爸爸：『首先，如果交易記錄都沒成功，那麼我們就不用再麻煩將錢放到金庫了。其次，假設同時很多人來存錢，兔先生有點處理不過來，沒準就會弄錯。我們有記錄的話，兔先生就可以按照記錄一個一個處理，雖然這樣慢一點，但不會出錯。另外，交易記錄永遠不可能被篡改或者被覆蓋，譬如如果我們在記錄 N 這個位置記錄下客戶 A 存了 100 塊錢，那麼這條記錄 N 後面一定是這筆交易，而不可能在變成客戶 B 取了 100 塊錢。』
兔小姐：『嗯，聽起來很有道理，那麼我們就這麼做吧。』

好了，雖然上面的例子有點不切合實際，畢竟如果銀行真這麼玩，離倒閉也就不遠了，但各位還是先認為這套機制能很好的工作吧。在 Raft 裡面，交易記錄，我們可以叫做日誌，而金庫，則是狀態機器。對於任何的操作，Raft 會首先將其記錄到日誌，然後等這個日誌提交之後，我們再將其對應的資料寫入到狀態機器裡面。每一條日誌都有一個唯一的編號，這個編號是嚴格按照加一單調遞增的，也就是說，leader 只會追加日誌，而不會覆蓋日誌。假設現在的日誌編號是 10，那麼下一條日誌的編號就一定是 11。如果這條日誌被應用到了狀態機器，那麼我們就可以認為這條日誌已經是被 applied 了。

Quorum

不久之後，泥坑銀行儲蓄系統第一個版本就上線了。一切工作的良好，直到有一天，電閃雷鳴，泥坑銀行停電了。使用者發現根本沒辦法進行交易了，雖然狗爺爺盡了最大的努力，但讓整個銀行正常工作也花了不少時間。銀行正常營業之後，兔小姐找來了豬爸爸。

兔小姐：『豬爸爸，現在看起來我們必須要保證，即使在泥坑小鎮的銀行出現了問題，譬如停電這種的，使用者仍然能夠正常的進行交易。』
豬爸爸：『是的，兔小姐。那要做到這樣，我們必須在其他地方建立另一個銀行網點，這樣，即使在泥坑小鎮銀行不能對外提供服務了，但客戶還是能在其他銀行網點進行交易。』
兔小姐：『好主意，豬爸爸，那麼我們 就在迴音山穀建立一個分部，當泥坑小鎮的銀行出現了故障，使用者仍然能夠在迴音山穀進行交易。』
豬爸爸：『兔小姐，恐怕只是在迴音山穀建立一個分部，是不行的。』
兔小姐：『為什麼呢？豬爸爸，我有點不明白了。』
豬爸爸：『現在假設我們在泥坑小鎮和迴音山穀都部署好系統，如果一個客戶到泥坑小鎮存錢，我們首先要在泥坑小鎮這邊記錄這筆交易，然後在通知迴音山穀那邊也記錄這筆交易，只有我們知道迴音山穀記錄交易成功了，我們才可以進行下一步，也就是將使用者的錢放到金庫裡面，同時告訴迴音山穀那邊，也需要將對應錢放到那邊的金庫，這樣如果泥坑小鎮出現了問題，客戶仍然能到迴音山穀那邊取錢。』
兔小姐：『這聽起來很複雜，但這樣看起來沒問題，所以將系統放到兩個地方，沒問題呀！』
豬爸爸：『不不，兔小姐。上面我說的是都兩邊都能正常工作的情況，但實際會有很多異常情況。譬如，假設泥坑小鎮這邊的系統能正常工作，但迴音山穀的出現了問題，那麼客戶來泥坑小鎮存錢，因為我們沒辦法在迴音山穀記錄這筆交易，所以使用者仍然不能存錢。』
兔小姐：『出現這種情況，我們還是先讓客戶能存錢吧，等迴音山穀系統好了再把相關的交易記錄放到那邊去，這樣不行嗎？』
豬爸爸：『當然不可以，兔小姐。因為我們要保證客戶金錢的絕對安全。假設客戶先在泥坑小鎮這邊存了錢，迴音山穀那邊可能因為出現了問題並不知道這筆交易，如果泥坑小鎮這邊的系統出現了問題，那麼使用者去迴音山穀取錢，就會發現，他在迴音山穀的錢還是之前的總額，這樣問題就大了。所以，如果只有兩個地方有系統，我們必須要保證這兩個地方的系統都完全能正常工作，任何一方出現了問題，整個系統就是停用。』
兔小姐：『哦，我大概明白了，那我們怎麼辦？』
豬爸爸：『如果我們要容忍一個地方的銀行不能對外提供服務，但客戶還是能正常的進行交易，我們至少需要在三個地方部署系統。』
兔小姐：『哦，我有點糊塗了，你能仔細解釋下嗎，為什麼三個就可以呢？』
豬爸爸：『好的，兔小姐。假設現在我們在三個地方有部署好了系統，譬如這三個地方就是泥坑小鎮，迴音山穀和海盜島吧。假設一個客戶來泥坑小鎮存錢，首先，我們會在泥坑小鎮記錄下這筆交易，然後告訴迴音山穀和海盜島也記錄下這次交易，如果迴音山穀或者海盜島有一個回複泥坑小鎮這邊交易已經被成功記錄，我們就可以允許客戶在泥坑小鎮將錢存到金庫了，然後在告訴迴音山穀和海盜島那邊可以存入金庫了。』

豬爸爸停頓了一下，喝了一口水，接著道：『上面我們說到，只要我們知道有兩個地方成功記錄下這次交易，我們就可以繼續存錢了，即使一個地方出現了問題也不會有問題。譬如，我們知道泥坑小鎮和迴音山穀成功記錄了交易，但海盜島因為一些問題導致了反饋延遲，但還能正常工作。然後泥坑小鎮這邊突然出現了問題，不能對外提供服務了，但我們還是能正常對外提供服務，因為我們知道最新的交易資訊已經被記錄到了迴音山穀，我們從迴音山穀這邊就一定能得到正確的金錢總數。但是，這時候我們仍然只有兩個地方能正常工作了，所以如果第二個地方出現了問題，我們仍然不能對外提供服務了。所以，如果我們要容忍兩個地方出現問題，但系統仍然能夠對外提供服務，我們就需要——』

『我們就需要在五個地方部署服務了，是吧，豬爸爸。』兔小姐直接插話道。
『是的，非常正確，兔小姐。』豬爸爸由衷的讚歎道。
『那麼我覺得我們先考慮三個地方吧，容忍一個地方不能工作就可以了，那就在迴音山穀和海盜島那邊也建立分部吧。』
『好的，兔小姐，不過其實我有點擔心海盜島那邊。。。。。。』
『就這麼決定了，豬爸爸』，兔小姐沒等豬爸爸說完，就直接做了決定。

好了，說了這麼多，還是回到現實中來吧。上面的例子，我們可是假設了金錢能被複製成多份放到不同的金庫裡面的，但現實銀行可不會這麼幹。為了要設計一個高可用的系統，單點問題是必須要解決的，畢竟如果這個點出現了問題，整個系統就沒法服務了。為瞭解決這個問題，我們需要在多個地方部署系統，但這樣就會引入另一個問題，也就是資料一致性的問題。

CAP

這裡我們來簡單說說 CAP，也就是一致性，可用性和分區容忍性。因為在分布式系統裡面，P 一定是避免不了的，所以我們無非就是選擇 C 或者選擇 A 的問題。通常 A 都是能做到 HA，也就是高可用的，所以對於需要完全保證資料安全的系統，我們一定會選擇 C。為了保證 C，我們在寫入資料的時候，一定會保證至少 quorum 的節點都成功被寫入了資料，才會認為這次寫入是成功的。 在 Raft 裡面，如果一條日誌被 quorum 的節點成功接收，那麼我們就可以認為這條日誌已經被 committed 了。

通常，我們說的 C，其實就是線性一致性，也就是我在某個時間寫入了一個值，那麼這個時間點之後的任何時間，我們讀到的就是這個最新的值，而不可能是老的。在資料寫入 quorum-節點之後，我們的讀取如果也能夠保證在 quorum-節點讀取，那麼就一定能讀到最新的值。這個就是 Amazon 的 Dynamo 做法，但這樣就把線性一致性保證的負擔落到了讀取資料的用戶端上面。Raft 採用了另一種簡單的做法，我們後續繼續說明。

小結

好吧，說了這麼多，說了這麼多，其實也就提了幾個 Raft 的概念。這裡稍微總結一下，Raft 使用的是 Log Replication + State Machine 的方式來處理分布式資料的一致性問題，這也是現在的通用做法。對於 Raft 來說，Log 的 ID 一定是加一單調遞增的，如果一個 Log 被至少 quorum 個節點接受，我們就可以認為這條日誌被 committed 了，然後就可以應用這條 Log，當 Log 被應用之後，改 Log 就是 applied 了。後面，我們將開始討論 Raft 的 Leader 了。