淘寶在“雙十一”背后，OceanBase分布式系統負載均衡的經驗分享。

云計算所具備的低成本、高性能、高可用性、高可擴展性等特點與互聯網應用日益面臨的挑戰不謀而合，成為近年來互聯網領域的熱門話題。作為一名技術人員不難理解在云計算的底層架構中，分布式存儲是不可或缺的重要組成部分。國外知名的互聯網公司如Google、Amazon、Facebook、Microsoft、Yahoo等都推出了各自的分布式存儲系統，在國內OceanBase是淘寶自主研發的一個支持海量數據的高性能分布式數據庫系統，實現了數千億條記錄、數百TB數據上的跨行跨表事務。

在分布式系統中存在著著名的“短板理論”，一個集群如果出現了負載不均衡問題，那么負載***的機器往往將成為影響系統整體表現的瓶頸和短板。為了避免這種情況的發生，需要動態負載均衡機制，以達到實時的***化資源利用率，從而提升系統整體的吞吐。

本文將結合OceanBase的實際應用和大家分享一個去年淘寶雙十一前期的準備工作中遇到負載均衡相關案例，拋磚引玉，期望對大家的工作有所啟發。

OceanBase架構介紹

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

圖1 OceanBase 架構圖

Tablet：分片數據，最基本的存儲單元，一般會存儲多份，一個Table由多個tablet構成;

RootServer：負責集群機器的管理、Tablet定位、數據負載均衡、Schema等元數據管理等。

UpdateServer：負責存儲動態更新數據，存儲介質為內存和SSD，對外提供寫服務;

ChunkServer：負責存儲靜態Tablet數據，存儲介質為普通磁盤或者SSD。

MergeServer：負責對查詢中涉及多個Tablet數據進行合并，對外提供讀服務;

在一個集群中，Tablet的多個副本分別存儲在不同的ChunkServer，每個ChunkServer負責一部分Tablet分片數據，MergeServer和ChunkServer一般會一起部署。#p#

雙十一前期準備

對于淘寶的大部分應用而言，“雙十一”就是一年一度的一次線上壓測。伴隨流量不斷刷新著歷史新高，對每個系統的可擴展性提出了很大的挑戰。為了迎戰雙十一各產品線對有可能成為瓶頸部分的流量進行預估和擴容成為刻不容緩的任務。在本文要分享的案例中，應用方根據歷史數據預估讀請求的訪問峰值為7w QPS，約為平時的5-6倍，合計每天支持56億次的讀請求。當時OceanBase集群部署規模是36臺服務器，存儲總數據量為200億行記錄，每天支持24億次的讀請求。

當前集群的讀取性能遠不能滿足需求，我們首先進行了一次擴容，上線了10臺Chunkserver/Mergeserver服務器。由于OceanBase本身具有比較強的可擴展性，為集群加機器是一件非常簡單的操作。中心節點Rootserver在新機器注冊上線后，會啟動Rebalance功能以Tablet為單位對靜態數據進行數據遷移，見下圖的示意，最終達到所有ChunkServer上數據分片的均衡分布。

表 1. 某Table的Tablet列表

圖2.1 Tablet在三臺ChunkServer上的分布

圖2.2加入一臺機器Tablet遷移后的分布

擴容完成后引入線上流量回放機制進行壓力測試，以驗證當前集群的性能是否可以滿足應用的雙十一需求。我們使用了10臺服務器，共2000-4000個線程并發回放線上讀流量對集群進行壓測，很快發現集群整體的QPS在達到4萬左右后，壓測客戶端出現大量超時現象，平均響應延遲已經超過閾值100ms，即使不斷調整壓力，系統的整體QPS也沒有任何增大。此時觀察整個集群機器的負載狀態發現只有極個別服務器的負載超高，是其他機器的4倍左右，其他機器基本處于空閑狀態，CPU、網絡、磁盤IO都凸現了嚴重的不均衡問題。

負載不均衡導致了整體的吞吐取決于負載***的那臺Server，這正是前文提到的典型 “短板理論”問題。#p#

負載不均問題跟蹤

客戶端連接到OceanBase之后一次讀請求的讀流程如下圖所示：

圖3 客戶端到OceanBase的讀流程圖

Client 從RootServer獲取到MergeServer 列表;

Client將請求發送到某一臺MergeServer;

MergeServer從RootServer獲取請求對應的ChunkServer位置信息;

MergeServer將請求按照Tablet拆分成多個子請求發送到對應的ChunkServer;

ChunkServer向UpdateServer請求***的動態數據，與靜態數據進行合并;

