資料庫高可用性簡史

在互聯網出現之前，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用於需要一致性的應用程序。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！