OceanBase分佈式系統負載均衡案例學習

        一個集羣若是出現了負載不均衡問題，那麼負載最大的機器每每將成爲影響系統總體表現的瓶頸和短板。爲了不這種狀況的發生，須要動態負載均衡機制，以達到實時的最大化資源利用率，從而提高系統總體的吞吐。

OceanBase架構介紹

OceanBase是一個具備自治功能的分佈式存儲系統，由中心節點RootServer、靜態數據節點ChunkServer、動態數據節點UpdateServer以及數據合併節點MergeServer四個Server構成，以下圖所示。

• Tablet：分片數據，最基本的存儲單元，通常會存儲多份，一個Table由多個tablet構成；
• RootServer：負責集羣機器的管理、Tablet定位、數據負載均衡、Schema等元數據管理等。
• UpdateServer：負責存儲動態更新數據，存儲介質爲內存和SSD，對外提供寫服務；
• ChunkServer：負責存儲靜態Tablet數據，存儲介質爲普通磁盤或者SSD。
• MergeServer：負責對查詢中涉及多個Tablet數據進行合併，對外提供讀服務；

在一個集羣中，Tablet的多個副本分別存儲在不一樣的ChunkServer，每一個ChunkServer負責一部分Tablet分片數據，MergeServer和ChunkServer通常會一塊兒部署。

圖1.Tablet在三臺ChunkServer上的分佈

圖2.加入一臺機器Tablet遷移後的分佈

客戶端鏈接到OceanBase以後一次讀請求的讀流程以下圖所示:

1. Client 從RootServer獲取到MergeServer 列表；
2. Client將請求發送到某一臺MergeServer；
3. MergeServer從RootServer獲取請求對應的ChunkServer位置信息；
4. MergeServer將請求按照Tablet拆分紅多個子請求發送到對應的ChunkServer；
5. ChunkServer向UpdateServer請求最新的動態數據，與靜態數據進行合併；
6. MergeServer合併全部子請求的數據，返回給Client；

     分析以上的流程可知，在第2步客戶端選擇MergeServer時若是調度不均衡會致使某臺MergeServer機器過載；在第4步MergeServer把子請求發送到數據所在的ChunkServer時，因爲每一個tablet會有多個副本，選擇副本的策略若是不均衡也會形成ChunkServer機器過載[下面爲按照此處存在負載不均衡分析]。因爲集羣部署會在同一臺機器會同時啓動ChunkServer和MergeServer，沒法簡單區分過載的模塊。

ChunkServer是存儲靜態Tablet分片數據的節點，分析其負載不均的緣由包含以下可能：

1. 數據不均衡： ChunkServer上數據大小的分佈是不均衡的，好比某些節點由於存儲Tablet分片數據量多少的差別性而形成的不均衡；
2. 流量不均衡：數據即便是基本均衡的狀況下，仍然會由於某些節點存在數據熱點等緣由而形成流量是不均衡的。a.存在訪問熱點：好比熱銷的商品，這些熱點數據會致使ChunkServer成爲訪問熱點，形成了負載不均； b.請求差別性較大：系統負載和處理請求所耗費的CPU\Memory\磁盤IO資源成正比，而資源的耗費通常又和處理的數據量是成正比的，便可能是由於存在某些大用戶而致使沒有數據訪問熱點的狀況下，負載仍然是不均衡的。

負載均衡算法設計

若是把熱點ChunkServer上非熱點Tablet的訪問調度到其餘Server，是能夠緩解流量不均問題的，所以咱們設計了新的負載均衡算法爲：以實時統計的ChunkServer上全部tablet的訪問次數爲Ticket，每次對Tablet的讀請求會選擇副本中得票率最低的ChunkServer。

同時考慮到流量不均衡的第二個緣由是請求的差別較大問題，ChunkServer對外提供的接口分爲Get和Scan兩種，Scan是掃描一個範圍的全部行數據，Get是獲取指定一行數據，所以兩種訪問方式的次數須要劃分賦予不一樣的權重(α,β)參與最終Ticket的運算：

除此以外，簡單的區分兩種訪問模式仍是遠遠不夠的，不一樣的Scan佔用的資源也是存在較大差別的，引入平均響應時間（avg_time）這個重要因素也是十分必要的：

負載均衡算法要求具備自適應性和強的實時性，一方面新的訪問要實時累積參與下次的負載均衡的調度，另外一方面歷史權重數據則須要根據統計週期進行非線性的衰減（y 衰減因子），減小對實時性的影響：

本文摘自：

http://www.csdn.net/article/2013-02-28/2814303-sharing-OceanBase-distributed-system-load-balance-case