分布式系統的一致性演算法------《Designing Data-Intensive Applications》讀書筆記13

標籤：ati   database   持久性   ade   約束   重複   markdown   環境   ges   

一致性演算法是分布式系統中最重要的問題之一。表面上看，這似乎很簡單，只是讓幾個節點在某些方面達成一致。在本篇之中，會帶大家完整的梳理分布式系統之中的共識演算法，來更加深刻的理解分布式系統的設計。

1.原子提交和兩階段交易認可（2PC）

原子提交防止了資料庫處於半更新的狀態，這對於需要滿足多個物件事務和維護次級索引的資料庫尤為重要。每個次級索引都是從主要資料中分離出來的資料結構，因此，如果修改某些資料，也需要在次級索引中做出相應的更改。通過原子性保證二級索引能夠與原資料保持一致。

分布式系統下的原子提交

我們先來看看，在一個單一的節點上是如何?原子提交的：
對於執行在一個單一資料庫節點的事務，當用戶端向資料庫提交事務時，資料庫首先將事務資訊添加到磁碟上的日誌進行提交。如果資料庫在這個過程中間崩潰，則在節點重新啟動時從日誌中恢複事務。如果在崩潰前將提交記錄成功寫入磁碟，則認為事務被提交，如果沒有，則該事務的任何寫入都復原。在單一的節點的資料庫下，事務的原子提交取決於持久化寫入磁碟的順序，使得事務的提交原子化。

如果事務中涉及多個節點呢？情況就變得十分複雜了：

• 有些節點可能檢測到約束違反或衝突，需要中止，而其他節點能夠成功地提交。

• 一些提交請求可以在網路中丟失，最終中止由於逾時，而其他提交請求獲得通過。

• 某些節點可能在提交記錄完全寫入和復原恢複之前崩潰，而另一些節點則成功提交。

所以，一個節點必須確定事務在所有其他節點也要提交時才能進行提交。我們必須要有一種演算法能夠讓分布式節點達成共識。

兩階段交易認可（2PC）。

兩階段交易認可協議就是我們要談到的第一個分布式共識協議。如所示

• 通過一個協調器，當應用程式準備提交時，協調器節點開始的第1階段。它向每個參與的資料庫節點發送一個準備請求，詢問它們是否能夠提交？然後協調器追蹤參與者的響應，如果所有參與者都能回答：是，表示他們準備提交，那麼協調器在第2階段發出一個提交請求，則所有參與者同時進行提交，如果任何參與者回答：否，則協調器向第2階段的所有節點發送一個中止請求。

兩階段交易認可的問題

一旦出現了網路故障或參與者失效，協調器節點可以通過逾時機制來中止事務。二如果在階段二出現提交或中止事務失敗，協調器節點可以無限重試直到故障恢複。但是，如果這個過程之中協調器節點崩潰了，將會產生許多頭疼的問題：

如果協調器在發送準備請求之前失敗，參與者可以安全地中止事務。但是，一旦參與者收到了一個準備請求並回答了：是，它就必須等待從協調器節點的指令，事務是被提交還是中止。而一旦協調器節點崩潰或出現網路故障，參與者只能無限期的等待。如所示：

由於協調器在將提交請求發送到Database 1之前崩潰了，因此Database 1不知道事務是否提交。如果資料庫1單方面中止暫停之後，它的結果與Database 2產生不一致。 唯一的辦法是等待協調器恢複，這就是為什麼在向參與者提交或中止事務請求之前，協調器必須將其提交或中止的結果寫入本地磁碟上的交易記錄。當協調器恢複時，它通過讀取其交易記錄確定所有可疑事務的狀態。任何在協調器日誌中沒有提交記錄的事務都會被中止。

2.協商一致性

由上文我們可以瞭解，在分布式系統之中可以使用兩階段交易認可協議來實現的事務(也可以使用兩階段交易認可協議的升級版三階段提交協議)。分散式交易雖然解決了分散式資料庫之中的事務實現，但是它也引入了新的問題，事務協調器本身也是一種資料庫（在其中儲存事務的結果）。如果協調器只在一台機器上運行，很容易就會產生單點故障問題。而預設情況下，許多協調器實現不是高可用的，只有基本的副本備份功能。許多伺服器端應用程式以無狀態模型為基礎，將持久性狀態都儲存在資料庫中，其優點是可以隨意添加和刪除應用伺服器。但是，當協調器成為應用程式伺服器的一部分時，它會改變部署的性質。因為協調器的日誌同樣成為了需要持久化狀態儲存的內容。一方面，分散式交易很難實現完整的一致性保障。另一方面，由於協調器節點的存在，分散式交易會大大降低資料庫的效能，所以很多資料系統放棄了對分散式交易的支援。

協商一致性

其實分散式交易困痛點就在於實現一致性，它要求系統之中多個節點達成共識。例如，如果有幾個人同時嘗試預訂飛機上的最後一個座位或同一個劇院的座位，或者試圖用相同的使用者名稱註冊一個帳戶，則可以使用一致性演算法來最終確定哪種哪個操作是成功的，並且在分布式系統的節點之中達成一致的共識。

