作者:易鴻偉 閆建良 王光樹

在 TPC-C 標準定義中，測試系統分為 RTE(Remote Terminal Emulator)和 SUT 兩部分。在實際的 TPC-C 測試流程中，不只是對 DB 端能力的考驗，對鏈路 中的所有元件都存在極大的資源消耗和壓力。以這次 6088 萬 tpmC 測試結果看，我 們一共在 64 臺 64C128G 的雲伺服器上運行了 960 個 RTE 客戶端，來模擬總計 47942400 個使用者 Terminal，最後還需要基於這麼多 RTE 統計結果進行一致性 和持久化審計驗證。而 SUT 又拆分為三部分:WAS(Web Application Server)、 OceanBase Proxy(OBProxy) 和 OceanBase Server(OBServer)。RTE 的 請 求 到 WAS，然後 WAS 通過 OceanBase 客戶端來訪問 OBProxy，OBProxy 會將請求 轉發到後端 OceanBase 叢集中最佳的 ObServer 去執行請求。WAS 和 OBProxy 是 RTE 和 OBServer 之間的橋樑，這個橋樑對於承載壓力起著至關重要的作用。本 次 TPC-C 基準測試中，OceanBase 訪問鏈路上主要涉及兩個元件:

• ODBC 介面及驅動:TPC-C 測試中，WAS 請求 OceanBase 採用了 ODBC 介面。ODBC(Open Database Connectivity) 是 Microsoft 提出的 資料訪問規範，ODBC 在大多數 DBMS 上都可以使用，OceanBase 也提供 了 ODBC 介面訪問能力。感興趣的使用者可以查閱 ODBC API 說明 快速上手 使用，使用 ODBC 的使用者可以直接使用該介面無縫遷移的訪問 OceanBase。 ODBC 介面及驅動整合到 WAS 內部，作為請求 OceanBase 的客戶端。
• OBProxy 代理:OceanBase 實現了 OBProxy 代理伺服器來解決資料庫鏈 路上的路由及容災問題。OBProxy 會感知資料副本地址和分割槽規則，不參 與 SQL 引擎參與執行計劃的生成排程，主要負責 SQL 路由和轉發。這種架 構設計中，OBProxy 承擔了基礎的路由和容災功能，而資料庫的功能全部交

由 OBServer 實現。這樣更加簡單明確的分工可以各元件效能做的更加極致， OBProxy 也做到了完全無狀態，只需要新增節點即可實現代理能力的水平擴 容，OceanBase 整體也能做到資料庫的最高效能。

TPC-C 基準 OceanBase 鏈路訪問圖

TPC-C 是一個非常嚴苛的基準測試模型，考驗的是一個完備的關係資料庫系統 全鏈路的能力，任何一個環節有瓶頸均無法發揮資料庫的最大效能，接下來本文會 分別在效能、成本及服務持續三個方面來說明下是如何優化 OceanBase 鏈路上的 元件。

鏈路效能優化

在 TPC-C 基準測試之 SQL 優化已經提到，從整個鏈路的角度來看，SQL 所 需要的執行時間是非常短暫的，大量時間花費在與客戶端的互動過程中，造成資 源的浪費和耗時的增加，為此 OBServer 提供 Prepared Statement、儲存過程和 ARRAY BINDING 能力。客戶端和 OBProxy 針對該能力進行支援以使其真正發 揮作用。同時客戶端本身也進行一些優化提升鏈路效能，接下來主要介紹鏈路效能部 分的優化點:

