OceanBase 的 CAP 分析

單元化架構中的成千山萬的應用就像是計算器，本身無 CAP 限制，其 CAP 限制下沉到了其數據庫層，也就是螞蟻自研的分布式數據庫 OceanBase（本節簡稱 OB）。

在 OB 體系中，每個數據庫實例都具備讀寫能力，具體是讀是寫可以動態配置。
實際情況下大部分時候，對于某一類數據（固定用戶號段的數據）任意時刻只有一個單元會負責寫入某個節點，其他節點要么是實時庫間同步，要么是異步數據同步。
OB 也采用了 PAXOS 共識協議。實時庫間同步的節點（包含自己）個數至少需要 (N/2)+1 個，這樣就可以解決分區容忍性問題。
下面我們舉個馬老師改英文名的例子來說明 OB 設計的精妙之處：假設數據庫按照用戶 ID 分庫分表，馬老師的用戶 ID 對應的數據段在 [0-9]，開始由單元 A 負責數據寫入。

假如馬老師（用戶 ID 假設為 000）正在用支付寶 App 修改自己的英文名，馬老師一開始打錯了，打成了 Jason Ma，A 單元收到了這個請求。
這時候發生了分區（比如 A 網絡斷開了），我們將單元 A 對數據段 [0,9] 的寫入權限轉交給單元 B（更改映射），馬老師這次寫對了，為 Jack Ma。
而在網絡斷開前請求已經進入了 A，寫權限轉交給單元 B 生效后，A 和 B 同時對 [0,9] 數據段進行寫入馬老師的英文名。
假如這時候都允許寫入的話就會出現不一致，A 單元說我看到馬老師設置了 Jason Ma，B 單元說我看到馬老師設置了 Jack Ma。
然而這種情況不會發生的，A 提議說我建議把馬老師的英文名設置為 Jason Ma 時，發現沒人回應它。

因為出現了分區，其他節點對它來說都是不可達的，所以這個提議被自動丟棄，A 心里也明白是自己分區了，會有主分區替自己完成寫入任務的。
同樣的，B 提出了將馬老師的英文名改成 Jack Ma 后，大部分節點都響應了，所以 B 成功將 Jack Ma 寫入了馬老師的賬號記錄。
假如在寫權限轉交給單元 B 后 A 突然恢復了，也沒關系，兩筆寫請求同時要求獲得 (N/2)+1 個節點的事務鎖，通過 no-wait 設計，在 B 獲得了鎖之后，其他爭搶該鎖的事務都會因為失敗而回滾。

下面我們分析下 OB 的 CAP：

分區容忍性：OB 節點之間是有互相通信的（需要相互同步數據），所以存在分區問題，OB 通過僅同步到部分節點來保證可用性。這一點就說明 OB 做了分區容錯。

可用性分區容忍性：OB 事務只需要同步到 （N/2)+1 個節點，允許其余的一小半節點分區（宕機、斷網等），只要 (N/2)+1 個節點活著就是可用的。

極端情況下，比如 5 個節點分成 3 份（2:2:1），那就確實不可用了，只是這種情況概率比較低。

一致性分區容忍性：分區情況下意味著部分節點失聯了，一致性顯然是不滿足的。但通過共識算法可以保證當下只有一個值是合法的，并且最終會通過節點間的同步達到最終一致性。

所以 OB 仍然沒有逃脫 CAP 魔咒，產生分區的時候它變成 AP+最終一致性（C）。整體來說，它是 AP 的，即高可用和分區容忍。

總結

以上是生活随笔為你收集整理的OpenBase关于一致性，可用性，分区容错性（CAP）分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。