MergeServer合并所有子請求的數據，返回給Client;

OceanBase的讀請求流程看起來如此復雜，實際上第1步和第3步中Client與RootServer以及MergeServer與RootServer的兩次交互會利用緩存機制來避免，即提高了效率，同時也極大降低了RootServer的負載。

分析以上的流程可知，在第2步客戶端選擇MergeServer時如果調度不均衡會導致某臺MergeServer機器過載;在第4步MergeServer把子請求發送到數據所在的ChunkServer時，由于每個tablet會有多個副本，選擇副本的策略如果不均衡也會造成ChunkServer機器過載。由于集群部署會在同一臺機器會同時啟動ChunkServer和MergeServer，無法簡單區分過載的模塊。通過查看OceanBase內部各模塊的提供的監控信息比如QPS、Cache命中率、磁盤IO數量等，發現負載不均問題是由第二個調度問題引發，即MergeServer對ChunkServer的訪問出現了不均衡導致了部分ChunkServer的過載。

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

數據不均衡： ChunkServer上數據大小的分布是不均衡的，比如某些節點因為存儲Tablet分片數據量多少的差異性而造成的不均衡;

流量不均衡：數據即使是基本均衡的情況下，仍然會因為某些節點存在數據熱點等原因而造成流量是不均衡的。

通過對RootServer管理的所有tablet數據分片所在位置信息Metadata進行統計，我們發現各個ChunkServer上的tablet數據量差異不大，這同時也說明擴容加入新的Server之后，集群的Rebalance是有效的(后來我們在其他應用的集群也發現了存在數據不均衡問題，本文暫不解釋)。

盡管排除了數據不均衡問題，流量不均衡又存在如下的幾種可能性：

存在訪問熱點：比如熱銷的商品，這些熱點數據會導致ChunkServer成為訪問熱點，造成了負載不均;

請求差異性較大：系統負載和處理請求所耗費的CPU\Memory\磁盤IO資源成正比，而資源的耗費一般又和處理的數據量是成正比的，即可能是因為存在某些大用戶而導致沒有數據訪問熱點的情況下，負載仍然是不均衡的。

經過如上的分析至少已經確定ChunkServer流量不均衡問題和步驟4緊密相關的，而目前所采用的tablet副本選擇的策略是隨機法。一般而言隨機化的負載均衡策略簡單、高效、無狀態，結合業務場景的特點進行分析，熱點數據所占的比例并不會太高，把ChunkServer上的Tablet按照訪問次數進行統計也發現并沒有超乎想象的“大熱點”，基本服從正太分布。

可見熱點Tablet雖訪問頻率稍高對負載的貢獻率相對較大，但是熱點tablet的占比很低，相反所有非熱點tablet對負載的貢獻率總和還是很高的，這種情況就好比“長尾效應”。#p#

負載均衡算法設計

如果把熱點ChunkServer上非熱點Tablet的訪問調度到其他Server，是可以緩解流量不均問題的，因此我們設計了新的負載均衡算法為：以實時統計的ChunkServer上所有tablet的訪問次數為Ticket，每次對Tablet的讀請求會選擇副本中得票率***的ChunkServer。

同時考慮到流量不均衡的第二個原因是請求的差異較大問題，ChunkServer對外提供的接口分為Get和Scan兩種，Scan是掃描一個范圍的所有行數據，Get是獲取指定一行數據，因此兩種訪問方式的次數需要劃分賦予不同的權重(α,β)參與最終Ticket的運算：

除此之外，簡單的區分兩種訪問模式還是遠遠不夠的，不同的Scan占用的資源也是存在較大差異的，引入平均響應時間(avg_time)這個重要因素也是十分必要的：

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

采用新的算法后，很好的緩解了負載不均衡的問題，整體負載提升了1倍，整體QPS吞吐提升到了8w。

小結

負載均衡問題是老生常談的問題，解決不好就會出現“短板效應”，更甚至引發分布式系統中的連鎖反應即“雪崩”，從而演化成系統的災難。負載均衡的算法也層出不窮，有的出于成本***，有的是為了最小延遲，有的則是***化系統吞吐，目的不同算法自然各異，不存在包治百病的良方，并不是越復雜的算法越有效，要綜合考慮算法所需數據獲取的Overhead，更多的是遵循“簡單實用”的法則，根據業務場景進行分析和嘗試。

正是這種靈活性的策略，對我們的系統設計提出了新的需求，要有一定的機制來監控和驗證問題：比如可以實時獲取系統運行的各種內部狀態和數據，允許選擇不同負載均衡算法進行試驗等。