• 提供非同步介面能力:通常使用資料庫訪問都是同步介面，同步介面開發方便， 但客戶端受網路互動耗時影響大，併發能力受到限制。使用多執行緒的方式可以 幫助提升併發能力，但機器的執行緒資源是寶貴的，過多的執行緒會增加機器線 程切換的開銷，限制了併發能力。為使 WAS 可以達到更高的吞吐能力，我 們基於事件驅動機制在 ODBC 介面內增加非同步介面的支援。使用非同步介面， WAS 單個執行緒內可以在傳送請求後無需等待執行結果繼續在其他 Session 上 傳送請求，通過充分使用執行緒資源從而大幅提升吞吐能力。非同步介面本身參 考 ODBC 介面規範，使用者呼叫非同步介面會立即返回，如果尚未執行完成則返 回 SQL_STILL_EXECUTING，使用者可以輪詢介面直到執行完成返回成功 (SQL_SUCCESS)或者失敗(SQL_ERROR)，也可以基於網路事件驅動， 在有結果返回時再次呼叫介面獲取結果。使用非同步介面，可以在少量執行緒資源 下輕鬆支援大量的併發連線，極大的提升了 WAS 的併發能力，機器資源的利 用率也得到提升，大幅降低壓測成本。
• 提 供 Prepared Statement 能 力:Prepared Statement 是 一 種 二 進 制 的 請 求互動協議，一次 PS SQL 文字傳輸，多次執行，OBProxy SQL 引擎會緩 存 PS SQL 文字以及解析結果，每條 PS SQL 只需要執行一次 Prepare 操 作，後續所有 Session 上的每次執行只需要傳入對應的 Statement Id，就可 以從快取中找到對應的 SQL 解析結果，結合傳入的引數，可以很快的計算出 OBServer 的路由資訊，轉發效能更為高效。同時，作為代理層的 OBProxy 也很好的支援了 OBServer 的分散式特性，當 Client Session 需要切換 Server Session 時，無需再次傳送 PS SQL 和 Execute 階段時的型別資料， OBProxy 可以自行判斷並決定是否需要同步 PS SQL 或加上型別資料。通 過 Prepared Statement 能力，可以有效減低系統間的互動成本，提升效能，相比普通 SQL 文字的互動方式，省去了大量 SQL 文字的傳輸以及請求文字 解析的 CPU 開銷。
• 儲存過程:對於儲存過程，OBProxy 做了大量優化，儲存過程通常包含多條 SQL，不同 SQL 通常需要QQ拍賣地圖路由到不同 OBServer 上執行，產生大量遠端執 行。遠端執行不僅會增加 RT，也會佔用更多的 CPU 資源，因此，OBProxy 的 SQL 引擎會解析儲存過程中的 SQL，計算最優策略，將儲存過程呼叫發往 最合適的 OBServer 上執行，儘可能的減少遠端執行次數。OBProxy 也會緩 存儲存過程的解析結果和路由資訊，用以省去每次硬解析帶來的 CPU 開銷。
• 複雜型別:我們在 OceanBase 原有傳輸協議上重新做了擴充套件，使得整個鏈 路支援複雜型別的傳輸。同時，OBProxy 新增了複雜資料型別的解析，能夠 根據複雜型別資料來計算路由和分割槽裁剪。通過支援複雜型別，可以提高每次 傳輸攜帶的資料資訊，有效減少互動次數，也能夠根據複雜型別的資料計算最 佳路由策略，儘可能的路由到分割槽更多的 OBServer 上，減少遠端執行次數。 正是有了 OBProxy 對於陣列等複雜型別的支援，才使得客戶端可以更好的使 用儲存過程和 ARRAY BINDING 的能力。

代理資源佔用

OBProxy 代理採用多執行緒非同步框架和透明流式轉發的設計，保證了資料的高性 能轉發(單核 5 萬 QPS、轉發 RT 30~50 us)，以及自身對機器資源的最小消耗。 在 TPC-C 基準測試中，我們也採用了本地的形式部署到 WAS 端，這樣可以最大程 度的的減少客戶端到代理層的網路開銷。在本次測試中，OBProxy 代理層部署到 64 臺客戶端機器上，每臺機器上使用到了 10 個 Core，一共佔用 640 Cores，僅佔整 體 CPU 測試成本的 7% 左右，幾乎沒有使用儲存資源，資源佔用比例小且支援水平擴容。

持續服務能力

OceanBase 提供了高可用的資料庫服務，在出現機器不可用的場景下，不需要 有任何人工干預資料庫依然能夠持續提供服務，在本次 TPC-C 做 Durability 測試強 制斷電操作中，OceanBase 就表現出無人工干預下的資料庫持續服務的能力，大大 超出審計員的期望。

OceanBase 針對強制斷電這種單機故障場景，OBProxy 有包含黑名單和灰 名單兩種機制，用於處理 OBServer 錯峰合併、升級、宕機、啟動 / 停止，網路分 區等狀態。黑名單採取定期重新整理維護，由 OBServer 反饋哪些伺服器節點不能提供 服務。灰名單則採取主動觸發維護，當 OBProxy 轉發請求給 OBServer，如果發 現 OBServer 返回特定的系統錯誤，或者 OBServer 在一段時間內有多次連續不 可用，則將該 OBServer 加入灰名單。黑名單中的 OBServer 不會被訪問，灰名 單中的 OBServer 每隔一段時間會重試一次，檢查是否需要洗白，以避免長時間將 OBServer 降級。通過 OceanBase 這樣的機制，能夠保障 TPC-C Durability 測 試過程中的資料庫持續服務能力。

總結

OceanBase 鏈路層為客戶提供了端到端的完整解決方案，其自研的傳輸協議 能夠非常靈活的支援 SQL 特性和互動協議，實現了標準的資料庫訪問介面並支援 Oracle 相容模式，可以達到資料庫的易用性、高效能、服務持續的最大平衡。後續 會持續優化傳輸協議以達到最高的傳輸及互動效率，完善資料庫訪問標準介面，為用 戶提供一個更為成熟的資料庫服務。