螞蟻金服自研數據庫 OceanBase 登頂 TPC-C 引起業內廣泛關注，為了更清楚的展示其中的技術細節，我們特意邀請 OceanBase 核心研發人員對本次測試進行技術解讀，共包括五篇：

1）TPC-C基準測試介紹
2）OceanBase如何做TPC-C測試
3）TPC-C基準測試之SQL優化
4）TPC-C基準測試之數據庫事務引擎的挑戰
5）TPC-C基準測試之存儲優化

---

OceanBase 這次 TPC-C 測試與榜單上 Oracle 和 DB2 等其他數據庫在硬件使用上有非常大的不同，OceanBase 的數據庫服務器使用的是 204+3 臺型號是 ecs.i2.16xlarge 阿里云 ECS 服務器，其中 204 臺作為 data node，還有 3 臺作為 root node，每位讀者都可以在阿里云網站上輕松按需購買。如果讀者翻看 Oracle 和 DB2 的 TPC-C 測試報告會發現，這些數據庫都會使用專用的存儲設備，例如前最高記錄保持者 Oracle 在 2010 年的測試，使用了 97 臺 COMSTAR 專用的存儲設備，其中 28 臺用來存儲數據庫的重做日志（Redo Log）。

硬件的差異給軟件架構提出了完全不同的挑戰，專用的存儲設備其內部通過硬件冗余實現了設備自身的可靠保證，數據庫軟件在使用這樣的存儲設備時就天然的預設了數據不會丟失。但是，這種方式帶來了成本的極大消耗，專用的存儲設備的價格都是特別昂貴的。

OceanBase 使用通用的 ECS 服務器提供數據庫服務，并且只使用 ECS 機器自帶的本地硬盤做數據存儲，這是最通用的硬件條件。但是這種方式對軟件架構提出了很大的挑戰，因為單個 ECS 服務器的不如專用的存儲設備可靠性高。這也對 OceanBase 的事務引擎提出了很大的挑戰，OceanBase 是在普通的 ECS 服務器上就可以實現 ACID 特性。

TPC-C 測試是對事務 ACID 特性有完整并且嚴格的要求。下面分別介紹 OceanBase 針對事務 ACID 的特性的解決方案。

Paxos 日志同步保證持久性(Durability)

OceanBase 數據庫的事務持久性（Durability）保證是依賴事務重做日志（Redo Log）的持久性來達成的。所有的 Redo Log 會實時強同步到另外兩臺數據庫服務機器上，包含產生 Redo Log 的機器在內，總共會有三臺機器在硬盤中持久化 Redo Log。OceanBase 采用了 Paxos 一致性同步協議來協調這三臺機器上 Redo Log 的持久化，Paxos協議采用超過半數（也叫“多數派”）成功即算成功的算法（三個副本時，兩個成功即超過半數），當其中兩臺機器完成持久化后，事務即可完成提交，剩下的一臺機器的 Redo Log 在通常情況下，也是立即就持久化完成了。但如果這臺機器碰巧出現異常，也不會影響事務的提交，系統會在其恢復后自動補齊所缺失的 Redo Log。如果機器永久故障，系統會將故障機器所應負責同步的數據分散給集群內的其他機器，這些機器會自動補齊所缺失內容，并跟上最新的 Redo Log 寫入。

使用 Paxos 一致性協議的最大優勢是數據持久化和數據庫服務可用性（Availability）的完美平衡。當使用三個副本時，任何時候壞掉一個副本時至少還有另一個副本有數據，并且寫入還可以持續，因為還剩下兩個副本，后續的寫入也不受影響。所以，OceanBase 在保證了事務持久性的同時，也大大提升了數據庫的連續服務能力。TPC 組織的審計員在現場審計 OceanBase 持久性能力時，在客戶端持續產生壓力的情況下，從 OceanBase 集群中隨意挑選了一臺機器做了強制斷電操作，發現數據庫的數據不僅沒丟，數據庫不需要任何人工干預還能持續的提供服務，審計員們都很吃驚，并且對 OceanBase 大為贊賞。

依靠自動兩階段提交原子性(Atomicity)

TPC-C 測試模型的五種事務中的“訂單創建”和“訂單支付”兩個事務分別會對很多數據做修改，是其中相對復雜的兩個事務。TPC-C 標準對事務的原子性（Atomicity）是強制性的要求，要求一個事務內部對倉庫、訂單、用戶等表格的修改一定要原子的生效，不允許出現只有一半成功的情況。

OceanBase 的數據是按照倉庫 ID（Warehouse_ID）拆分到多臺機器上的，如果所有的事務都是發生在同一個倉庫內部，那么無論數據量有多大，事務的修改都只會涉及一臺機器的數據，也就是在一臺機器上完成事務提交，這是一種完美的線形擴展的場景。但是這不符合實際的業務場景，大多數的實際業務都會有很多不同維度之間的數據交互。TPC-C 測試標準也是對此認真考慮，所以對于事務操作數據的隨機性規則提出了要求，最終要保證產生 10% 的“訂單創建”事務和 15% 的“訂單支付”事務要操作兩個及以上的倉庫。在 OceanBase 數據庫內，這樣就產生了跨機器的事務操作，而這必須使用兩階段提交協議來保證原子性。

