支撐螞蟻金服上百個關鍵業務的OBProxy到底牛在哪裡？

OB君：OBProxy是OceanBase專用的反向代理伺服器，從2015年開始設計編碼發布，目前已經伴隨著OceanBase穩定支撐阿里/螞蟻內部上百個關鍵業務，以及多家外部客戶。本文將從Why、What、How角度深入解析OBProxy。

本文作者：蕭石

本文作者：嚴華

現任螞蟻金服OceanBase團隊高級開發工程師，2015年加入OceanBase後一直從事數據鏈路/SQL引擎方面的研發工作。

OceanBase作為典型的分散式關係資料庫，從產品架構層面可以分為以下三部分：

服務端產品：由若干分散式ObServer組成，均包含SQL引擎/存儲引擎/分散式事務引擎，共同配合提供一個高可用、可擴展的分散式關係資料庫系統。

數據鏈路產品：提供從用戶端到資料庫端的最佳鏈路訪問功能，屏蔽用戶對分散式資料庫的感知，保障分散式資料庫的最高性能服務。

雲管控平台：提供OceanBase雲產品服務，簡化在使用OceanBase過程中的運維和業務開發複雜度，做到輕鬆上雲。

其中, 數據鏈路的核心產品是就是本文的主角——OBProxy。OBProxy作為OceanBase專用的反向代理伺服器，從2015年開始設計編碼發布，經過螞蟻金服內外部業務的多年打磨，目前已經伴隨著OceanBase穩定支撐阿里/螞蟻內部上百個關鍵業務，以及浙商銀行、南京銀行、PayTM等多個外部金融客戶。本文將從Why、What、How角度分別講解OBProxy，希望幫助大家藉此加強對OceanBase的架構思想和高性能原理的理解。

為什麼要OBProxy?

分散式關係資料庫與單機資料庫最大的不同在於數據存儲在多個節點，並不會因為單節點的異常導致整體的數據丟失。然而用戶的使用方式還是不變，還是期望的。分散式資料庫中每個server都能提供服務，那麼用戶該訪問哪個server呢？由於數據是分散式存儲，用戶的DML請求發給不同的server執行的性能必然有所差異，用戶的請求該發往哪個server呢？ 假如分散式的多個server中宕機一台server，那如何不讓用戶受到影響影響呢？針對這些分散式資料庫都會遇到的問題，各個產品的解法各不一樣。

Google的F1分散式關係資料庫採用的數據鏈路。如上圖，用戶通過F1 client發出請求，請求會首先根據負載均衡組件發給最優的F1節點上的F1 server，F1的Spanner節點中的大部分F1 server是無狀態SQL引擎，不存儲數據，而是依賴Spanner從CFS中讀取的數據。Spanner將數據多副本方式存儲, 可以指定版本數據的讀取, 但是寫操作需要在leader serevr執行. 因此實際中共同負責承擔路由和容災的功能，即要保證client訪問的是最優的鏈路的F1 server和Spanner，同時F1 server和Spanner要具備容災能力[1]。

基於分庫分表+MySQL實現的分散式關係資料庫採用的數據鏈路。如上圖，用戶通過各類MySQL驅動發送請求，經過負載均衡組件路由到任意一個的中間件上，中間件根據分庫分表規則將用戶請求拆分發到各個分散式的MySQL上， 每個MySQL執行自己分配的SQL，中間件最後負責將結果匯總組合返回給用戶。MySQL由主備server組成，其中一台server的宕機不影響MySQL整體服務，一台中間件的宕機不影響負載均衡組件路由到其他無狀態的中間件上。因此這裡由負載均衡組件 + 中間件完成路由和容災功能。

當前OceanBase採用的數據鏈路是。如上圖，其中用戶通過任意MySQL驅動發出請求，請求通過負載均衡組件訪問到任意一台無狀態的OBProxy上，OBProxy將用戶請求轉發到後端OceanBase集群中最佳的ObServer去執行。這裡負載均衡組件可以是市場上常見的產品如SLB，OBProxy不負責分庫分表，也不作為SQL引擎參與執行計劃的生成調度，只負責純粹的反向代理轉發。每個ObServer均包含完整SQL引擎和存儲引擎，負責解析用戶SQL生成物理執行計劃並執行，分散式的ObServer之間通過Paxos協議保證高可用。這種架構設計中，OBProxy只承擔基本的路由和容災功能，而資料庫的功能全部交由ObServer實現。這樣更加簡單明確的分工可以各組件性能做的更加極致，OceanBase整體最高也能做到訪問單機資料庫的性能。

為什麼OBProxy不能使用市場上其他DB Proxy代替呢？ 因為市場上通用DB Proxy基本是面向MySQL Server設計的，並不適用分散式的OceanBase。為OceanBase量身定製的OBProxy能夠對非分區表/分區表的路由更加準確，能和observer的配合更加完美。其次，定製化的OBProxy可以提供對更多OceanBase集群支持，以及便利運維OBProxy的支持。最後，定製化的OBProxy可以站在用戶的角度做跟多實用的優化，方便用戶使用OceanBase。

