資料庫高可用性簡史

在網際網路出現之前，7*24小時的可用性基本是不可能實現的，而現在凌晨處理使用者請求已經成為了常態。當然，如果僅僅是依靠一臺電腦來實現這些請求是不太現實的，為了保證正常執行，最好是在滿足我們需求的多臺計算機之間分配負載。

分散式除了具備眾所周知的優點，也有很多明顯的缺點，例如其具有尖銳的邊緣，特別是在同步和容忍系統內部分故障的方面。資料庫中的分散式，與其它電腦科學領域的技術相比，發展比較緩慢，往往是軟體在跟蹤本地資料庫中的分散式計算結果，但資料庫本身的狀態儲存在一臺機器上。為什麼?因為跨機器複製狀態很難。

所以，本文就來探討一下分散式資料庫如何處理系統內的部分故障，並在其它層次上解釋一下高可用性。

Christina Chung

Active-Passive

以前，資料庫只在單臺機器上執行，只有一個節點，處理所有讀寫和寫入，自然也就是不存在“部分失敗”這樣的事情。

對於網際網路來說，單個資料庫的完全失敗是一個雙重問題，首先，計算機是全天候訪問的，因此停機時間直接會影響使用者;其次，一次請求失敗可能會導致系統不斷的請求，加重後果。而想要解決這個問題也很簡單，那就是擁有多臺可以處理請求的計算機，這就是分散式資料庫真正開始的故事。

在單節點世界中，最明顯的解決方案是繼續讓單個節點提供讀寫操作，並簡單地將其狀態同步到輔助被動機器上，這樣Active-Passive複製就誕生了。

Active-Passive透過在主節點發生故障的情況下進行最新備份來提高可用性，使用者可以將流量定向到Passive節點，並將其狀態轉換為active。無論何時，只要有伺服器出現問題，都可以用新的機器替換掉。

首先，從active節點到 passive節點的複製是一個同步過程，即在passive節點確認之前，不會提交轉換。但是，如果passive節點也發生故障，那麼就可能會讓人有些手足無措，如果要是備份系統不可用，那麼整個系統一旦崩潰就完蛋了。

為了進一步提高可用性，可以非同步複製資料。雖然體系結構看起來相同，但非同步複製能夠處理active或passive節點，而不會影響資料庫的可用性。

非同步Active-Passive已經是向前發展了一大步，但是其仍存在重大缺陷：

• 當active節點死亡時，尚未複製到passive節點的資料都可能丟失，而這時客戶端可能會認為資料已經完全提交了。

• 依靠一臺機器來處理流量，你仍然繫結到一臺機器的最大可用資源。

五個9：擴充套件到許多機器

網際網路的發展使得企業在規模和複雜性等方面的需求都有所增長，這對資料庫來說，則意味著它們需要能夠處理比任何單個節點處理的更多流量，並且要能夠提供“始終線上”的高可用性。鑑於現在很多工程師都有從事分散式技術的經驗，很顯然，超越單節點active-passive設定甚至在多臺計算機之間分配資料庫是完全有可能實現的。

Sharding

首先，也是最容易執行的地方是調整現有內容，工程師透過sharding將Active-Passive複製轉換為更具可擴充套件性的內容。在此方案中，您將叢集中的資料按某個值(例如主鍵中的行數或唯一值)進行拆分，並將這些段分佈在多個站點中，每個站點都有一個active - passive。然後可以在叢集前新增某種路由技術，以將客戶端定向到正確的站點獲取其請求。

透過sharding可以在多臺計算機之間分配工作負載，提高吞吐量，並透過容忍更多的部分故障來建立更大的彈性。

系統分片優勢很多，但其複雜性也給團隊帶來了巨大的運營負擔，計算分片可能會變得非常繁重，以至於路由最終會逐漸滲透到應用程式的業務邏輯中。如果您需要修改系統分片的方式(例如架構更改)，通常會帶來巨大的工程量。

Single-node Active-Passive系統也提供了事務支援(即使不是很強的一致性)，但跨分片協調事務實在是太困難了，因為很多分片系統都徹底放棄了。

Active-Active

鑑於分片資料庫難以管理且功能不全，工程師們開始開發至少可以解決其中一個問題的系統。雖然出現的系統仍然不支援交易，但卻更容易管理。隨著對應用程式正常執行時間的需求增加，幫助團隊滿足其SLA是一個明智的決定。

