編者按：在CSDN雲端計算頻道日前所做的文章《響應高達6秒 使用者揭露Heroku私自修改路由造成高支出》中，網友們認為這是“因隨機排程+Rails的單執行緒處理導致延遲增加的負載均衡失敗的案例”。但在負載均衡測試時就能發現問題並妥善解決的成功經驗有沒有？在隨後的微博中，支付寶的@Leverly評論：“去年雙11前的壓測OB就發現了存在嚴重的隨機訪問導致負載不均問題，還好通過加權演算法很好的解決了。” 引發了我們的關注，於是有了本文。重點是淘寶在“雙十一”背後，OceanBase分散式系統負載均衡的經驗分享。

以下為正文：

雲端計算所具備的低成本、高效能、高可用性、高可擴充套件性等特點與網際網路應用日益面臨的挑戰不謀而合，成為近年來網際網路領域的熱門話題。作為一名技術人員不難理解在雲端計算的底層架構中，分散式儲存是不可或缺的重要組成部分。國外知名的網際網路公司如Google、Amazon、Facebook、Microsoft、Yahoo

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

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

OceanBase架構介紹

OceanBase是一個具有自治功能

圖1 OceanBase 架構圖

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

在一個叢集中，Tablet的多個副本分別儲存在不同的ChunkServer，每個ChunkServer負責一部分Tablet分片資料，MergeServer和ChunkServer一般會一起部署。

雙十一前期準備

對於淘寶的大部分應用而言，“雙十一”就是一年一度的一次線上壓測。伴隨流量不斷重新整理著歷史新高，對每個系統的可擴充套件性提出了很大的挑戰。為了迎戰雙十一各產品線對有可能成為瓶頸部分的流量進行預估和擴容成為刻不容緩的任務。在本文要分享的案例中，應用方根據歷史資料預估讀請求的訪問峰值為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，這正是前文提到的典型 “短板理論”問題。

負載不均問題跟蹤

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

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

1. Client 從RootServer獲取到MergeServer 列表；
2. Client將請求傳送到某一臺MergeServer；
3. MergeServer從RootServer獲取請求對應的ChunkServer位置資訊；
4. MergeServer將請求按照Tablet拆分成多個子請求傳送到對應的ChunkServer；
5. ChunkServer向UpdateServer請求最新的動態資料，與靜態資料進行合併；
6. 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分片資料的節點，分析其負載不均的原因包含如下可能：

1. 資料不均衡： ChunkServer上資料大小的分佈是不均衡的，比如某些節點因為儲存Tablet分片資料量多少的差異性而造成的不均衡；
2. 流量不均衡：資料即使是基本均衡的情況下，仍然會因為某些節點存在資料熱點等原因而造成流量是不均衡的。

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

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

1. 存在訪問熱點：比如熱銷的商品，這些熱點資料會導致ChunkServer成為訪問熱點，造成了負載不均；
2. 請求差異性較大：系統負載和處理請求所耗費的CPU\Memory\磁碟IO資源成正比，而資源的耗費一般又和處理的資料量是成正比的，即可能是因為存在某些大使用者而導致沒有資料訪問熱點的情況下，負載仍然是不均衡的。

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

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

負載均衡演算法設計

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

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

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

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

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

小結

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

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

Update1：看到樓下網友專業方面的提問，@Leverly 已經進行了回覆。有更多交流，不妨直接討論。共享：）！

3月2日Update2：圖2.2已更換（原圖右邊顯示不完全，應為“A，E，G，H，I"）。

參考文獻

4.http://www.cs.usask.ca/faculty/eager/loadsharing.pdf

歡迎 @CSDN雲端計算微博參與討論，瞭解更多雲資訊。