OBProxy是什麼？

OBPrxoy是為OceanBase資料庫專門量身定製的反向代理伺服器，用戶的數據在OceanBase上以多副本的形式存放在各個ObServer上， OBProxy負責接收用戶發過來的SQL請求，轉發用戶請求SQL路由到最佳目標ObServer上，並將執行結果給用戶。作為OceanBase資料庫產品不可或取的一部分，OBProxy具備以下特性：

高性能轉發：OBProxy完整兼容MySQL協議，採用多線程非同步框架和透明流式轉發的設計，保證了數據的高性能轉發（單核5萬QPS），以及自身對機器資源的最小消耗（內存不超過50M,單cpu不超過20%）。

最佳路由：OBProxy需要充分考慮用戶請求涉及的的副本位置、用戶配置的讀寫分離路由策略、OceanBase多地部署的最優鏈路，以及OceanBase各機器的狀態以及負載情況，將用戶請求路由到最佳的ObServer，最大限度的保證OceanBase整體性的高性能運轉。

連接管理：針對一個Client端的物理連接，OBProxy維持自身到後端多個ObServer的連接，採用基於版本號的增量同步方案維持每個ObServer的連接在同一狀態，保證了Client高效訪問各個ObServer。

定製協議：原生MySQL協議存在報文CRC校驗缺失，Request ID校驗缺失的正確性缺陷，而OBProxy默認使用OceanBase定製協議予以解決，保證了和ObServer之間鏈路的正確性。

易運維：OBProxy本身無狀態，支持同時訪問多個OceanBase集群，支持無限水平擴展。並且可以通過豐富的內部命令實現對自身狀態的實時監控，實現自身冷熱升級/下線/重啟等常見運維操作，可以提供極大的運維便利性。

儘管OBProxy已經在代理轉發上做的很極致，但是始終是要經過兩次網路延遲開銷。為了最小化解決這個問題，在實際高性能要求的場景中，可以選擇將OBProxy部署在Client端所在機器上，由守護進程保證OBProxy進程的高可用，Client到ObServer實際只有最短一跳網路路徑，這樣用戶可以通過訪問本地的OBProxy來實現對遠端分散式OceanBase資料庫服務的訪問。OBProxy自身運行非常小的資源消耗也能保證這一部署的可行。

另外，大家肯定很好奇，其他資料庫的數據鏈路產品通常都支持分庫分表/SQL審計等中間件功能，為什麼OBProxy不支持？

其實分庫分表只是傳統資料庫解決單一資料庫並發訪問性能不足和存儲瓶頸問題的一種常用擴展手段，傳統資料庫依賴數據鏈路產品的分庫分表中間件邏輯來幫助實現高性能的資料庫服務，而OceanBase並不依賴這個。OceanBase通過一級分區/二級分區的分區表的手段解決上述問題，而OBProxy也不必改寫用戶請求SQL，只需要根據用戶的請求SQL計算出所涉及的分區的目標ObServer地址，然後透明轉發代理。

另外，根據OceanBase的架構設計，OBProxy只需專心做代理，SQL功能交給後端ObServer支持。並且OBProxy後端對應的ObServer都屬於同一個OceanBase集群，並不是其他資料庫相互獨立的資料庫實例。因此其他中間件的SQL審計等SQL層功能只需要OceanBase本身支持，不需要依靠數據鏈路產品單獨實現。

OBProxy是如何設計實現的？

OBProxy的主要架構可以簡單描述如上圖所示，其中非同步框架實現高效的代理轉發，通信協議實現OBProxy與Client和ObServer之間通信方式，連接管理實現OBProxy的連接池功能，路由選擇實現對用戶請求的的最優路由選擇,而容災模塊則負責監控OceanBase集群狀態。監控運維提供對OBProxy的豐富運維手段，集群管理實現OBProxy對OceanBase多集群的支持。以上組件相互依賴配合，共同實現OBProxy的整體功能。

下面選取OBProxy比較核心的組件進行詳細說明。

非同步框架

多線程的非同步框架是OBProxy的核心組件，包括事件處理，網路包處理，轉發流程三部分功能。基於狀態機模型的設計，也使得OBProxy整個轉發流程更加流式高效。