OceanBase 會自動跟蹤一個事務內所有 SQL 語句操作的數據，根據實際數據修改的位置自動確定兩階段提交的參與者，事務開始提交時，OceanBase 自動選擇第一個參與者作為協調者，協調者會給所有參與者發送 Prepare 消息，每個參與者都需要寫各自的 Redo Log 和 Prepare Log（也意味著每個參與者各自做自己的 Paxos 同步），等協調者確認所有參與者的 Redo Log 和 Prepare Log 完成后，然后再給所有參與者發送 Commit 消息，再等所有參與者的 Commit 工作完成。整個協議是在事務提交過程中自動完成，對用戶完全透明。OceanBase 為每一個兩階段提交事務自動選擇一個協調者，整個系統任何機器都可以分擔協調者工作，所以 OceanBase 可以將事務處理能力進行線形擴展。

多版本并發控制保證事務的隔離性(Isolation)

TPC-C 標準里要求“訂單創建”、“訂單支付”、“訂單配送”、“訂單支付”事務之間都是串行化隔離級別（Serializable）。OceanBase 采用的方法是基于多版本的并發控制機制。事務提交時會申請一個事務的提交時間戳，事務內的修改以新的版本寫入存儲引擎，并且保證之前版本的數據不受影響。事務開始時會獲取一個讀取時間戳，整個事務內數據的讀取操作只會看到基于讀取時間戳的已提交數據。所以，事務的讀取不會遇到臟數據、不可重復讀數據以及幻讀數據。同時，事務的修改會在修改的數據行上持有行鎖，保證兩個并發的修改相同行的事務會互斥。

OceanBase 的全局時間戳生成器也是由多副本組成，可以獨立部署在三臺機器上，也可以像這次 TPC-C 評測中一樣部署在 root node 機器上，與 root node 共享資源。全局時間戳的三副本是一種極高可用的架構，任何一次時間戳的獲取操作都至少在三臺機器上的兩臺獲得了確認，所以任意一臺機器出現故障，獲取時間戳的操作不會有一點影響。

按照 TPC-C 標準，OceanBase 準備了 9 種不同的場景測試有讀-讀、讀-寫沖突時事務的隔離性，最終都完美通過了審計員的審計。

一致性保證(Consistency)

在有了上述的事務能力后，OceanBase 可以完美的保證各種數據的一致性的約束。TPC-C 標準里提出了 12 種不同的一致性測試場景在各種測試運行前后對數據庫內的數據進行一致性校驗。因為 OceanBase 此次測試數據規模龐大，一致性校驗的 SQL 需要核對大量的數據，所以一致性校驗的挑戰在于校驗的 SQL 本身運行的效率。基于 OceanBase 的并行查詢能力，發揮整個集群所有的計算資源，校驗 SQL 的運行時間均縮短了幾個數量級，很好的完成一致性功能的審計工作。

復制表

TPC-C 測試模型中有一張商品（ITEM）表，這張表的內容是測試所模擬的銷售公司所有售賣的商品信息，包含了商品的名字、價格等信息。“訂單創建”事務執行中需要請求這張表內的數據來確定訂單的價格信息，如果商品表的數據只存放在一臺機器上，那么所有機器上發生的“訂單創建”事務都會請求包含商品表的機器，這臺機器就會成為瓶頸。OceanBase 支持復制表功能，將商品表設置為復制表后，商品表的數據會自動復制到集群中的每一臺機器上。TPC-C 標準不限制數據的副本數，但是不管數據的組織形式，標準里要求事務的 ACID 一定要保證。OceanBase 使用特殊的廣播協議保證復制表的所有副本的 ACID 特性，當復制表發生修改時，所有的副本會同時修改。并且，當有機器出現故障時，復制表的邏輯會自動剔除無效的副本，保證數據修改過程中不會因為機器故障出現無謂的等待。復制表在很多業務場景中都有使用，例如很多業務中存儲關鍵信息的字典表，還有金融業務中存儲匯率信息的表。

總結

OceanBase 堅持在普通的PC服務器上實現高可靠、高可用、高性能、可擴展的數據庫，實現了用廉價硬件和云計算的部署環境提供最關鍵的數據庫服務的能力。后續，我們會持續優化事務處理的性能，豐富事務的各種功能特性，為用戶提供更好用的數據庫服務。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的蚂蚁金服OceanBase挑战TPCC|TPC-C基准测试之数据库事务引擎挑战的全部內容，希望文章能夠幫你解決所遇到的問題。

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