OceanBase 負載均衡的魅力
OB君 ：9月21日，OceanBase 2.0 在雲棲大會上重磅釋出。我們將在接下來的時間裡為大家持續推出 “ OceanBase 2.0 技術解析系列 ” 文章，分別從 可運維性、分散式架構、資料可用性、價效比及相容性 五個方面對OceanBase 2.0的產品新特性及其背後的技術原理進行深入的解析。
前面跟大家分享了可運維性方面的3篇文章，今天我們將從分散式架構聊起，跟大家分享關係資料庫在負載均衡方面的架構經驗。更多精彩歡迎關注OceanBase公眾號持續訂閱本系列內容！
本文作者：慶濤
現任螞蟻金服OceanBase資料庫技術支援專家，負責OceanBase資料庫的外部技術推廣和支援工作。曾經支援過B2B、天貓和阿里雲業務，熟悉Oracle/SQL Server/MySQL/OceanBase的運維和資料庫有關的架構方案的設計。
引言
隨著網際網路業務的普及，海量資料的儲存和訪問成了應用架構設計常見的問題。業務高峰期，應用幾百萬幾千萬的請求落在資料庫上時，資料庫如何保持穩定和擴充套件性？通過資料拆分，加上負載均衡設計是首選方法。本文總結了關係資料庫在負載均衡方面的架構經驗，進而介紹OceanBase分散式資料庫的負載均衡的獨特魅力。
負載均衡的傳統理解
負載均衡是一種設計，原理是用一個統一的中心入口收斂所有請求，然後依據一定的演算法將請求分發到後端多個節點處理。節點處理後的結果可以直接返回給客戶端或者返回給負載均衡中心，再返回給客戶端。
根據這個原理，負載均衡設計可以工作在OSI七層模型的二層（資料鏈路層MAC）、三層（網路層IP）、四層（傳輸層TCP）和七層（應用層）。越往上，原理越複雜，設計越智慧，越靈活。
市場上負載均衡產品有兩類。 一類是硬體實現 ：有獨立的硬體如F5，也有整合在網路裝置上的。 另一類是軟體 ，安裝在中心伺服器上。如 LVS，HAProxy，Keepalive， DNS LoadBalance等。軟體方案優點是配置簡單，操作靈活，成本低廉；缺點是依賴系統，有額外資源開銷，安全性和穩定性不是很高。硬體方案優點是獨立於系統，效能好，策略多；缺點是價格昂貴。
請求轉發演算法有多種，如輪詢（Round Robin，RR）、按權重輪詢（Weighted Round Robin）、隨機、權重隨機、按響應時間、最少連線數、DNS均衡等，可以根據實際場景選擇。
請求能夠轉發到後端任一節點，就表示後端節點都是無狀態的叢集，是分散式的。所以負載均衡一定是用在分散式叢集架構裡的。
集中式關係資料庫的負載均衡設計
1.叢集資料庫
商業關係資料庫的架構早期都是集中式的，只有主備架構應對高可用和容災。後來為了應對效能增長，發展出叢集資料庫。叢集資料庫的架構是將例項和資料檔案分離，資料檔案放在一個共享儲存上，例項節點水平擴充套件為多個，彼此共享同一份資料檔案。
例項節點是分散式的，在每個例項節點上，配置一個數據庫監聽服務監聽多個VIP（本地的和遠端的），監聽服務彼此也是一個小叢集，會根據各個例項節點負載資訊決定將請求轉發到何處。當新增例項節點時，會對各個例項節點的請求重新做負載均衡，平衡壓力。
【圖1】ORACLE RAC架構
叢集資料庫的問題也是很明顯的，就是資料儲存不是分散式的。一旦共享儲存發生故障，整個資料庫叢集都不可用。所以這個分散式架構並不完美。
2.分散式資料庫中介軟體
隨著中介軟體技術的發展，出現了一類分散式MySQL叢集。其原理是將資料水平拆分到多個MySQL例項裡，然後在MySQL前端部署一組中介軟體叢集負責響應客戶端SQL請求。這個中介軟體具備解析SQL，路由和資料匯聚計算等邏輯，是分散式的，無狀態的。在中介軟體前端會通過一個負載均衡產品（如SLB或LVS等類似產品）接受客戶端請求並分發到各個中介軟體節點上。
【圖2】分散式資料庫中介軟體架構
這個是通過分散式資料庫中介軟體去彌補傳統集中式資料庫的分散式缺陷。它將計算節點做到分散式，可以水平擴充套件；同時將資料也水平拆分到多個儲存上，也實現了分散式。相比叢集資料庫架構，分散式資料庫中介軟體能提供更高的效能，更好的擴充套件性，同時成本也更低。
這個分散式架構下，計算節點因為是無狀態的，擴充套件很容易。資料節點就沒那麼容易。因為涉及到資料的重分佈，需要新增例項，以及做資料遷移和拆分動作。這些必須藉助資料庫外部的工具實現。這種分散式依然不是最完美的。因為它的資料儲存是靜止的。
分散式資料庫的負載均衡設計
Google釋出了關於Spanner&F1產品架構和運維的論文，引領了NewSQL技術的發展，具體就是分散式資料庫技術。這個是真正的分散式資料庫架構。在這種架構下，資料是分片儲存在多個節點，並且可以在多個節點之間不借助外部工具自由遷移。
【圖3】Google F1架構
Google的F1節點是無狀態的，客戶端請求經負載均衡再到一個F1節點 ，F1不儲存資料，向Spanner請求資料。F1如果加機器就自動做分片的負載均衡。Google描述的分散式資料庫的負載均衡邏輯應該就是分散式資料庫架構的設計目標。
2010年，阿里巴巴和螞蟻金服開始自主研發分散式關係資料庫OceanBase。 單就負載均衡的設計而言，OceanBase不僅實現了增加減少節點後節點間自動負載均衡，自動做資料儲存重分佈，還進一步支援多種業務場景下負載均衡需求。
OceanBase 2.0的負載均衡設計
1.OceanBase 架構
在看OceanBase的負載均衡設計之前，先看看OceanBase 1.0版本的架構。在1.x版本里，一個observer程序囊括了計算和儲存兩項功能。每個節點之間地位都是平等的（有總控服務rootservice的三個節點稍有特殊），每個zone裡每個節點的資料都是全部資料的一部分，每份資料在其他幾個zone裡也存在，通常至少有三份。所以從架構圖上看OceanBase的計算和儲存都是分散式的。跟Google的區別是1.x版本里，計算和儲存還沒有分離。但不影響作為分散式資料庫的功能。
【圖4】OceanBase 1.x 架構
2. 分割槽、副本和OBProxy
OceanBase的資料分佈的最小粒度是分割槽（Partition），分割槽就是分割槽表的一個分割槽或者二級分割槽，或者非分割槽表本身就是一個分割槽。OceanBase的負載均衡的原理就跟分割槽有關。每個分割槽（Partition）在整個叢集裡資料會至少有三份，即通常說的三副本（Replica）。三副本角色為1個leader副本2個follower副本。通常預設讀寫的是leader副本。leader副本的預設分佈在哪個機房（zone），受表的預設primary zone屬性和locality屬性影響。在異地多活架構裡，充分發揮了這個locality屬性的作用。
由於Leader副本分佈位置是OceanBase內部資訊，對客戶端是透明的，所以需要一個反向代理OBProxy給客戶端請求用。這個OBProxy只有路由的功能，它只會把sql請求發到一個表的leader副本所在的節點。跟HAProxy不同，它沒有負載均衡功能，也不需要。不過OBProxy是無狀態的，可以部署多個，然後在前面再加一個負載均衡產品，用於OBProxy自身的負載均衡和高可用。
【圖5】OceanBase分割槽、OBProxy
3. 負載均衡的衡量標準
OceanBase的各個節點（OBServer）的地位都是平等的（總控服務rootservice所在的節點作用稍微特殊一些），當前版本每個OBServer還是集計算與儲存能力於一個程序中（2.x後期版本會發布計算與儲存分離）。OceanBase會維持每個節點的資源利用率和負載儘可能的均衡。這個效果就是當一個大的OceanBase叢集裡，有若干個資源規格大小不等的租戶執行時，OceanBase會避免某些節點資源利用率很高而某些節點上卻沒有訪問或者資源利用率很低等。這個衡量標準比較複雜，還在不斷探索完善中。所以目前沒有確定的直白的公式可以直接描述。但可以介紹一下會跟下列因素有關：
- 空間 ：每個節點上Partition總的使用空間以及佔用其配額的比例；每個租戶的Unit在該節點上的總空間以及佔用其配額的比例
- 記憶體 ：每個節點的OB的記憶體裡已分配的記憶體以及佔用其配額的比例
- CPU ：每個節點裡的Unit的已分配的CPU總額以及佔用其總配額的比例
- 其他 ：最大連線數、IOPS等。目前定義了這些規格，但還沒有用於均衡策略
- 分割槽組個數（PartitionGroup） ：每個節點裡的分割槽組個數。同一個表分組的同號分割槽是一個分割槽組。如A表和B表都是分割槽表，分割槽方法一樣，則它們的0號分割槽是一個分割槽組，1號分割槽是一個分割槽組。如此類推。
4.負載均衡邏輯演進
OceanBase負載均衡的原理就是通過內部調整各個observer節點裡的leader副本數量來間接改變各個節點的請求量，從而改變節點裡某些用於負載均衡衡量標準的值。調整過程中的資料遷移是內部自動做的，不依賴外部工具，不需要DBA介入，對業務影響可以控制。
在分散式下，跨節點請求延時對效能會有損耗。尤其是當叢集是跨多個機房部署的時候。所以，不受控制的負載均衡對業務來說並不是好事。在業務層面，有些表之間是有業務聯絡的，在讀取的時候，相應的Partition最好是在一個節點內部。此外，加上OceanBase的架構還支援多租戶特性。不同租戶下的資料儲存是會在一個或多個Unit裡分配。Partition並不是毫無規則的自由分佈。對業務來說，能對負載均衡策略進行控制是很有意義的。它方便了應用整體架構設計時能保持上層應用流量分發規則和底層資料拆分規則保持一致，這是做異地多活的前提，同時也定義了負載均衡能力的邊界。
所以，Partition的分佈實際還受幾點規則限制。第一，每個租戶下的所有Partition都在一組或多組Unit裡。Partition的遷移不能跳出Unit的範圍。一個OceanBase叢集裡有很多租戶，也就有很多Unit。OceanBase首先會調整Unit在節點間的分佈。這個稱為“Unit均衡”。只是Unit的遷移具體過程還是逐個Partition進行遷移。第二，同一個分割槽組的分割槽必須在同一個節點裡。分割槽的遷移的終態是同一個PartitionGroup的Partition必須在同一個OBServer節點裡。
【圖6】租戶、Unit、PartitionGroup和Partition
由前面知負載均衡策略其實就是對Partition的行為新增規則，設定邊界。隨著業務規模的增大，業務會把整體資料按模組拆分到多個租戶裡。所以就存在有些租戶之間的資料在業務層面是有關聯關係的。這就是租戶組的概念（TenantGroup）。在負載均衡的時候會考慮同一個TenantGroup的租戶下的Unit裡的Partition會分配在同一個節點上。這樣做的目的是為了避免應用一個業務邏輯多次資料庫調用出現跨機房。
最後總結一下，OceanBase的多種負載均衡策略的目標就是既儘可能的做到資源利用率均衡，又將其對效能的影響控制在一定的範圍。隨著業務規模的擴大和使用的深入，負載均衡策略和規則還會進一步完善。
5. 負載均衡的風險和實踐
負載均衡的效果在不同的業務場景下可能不完全一致。還需要具體問題具體分析。
如果叢集結構頻繁變動，比如說經常性的有機器變更和增減等，或者有租戶的新增和刪減，可能會導致頻繁的負載均衡操作。這個內部資料遷移過程會佔用節點一定的CPU和IO資源。某些對資料庫效能非常敏感的業務可能會受影響。所以需要運維人員適當的運用負載均衡的一些硬性規則限制等。如設定租戶、表的locality屬性，將leader分割槽限制在某幾個可以接受的zone內。又如對相關業務聯絡緊密的表設定相同的表分組進行約束等。如果採取這些措施還是經常發現有均衡操作帶來影響時，還可以關閉自動負載均衡操作。所有Unit和Partition的分配可以通過命令具體指定，即手動均衡。
6.計算與儲存分離
在2.x 版本里，OceanBase將實現一個分散式儲存，從而實現計算和儲存分離架構。此時計算節點彈性伸縮時通過遷移Partition實現負載均衡，儲存節點彈性伸縮通過遷移Block資料實現分佈均衡。同樣所有操作都是後臺非同步的，不借助於外部同步工具，不需要運維人員介入，不影響現有高可用，對效能影響可控。
總結
OceanBase的負載均衡是通過調整內部資料分割槽（Partition）的分佈來間接改變各個OBServer節點的被請求量，從而改變各個節點的負載。在調整過程中的資料遷移是內部非同步進行，不依賴外部同步工具，不需要DBA介入。期間高可用機制一直生效，對業務讀寫的影響可以控制。
OceanBase的負載均衡是受一定策略約束的，以避免對應用效能產生很大的影響。不受約束的負載均衡對業務來說可能得不償失。
OceanBase的負載均衡對業務和運維人員都是透明的，前端反向代理OBProxy會自動更新調整的分割槽的位置資訊。OBProxy是無狀態的，可以部署多份，並且可以通過F5或LVS等產品做OBProxy的高可用和負載均衡。注意區分這個不是OceanBase的負載均衡。
下期預告
本文是“OceanBase 2.0 技術解析系列”文章的第四篇，下一篇將為大家 全面解析OceanBase 2.0 的全域性一致性快照功能 。敬請期待！