本文根據 OceanBaseDev Meetup#1 上海站分享整理，本次活動針對分布式資料庫的分布式事務以及落地實踐展開具體分享。
本文作者：羨林，螞蟻集團進階技術專家，2012年畢業于北京郵電大學計算機專業。2013年加入 OceanBase 團隊，參與了OceanBase 1.0 及 2.0 版本的設計與開發，目前主要負責 OceanBase 高可用及一緻性相關的工作。分享視訊以及 PPT 檢視位址見文末。
本文将首先介紹實作高可用資料庫所面臨的挑戰，然後從幾個方面介紹解決高可用問題所需的分布式一緻性技術的相關内容，希望對你有所幫助。
在關系資料庫系統之中，事務需要滿足 ACID 特性。其中，"D"表示"持久性"(Durability)，即一旦事務完成，則事務對資料庫的影響就不會丢失。
DBMS 複雜性的一個重要原因就是需要滿足持久性：資料庫中的任何修改直到該修改被存儲到非易失性的輔助存儲器中，才能認為這個修改是最終有效的。
資料是企業的核心命脈，滿足持久性是資料庫系統正确服務的先決條件。在此基礎上，随着資訊時代的發展，客戶對資料庫系統提出了更高的要求，即服務不能停，要求最基礎的資料庫系統提供高的可用性。
以支付寶為例，支付寶的客戶24小時均會使用支付寶提供的服務，這對整個系統提出了非常高的挑戰。
客觀現實及傳統資料庫的解決方案
如果系統不出現任何故障，那麼同時實作資料的可靠存儲和服務的持續可用也許是簡單的。
但在真實場景中，故障是不可避免的。有多種可能的故障原因：
• 硬體故障: 磁盤、網絡，甚至 CPU 和 Memory 均可能出現故障。以硬體廠商的統計資料為例，硬碟的年故障率達到1.25%, 伺服器的年故障率會更高；
• 軟體故障：作業系統、檔案系統以及資料庫系統本身，均有可能出現軟體故障；
• 人為誤操作：運維人員和 DBA 在運維、更新系統時，存在誤操作的可能，每個操作均如履薄冰；
• 故障範圍：随着系統規模越來越大，故障可能出現的範圍從單機、機架，到整個機房甚至一個城市；
傳統資料庫一般通過共享存儲或主備同步的方案來應對可能出現的故障。
在共享存儲的方案中，往往依賴于高端硬體來提高可用性，這一方面需要更高的成本，另一方面在共享存儲出現故障時，整個系統仍需要停服務，甚至有丢資料的風險。除此之外，共享存儲不支援跨機房部署，無機房級的容災能力。
在主備同步的方案中，無法平衡服務的可靠性和可用性。主備同步本質上隻有兩種選擇：異步同步和強同步。異步同步無法保證在主庫故障時資料的可靠性，而強同步無法保證在主庫、備庫或網絡三者任一出現故障時系統的可用性。
分布式一緻性協定
如上所述，共享存儲和主備同步的方案在故障場景下均無法很好的平衡資料的可靠性和系統的可用性。針對此問題，計算機科學家、圖靈獎獲得者 Leslie Lamport 早在20多年前就提出了對應的解決方案，也就是著名的 Paxos 協定。
我們先來看下 Wiki 裡對分布式一緻性協定的說明：
• Consensus is the process of agreeing on one result among a group of participants.
• This problem becomes difficult when the participants or their communications may experience failures.
通過 Paxos 協定，使用三副本/五副本，可以很好的平衡資料的可靠性和系統的可用性；在少數派副本出現故障時，Paxos 協定可以確定系統資料不丢，且服務持續可用。
在 Paxos 協定裡，有兩種不同的角色：
• Proposer: 提案發起者；
• Acceptor: 提案接受者，對 Proposer 的消息進行應答；
一個或多個 Proposer 可以發起提案，系統需要對所有提案中的某一個提案達成一緻，協定保證最多對一個确定的提案達成一緻。
一個基本的 Paxos 流程分 prepare、accept 兩步，如下圖所示：
Paxos協定的詳細内容參考論文《Paxos Made Simple》。另外，Raft 協定作為 Paxos 協定的一個變種，其論文《In Search of an Understandable Consensus Algorithm (Extended Version)》也值得細讀。
OceanBase 一緻性工程實踐
OceanBase 是最早将 Paxos 協定用于關系型資料庫的系統之一。通過資料多副本，OceanBase 用軟體手段在普通 PC 伺服器上實作了金融級的資料高可靠和系統的高可用，實作了 RPO = 0 以及 RTO < 30s。通過提供多種部署模式的選擇，可以分别實作機器級、機房級以及城市級的容災能力。
如下，是 OceanBase 的一個簡化的部署結構圖。圖中每個 ZONE 是一個容災域，每個 OBServer 是一個資料庫服務節點，每個 OBServer 中包含多個Paxos Group 提供服務。
這一小節分别介紹 OceanBase 使用的 Multi-Paxos 協定，為了節省成本開發的日志副本功能，以及為了保證資料正确性所做的一系列工作。
Multi-Paxos
在資料庫系統中，實作事務的持久性依賴的是 redo log。使用 Paxos 協定，每一條 redo log 即對應一個 Paxos Instance。
如果使用基本的 Paxos 協定決定一條 redo log 的内容，至少會有兩輪 RPC 延遲。基于此，使用 Multi-Paxos 協定對 redo log 的同步做優化，在系統穩定的情況下，一條 redo log 的同步，僅需要一輪 RPC 延遲。
Multi-Paxos 協定需要有一個穩定的 Leader。OceanBase 通過一個選舉協定在多個副本中選擇一個 Leader，所有的讀寫請求均通過 Leader 進行。寫請求會要求日志同步到多數派副本後應答用戶端持久化成功，而讀請求僅需要通路 Leader 即可保證讀取到最新的資料。
Leader 作為 Multi-Paxos 協定的 Proposer。假定 Proposer 比較穩定，可以一次性對所有的 Paxos Instance 做 prepare，所有 Paxos Instance 共用一個 maxPreparedProposalNO。
一輪具體的 Multi-Paxos 流程如下：
• 選舉協定從所有副本中選擇出一個 Leader 節點，作為 Proposer；
• Proposer 選擇一個 ProposalID 對所有日志進行 Prepare； Follower 節點（也是協定中的 Acceptor）收到後進行檢查：
如果未收到過更大 ProposalID 的請求，則接受此 Prepare 消息，并回複 LocalMaxLogID;
否則直接忽略此請求;
• Reconfirm: Proposer 收到多數派 Acceptor 對 Prepare 的響應，選取響應中 LocalMaxLogID 最大值，記做 ReconfirmMaxLogID，假設本地最大确認 LogID 為 K，對于 [K+1, ReconfirmMaxLogID] 範圍内所有日志，通過 Prepare/Accept 兩階段重新執行 Paxos 協定流程;
• Leader Active: Reconfirm 完成後，切換到此狀态提供資料的讀寫服務；
Multi-Paxos 實作了日志的亂序同步，對網絡抖動的容忍性更好。
日志副本
傳統資料庫的主備同步同一份資料儲存了兩份，而 Paxos 協定作為一個多數派協定，需要至少三副本。我們為了提供高可用能力付出了額外的成本，那這部分成本是否可以減小甚至消除呢?
首先，我們分析一個副本所需的資源類型：CPU、記憶體、磁盤空間。
作為一個備副本而言，CPU 和記憶體主要用于 redo log 的回放，而磁盤空間主要用于存儲使用者資料和 redo log。和使用者資料相比，redo log 所占用的磁盤空間是非常少的，常常隻需要十分之一甚至更少，并且可以重複使用。
基于上述分析，OceanBase 提供了日志副本功能，這樣的副本不回放 redo log，節省了 CPU 和記憶體的開銷，同時不存儲使用者資料，僅需要很少的磁盤空間用于 Paxos 投票。
在具體部署上，資料庫伺服器可以交叉部署正常副本和日志副本，也可以采購低配低成本伺服器，僅用于存儲日志副本。
資料正确性保證
Paxos 協定是分布式資料庫系統的基石，而通過 Paxos 協定實作的多副本資料一緻性又是一切資料正确性的前提。
OceanBase 從兩方面來確定資料的正确性。
1.異常測試
在測試階段模拟各類異常是確定正确性的基礎。具體工作如下：
• 設計了專門測試 Paxos 協定流程的測試架構，mock 寫盤和網絡，模拟亂序、丢包、延時等多種場景，測試協定正确性；
• 數十個容災測試用例，測試資料節點遇到各類異常時的行為；
• 代碼随機錯誤注入，模拟記憶體配置設定失敗、随機的網絡丢包；
• 多個內建測試環境，7*24 不間斷的做各類容災測試；
2.完備的 checksum 校驗
除異常測試外，在系統運作過程中，設計了多個次元的 checksum 校驗，用于實時發現可能的資料正确性問題：
• 日志體/完整日志（日志頭+日志體）/單次寫入塊的三個層次的 checksum 校驗，用于發現記憶體寫壞、磁盤靜默錯誤等問題；
• RPC packet checksum 實時校驗，用于發現可能的網絡包的資料問題；
• 單個日志流的累積 checksum 校驗，任何一條日志都會校驗從所在日志流第一條日志開始到本日志結束的所有日志内容的 checksum 校驗和，用于確定多個副本資料的嚴格一緻；
總結
分布式一緻性協定是實作原生分布式資料庫的關鍵技術之一。本文首先介紹了實作高可用資料庫所面臨的挑戰，然後從幾個方面介紹了解決高可用問題所需的分布式一緻性技術的相關内容。原生分布式是資料庫的未來，在走向未來的過程中，一定有更多有意思的挑戰，還有非常多的技術難題和挑戰等着我們，歡迎感興趣的小夥伴加入我們！（歡迎發送履歷到 [email protected] ）
回顧資料
• 視訊回顧：
https://www.bilibili.com/video/BV1wt4y1q7Eg• PPT 檢視位址：
https://tech.antfin.com/community/activities/1283/review/1013• 《Paxos Made Simple》：
https://lamport.azurewebsites.net/pubs/paxos-simple.pdf• 《In Search of an Understandable Consensus Algorithm (Extended Version)》 ：
https://raft.github.io/raft.pdf