淘寶在“雙十一”背后，OceanBase分布式系統(tǒng)負(fù)載均衡的經(jīng)驗分享。

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

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

本文將結(jié)合OceanBase的實際應(yīng)用和大家分享一個去年淘寶雙十一前期的準(zhǔn)備工作中遇到負(fù)載均衡相關(guān)案例，拋磚引玉，期望對大家的工作有所啟發(fā)。

OceanBase架構(gòu)介紹

OceanBase是一個具有自治功能的分布式存儲系統(tǒng)，由中心節(jié)點RootServer、靜態(tài)數(shù)據(jù)節(jié)點ChunkServer、動態(tài)數(shù)據(jù)節(jié)點UpdateServer以及數(shù)據(jù)合并節(jié)點MergeServer四個Server構(gòu)成，如圖1所示。

圖1 OceanBase 架構(gòu)圖

Tablet：分片數(shù)據(jù)，最基本的存儲單元，一般會存儲多份，一個Table由多個tablet構(gòu)成;

RootServer：負(fù)責(zé)集群機(jī)器的管理、Tablet定位、數(shù)據(jù)負(fù)載均衡、Schema等元數(shù)據(jù)管理等。

UpdateServer：負(fù)責(zé)存儲動態(tài)更新數(shù)據(jù)，存儲介質(zhì)為內(nèi)存和SSD，對外提供寫服務(wù);

ChunkServer：負(fù)責(zé)存儲靜態(tài)Tablet數(shù)據(jù)，存儲介質(zhì)為普通磁盤或者SSD。

MergeServer：負(fù)責(zé)對查詢中涉及多個Tablet數(shù)據(jù)進(jìn)行合并，對外提供讀服務(wù);

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

雙十一前期準(zhǔn)備

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

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

表 1. 某Table的Tablet列表

圖2.1 Tablet在三臺ChunkServer上的分布

圖2.2加入一臺機(jī)器Tablet遷移后的分布

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

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

負(fù)載不均問題跟蹤

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

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

Client 從RootServer獲取到MergeServer 列表;

Client將請求發(fā)送到某一臺MergeServer;

MergeServer從RootServer獲取請求對應(yīng)的ChunkServer位置信息;

MergeServer將請求按照Tablet拆分成多個子請求發(fā)送到對應(yīng)的ChunkServer;

ChunkServer向UpdateServer請求***的動態(tài)數(shù)據(jù)，與靜態(tài)數(shù)據(jù)進(jìn)行合并;

MergeServer合并所有子請求的數(shù)據(jù)，返回給Client;

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

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

ChunkServer是存儲靜態(tài)Tablet分片數(shù)據(jù)的節(jié)點，分析其負(fù)載不均的原因包含如下可能：

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

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

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

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

存在訪問熱點：比如熱銷的商品，這些熱點數(shù)據(jù)會導(dǎo)致ChunkServer成為訪問熱點，造成了負(fù)載不均;

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

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

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

負(fù)載均衡算法設(shè)計

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

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

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

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

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

小結(jié)

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

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