導語

在 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) 和 OceanBaseServer(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 鏈路上的組件。

鏈路性能優化

在 螞蟻金服OceanBase挑戰TPCC | 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 能力
PreparedStatement 是一種二進制的請求交互協議，一次 PSSQL 文本傳輸，多次執行，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 通常需要路由到不同 OBServer 上執行，產生大量遠程執行。遠程執行不僅會增加 RT，也會占用更多的 CPU 資源，因此，OBProxy 的 SQL 引擎會解析存儲過程中的 SQL，計算最優策略，將存儲過程調用發往最合適的 OBServer 上執行，盡可能的減少遠程執行次數。OBProxy 也會緩存存儲過程的解析結果和路由信息，用以省去每次硬解析帶來的 CPU 開銷。

復雜類型
我們在 OceanBase 原有傳輸協議上重新做了擴展，使得整個鏈路支持復雜類型的傳輸。同時，OBProxy新增了復雜數據類型的解析，能夠根據復雜類型數據來計算路由和分區裁剪。通過支持復雜類型，可以提高每次傳輸攜帶的數據信息，有效減少交互次數，也能夠根據復雜類型的數據計算最佳路由策略，盡可能的路由到分區更多的 OBServer 上，減少遠程執行次數。正是有了 OBProxy 對于數組等復雜類型的支持，才使得客戶端可以更好的使用存儲過程和 ARRAY BINDING 的能力。

代理資源占用

OBProxy 代理采用多線程異步框架和透明流式轉發的設計，保證了數據的高性能轉發（單核 5 萬 QPS、轉發 RT 30~50us），以及自身對機器資源的最小消耗。在 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 兼容模式，可以達到數據庫的易用性、高性能、服務持續的最大平衡。后續會持續優化傳輸協議以達到最高的傳輸及交互效率，完善數據庫訪問標準接口，為用戶提供一個更為成熟的數據庫服務。

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

總結

以上是生活随笔為你收集整理的蚂蚁金服OceanBase挑战TPCC丨TPC-C基准测试之链路层优化的全部內容，希望文章能夠幫你解決所遇到的問題。

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