而協商一致性通常的形式如下：一個或多個節點可以提出取值，而協商一致性演算法決定其中一個值。 協商一致性的核心理念：每個人都決定相同的結果，一旦你決定了，你就不能改變你的想法。我們可以先簡化這個模型，摒棄容錯性：可以指定一個節點成為Leader，由Leader節點做出所有的決定。但是，如果Leader節點失效，則系統陷入癱瘓。兩階段交易認可協議之中的協調器就是一個Leader，一旦協調器失效了，系統無法進行工作。而更好的協商一致性演算法要求，即使某些節點失效了，系統仍然能夠正常工作。當然，如果所有節點都崩潰了，並且沒有一個節點正在運行，那麼任何演算法都不可能雞血運行，所以說演算法可以容忍的故障數量是有限的：事實上，可以證明任何協商一致演算法至少需要大多數節點正常運行，來確保協商一致。

一致性演算法與全序廣播

在分布式系統之中存在許多協商一致性演算法演算法如：Paxos，Raft，Zab等等。本篇之中，不會涉及到不同演算法的全部細節，會通過他們來瞭解一些進階思想。（後續大家有興趣會給大家來詳解這些演算法）

這裡的一致性演算法符合全序廣播的特性，全序廣播需要以相同的順序向所有節點精確地傳遞一次訊息。在每一輪的協商之中，每個節點都可以提出下一個要發送的訊息，然後由協商達成一致，並在系統之中傳遞的下一條訊息。所有節點共同決定以相同的順序傳遞相同的訊息，且訊息不重複，訊息不會被破壞，也不會憑空產生。（這裡忽略拜占庭問題，如果需要引入拜占庭容錯，需要採用類似於區塊鏈之中的Pow演算法）

####epoch編號和Leader選舉

每一輪的訊息都進行協商，是缺乏效率的行為。所以類似於Raft與Zab等協議都利用Leader機制來進行最佳化。所以協商一致協議需要選舉出Leader，並且保證Leader是獨一無二的。如何來保證分布式節點對Leader節點的選舉結果的共識呢？這裡利用分布式的時序機制，每一個通過合法選舉出的Leader存在一個epoch編號，來確保Leader是獨特的。 一旦Leader節點失效，則各個節點之間開始投票選出新的Leader，新的Leader會產生一個新的epoch值，所以epoch值是根據Leader選舉順序單調遞增的。如果兩個不同的Leader在發生衝突（也許是因為前一個領導人實際上並沒有死），那麼所有節點會認同更高的epoch值。

Leader需要做出的每一個決策，它都必須將提議的值發送給其他節點，並等待節點的集合來響應提議。此時協商一致需要達到法定人數，也就是組成叢集的大多數節點。一個節點會投票贊成一個提案，只有當它不知道任何其他Leader具有更高的epoch值。協商一致性分為兩個運行階段：一:選擇一個Leader，二：投票表決Leader的提議。當Leader收到法定人數的投票結果同意提案，則可以斷定，沒有一個具有更高epoch值的Leader，然後它可以安全地提交結果。(可以用反證法證明) 這個投票過程雖然看起來類似於兩階段交易認可。最大的差異是協調器節點的容錯，來保證協商一致演算法高度可用性。

3.協商一致性的代價

協商一致性演算法是分布式系統的一個重大突破：它給所有其他不確定的系統帶來了具體的解決方案，並且它仍然是容錯的（只要大多數節點都能正常工作），並且提供全序廣播的特性，因此他們也可以在容錯的方式實現線性化的原子操作。

天下沒有免費的午餐，這種好處是有代價的。

• 協商過程之中需要對提案進行表決，而這個表決的過程本質上是一種同步複製。前文我們已經探討過同步複製與非同步複製的優缺點。而在實踐之中，我們通常配置使用非同步複製。某些提交的資料可能在容錯移轉時丟失，但為了更好的效能，許多人選擇接受這種風險。

• 協商一致性嚴格要求需要多數決。這意味著你需要至少三個節點來容忍一個故障（剩下的兩個組成多數），或者至少五個節點來容忍兩個故障（剩下的三個組成多數）。

• 大多數協商一致演算法假設一組固定的節點參與投票，這意味著不能動態添加或刪除叢集中的節點。

• 如何檢測失效的節點也是一個問題。在具有高度可變網路延遲的環境中，經常發生一個節點錯誤地認為Leader的失效。雖然這個錯誤不會損害系統的安全性，但是頻繁的Leader選舉會導致系統糟糕的表現，因為系統最終會花費更多的時間去選擇一個領導者而不是做任何有用的工作。

所以設計對不可靠網路更健壯的演算法仍然是我們電腦工作者需要挑戰和研究的問題。

小結：

從兩階段交易認可協議起步，我們梳理了分布式系統下的一致性演算法，並且分析了它們的優劣。通過這些外包出去的分布式協調服務作為基本模型，我們才能實現更多，更加複雜的分布式服務。

分布式系統的一致性演算法------《Designing Data-Intensive Applications》讀書筆記13