螞蟻金服自研數據庫 OceanBase 登頂 TPC-C 引起業內廣×××楚的展示其中的技術細節，我們特意邀請 OceanBase 核心研發人員對本次測試進行技術解讀，共包括六篇：
本文爲最後一篇，爲方便閱讀，我們將系列文章整理成PDF電子書，關注“螞蟻金服科技”官方公衆號，回覆“TPCC”即可下載。
導語
在 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 分佈式數據庫。簡歷請發送至 [email protected]