這些系統背後的思想是每個站點可以包含叢集的一些(或所有)資料併為其提供讀寫。每當一個節點接收到一個寫時，它就會將更改傳播到需要它的副本的所有其他節點。為了處理兩個節點接收到對同一金鑰的寫操作的情況，在提交之前，其他節點的轉換被輸入衝突解決演算法。考慮到每個站點都是“active”，它被稱為Active-Active。

因為每個伺服器都可以處理其所有資料的讀寫，所以分片在演算法上更容易完成，且部署更容易管理。

在可用性方面，Active-Active非常出色，如果節點失敗，客戶端只需要重定向到包含資料的另一個節點。只要資料的一個副本是活的，就可以為它服務讀寫操作。

雖然這種方案非常適合可用性，但其設計基本上與一致性不一致。因為每個站點都可以處理金鑰的寫入(並且在故障轉移方案中)，所以在處理資料時保持資料完全同步非常困難。相反，該方法通常是透過沖突解決演算法來調解站點之間的衝突，該演算法對如何“平滑”不一致性做出粗粒度的決策。

因為該解決方案是在事後完成的，這時客戶端已經收到有關過程的答案，且理論上已經基於響應執行了其他業務邏輯，因此，active-active複製很容易在資料中生成異常。但是，考慮到對正常執行時間的溢價，認為潛在異常的成本大於停機時間的成本，Active-Active成為主要的複製型別。

Scale一致性：Consensus & Multi-Active Availability

Active-Active似乎已經解決了基礎設施面臨的主要問題-可用性，但它只是透過放棄事務來實現的，這使得需要強一致性的系統沒有選擇空間。

例如，Google的廣告業務使用了一個龐大而複雜的分片MySQL系統，它嚴重依賴於SQL來任意查詢資料庫。由於這些查詢通常依賴於輔助索引來提高效能，因此它們必須與從它們派生的資料保持完全一致。

當系統變得足夠大是，分片MySQL就會出現問題，因此工程師就會開始設想如何解決擁有大規模可伸縮系統也能提供所需的強一致性。Active Active缺乏交易支援意味著它將不會是我們的選擇。

使用一致性複製，向節點提出寫入，然後將其複製到一定數量的其他節點。一旦大多數節點已經確認寫入，就可以提交。

Consensus & High Availability

這裡的關鍵思想是，一致複製是在同步和非同步複製之間取平衡，我們需要有任意節點來同步工作，這樣我們就可以忍受少數節點能夠有效能下降，且不會影響系統可用性。

一致性的代價是需要節點與其他人通訊來執行寫入，我們可以透過一些措施來減少節點之間的延遲，例如將它們放在相同的可用性區域中，如果所有的節點都在同一個資料中心，通訊就會很快，但無法在整個資料中心離線時繼續存在。將節點擴充套件到多個資料中心可能會增加寫入所需的延遲，但可以透過讓整個資料中心離線而不關閉應用程式來提高可用性。

Multi-Active Availability

CockroachDB實現了Google Spanner論文中的大部分知識，包括超出一致性複製的功能，使可用性更加簡單。為了描述其工作原理並將其與Active-Active區分開來，我們創造了術語“Multi-Active Availability”。

Active-Active vs. Multi-Active

Active-Active透過讓叢集中的任何節點為其金鑰進行讀寫來獲得可用性，但僅在提交寫之後才將其接受的任何更改傳播到其他節點。

另一方面，Multi-Active Availability允許任何節點提供讀和寫，但是確保大多數副本在寫(docs)時保持同步，並且只從最新版本(docs)的複製件進行讀取。

在可用性方面，Active-Active只需要一個副本即可用於兩個寫讀取，而Multi-Active需要大多數副本聯機以實現一致性(這仍然允許系統內的部分故障)。

這些資料庫可用性的下游是一致性的差異。Active-Active資料庫在大多數情況下都會接受寫操作，但不保證客戶端讀取資料的能力;而Multi-Active資料庫只在保證資料能夠以一致的方式讀取時才接受寫操作。

總結：

目前，業界開發了兩種主要的資料庫範例：Active-Active主要用於關注快速寫入的應用程式，而Active-Active用於需要一致性的應用程式。