OBProxy在啟動時，會根據當前機器的CPU核數創建一組工作線程，每個工作線程上運行著獨立的非同步事件處理程序。的一個物理連接在連接之後，會被分配到一個OBProxy工作線程上執行直到該連接生命期結束。而對於該Client連接，OBProxy按需維持了多個的server連接，這些連接亦綁定在相同的工作線程上。由於OBProxy和ObServer均完整兼容MySQL協議，因此Client端發給OBProxy的請求，OBProxy根據路由選擇模塊確定最佳ObServer後，直接將該網路報文轉發的ObServer，並將ObServer的回包轉發給Client端，整個流程中除了和的的兩次網路報文讀取，以及和的兩次網路報文寫入之外，沒有其他IO開銷，也沒有該報文在內存中來回拷貝的開銷，因此這樣做到了真正的透明流式轉發。

至於流量控制問題，OBProxy採用生產者消費者模型，以ObServer生產數據，Client消費數據為例，數據流向可以描述為：, 相當於一個consumer和一個producer共用一個buffer，這個buffer如果超過40KB，就不從網路上讀取數據。即假如consumer消費慢，producer生產快，一旦共用的buffer超過40KB，OBProxy不允許再生產數據，直到consumer消費掉，OBProxy再允許producer繼續生產數據。也就是說，用戶的一次查詢，OBProxy最多hold 40KB的數據，並不會存在常見的流量異常而導致OBProxy內存佔用過大的問題。

路由選擇

路由選擇是OBProxy的核心功能，如前所述說，路由選擇的輸入用戶的SQL，用戶配置規則，ObServer的狀態，路由選擇的輸出是一個可用ObServer地址。其路由邏輯可以入下圖所示：

其中，解析SQL模塊使用OBProxy自己定製的語法parser模塊，只需要解析出DML語句中資料庫名/表名/hint，不需要其他複雜的表達式推演等，因此parser模塊做的十分高效。

路由規則確定模塊中，OBProxy需要根據不同情況確定最佳的路由規則。比如強一致性讀的DML請求期望發到副本leader的ObServer上，弱讀的DML請求和其他請求則不要求，leader和follower均衡負載即可。如果OceanBase集群是多地部署，OBProxy還提供了LDC路由，優先發給同機房的ObServer，其次是同城的ObServer，最後才是其他城市的ObServer。如果OceanBase集群是讀寫分離部署，OBProxy還需要提供讀zone優先，只限讀zone，非合併優先等規則供業務按照自身特點配置。上述的幾種情況在路由選擇中是組合關係，輸出是一個確定的路由規則。

獲取路由表是指OBProxy根據用戶的請求SQL獲取該SQL涉及的副本位置。OBProxy每次首先會嘗試從本地線程緩存中獲取路由表，其次是全局緩存，最後才是發起非同步任務去向ObServer查詢路由表。對於路由表的更新，OBProxy採用觸發更新機制。OBProxy每次根據路由錶轉發給ObServer的請求，當ObServer不能本地執行時，會在回包時反饋給OBProxy。OBProxy根據反饋決定是否下次強制更新本地緩存路由表。那麼什麼時候路由表才會變化呢？通常是在ObServer合併或者負載均衡導致切主發生才會發生。

選擇目標ObServer則是根據上上一步確定的路由規則從上一步獲取的路由表中選擇最佳的ObServer，在經過黑名單/灰名單檢查通過後作為最終的目標server進行請求轉發。ObProxy的容災機制是通過黑名單/灰名單實現，下面單獨說明。

容災

OBProxy的容災策略主要影響路由選擇和連接管理，主要包含黑名單和灰名單兩種檢查，用於處理ObServer錯峰合併、升級、宕機、啟動/停止，網路分區等狀態。黑名單採取定期刷新維護，由ObServer反饋哪些server節點死不可用。灰名單採取主動觸發維護，當OBProxy轉發請求給ObServer，如果發現ObServer返回特定的系統錯誤，或者ObSerer在N秒內有M次連續不可用，則將該ObServer加入灰名單。黑名單中的ObServer將被過濾不訪問，但是灰名單中的ObServer每隔一段時間會重試一次，檢查是否需要洗白，以避免長時間將ObServer拉黑。

對於用戶的連接，通常情況下是。而在Client的一個事務中，只會使用到一個的連接。對於其他非事務中的連接，如果ObServer發生異常導致網路連接斷掉，OBProxy會關閉該無效的連接，Client端將對此無感知不受影響。

總結

OBProxy作為OceanBase的專用反向代理伺服器，是OceanBase資料庫能夠最高性能服務用戶必備組件，也是目前OceanBase外部市場輸出的標配。儘管OBProxy已經十分成熟穩定，但在橫向的外部市場開拓上，OBProxy作為資料庫「中間件」，自身還可以做的更多；在縱向的資料庫研發上，OBProxy作為數據鏈路的一環，發展還很長。這裡也歡迎有志之士前來勾搭，共同為OceanBase的壯大貢獻最好的力量！

參考資料：[1] F1: A Distributed SQL Database That Scales

想跟本文作者嚴華深入交流嗎？

想認識螞蟻金服OceanBase團隊的一線技術專家嗎？

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！