下文給大家?guī)韺ceanBase分布式系統負載均衡案例介紹與分析，希望能夠給大家在實際運用中帶來一定的幫助，負載均衡涉及的東西比較多，理論也不多，網上有很多書籍，今天我們就用創(chuàng)新互聯建站在行業(yè)內累計的經驗來做一個解答。
摘要：Heroku的問題讓我們意識到，在負載均衡測試時發(fā)現問題并妥善解決的成功經驗有沒有？于是，挖掘出“淘寶在雙十一壓測OB時發(fā)現存在嚴重的隨機訪問導致負載不均問題，并通過加權算法妥善解決”的成功案例，也就是本文。
在CSDN云計算頻道日前所做的文章《響應高達6秒 用戶揭露Heroku私自修改路由造成高支出》中，網友們認為這是“因隨機調度+Rails的單線程處理導致延遲增加的負載均衡失敗的案例”。但在負載均衡測試時就能發(fā)現問題并妥善解決的成功經驗有沒有？在隨后的微博中，支付寶的@Leverly評論：“去年雙11前的壓測OB就發(fā)現了存在嚴重的隨機訪問導致負載不均問題，還好通過加權算法很好的解決了?！?引發(fā)了我們的關注，于是有了本文。重點是淘寶在“雙十一”背后，OceanBase分布式系統負載均衡的經驗分享。
云計算所具備的低成本、高性能、高可用性、高可擴展性等特點與互聯網應用日益面臨的挑戰(zhàn)不謀而合，成為近年來互聯網領域的熱門話題。作為一名技術人員不難理解在云計算的底層架構中，分布式存儲是不可或缺的重要組成部分。國外知名的互聯網公司如Google、Amazon、Facebook、Microsoft、Yahoo等都推出了各自的分布式存儲系統，在國內OceanBase是淘寶自主研發(fā)的一個支持海量數據的高性能分布式數據庫系統，實現了數千億條記錄、數百TB數據上的跨行跨表事務[1]。
在分布式系統中存在著著名的“短板理論”[2]，一個集群如果出現了負載不均衡問題，那么負載大的機器往往將成為影響系統整體表現的瓶頸和短板。為了避免這種情況的發(fā)生，需要動態(tài)負載均衡機制，以達到實時的大化資源利用率，從而提升系統整體的吞吐。在此我向大家推薦一個架構學習交流圈。交流學習企鵝圈號：948368769 里面會分享一些資深架構師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務架構的原理，JVM性能優(yōu)化、分布式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多
本文將結合OceanBase的實際應用和大家分享一個去年淘寶雙十一前期的準備工作中遇到負載均衡相關案例，拋磚引玉，期望對大家的工作有所啟發(fā)。
OceanBase是一個具有自治功能的分布式存儲系統，由中心節(jié)點RootServer、靜態(tài)數據節(jié)點ChunkServer、動態(tài)數據節(jié)點UpdateServer以及數據合并節(jié)點MergeServer四個Server構成[1]，如圖1所示。
Tablet：分片數據，最基本的存儲單元，一般會存儲多份，一個Table由多個tablet構成；
RootServer：負責集群機器的管理、Tablet定位、數據負載均衡、Schema等元數據管理等。
UpdateServer：負責存儲動態(tài)更新數據，存儲介質為內存和SSD，對外提供寫服務；
ChunkServer：負責存儲靜態(tài)Tablet數據，存儲介質為普通磁盤或者SSD。
MergeServer：負責對查詢中涉及多個Tablet數據進行合并，對外提供讀服務；
在一個集群中，Tablet的多個副本分別存儲在不同的ChunkServer，每個ChunkServer負責一部分Tablet分片數據，MergeServer和ChunkServer一般會一起部署。
雙十一前期準備
對于淘寶的大部分應用而言，“雙十一”就是一年一度的一次線上壓測。伴隨流量不斷刷新著歷史新高，對每個系統的可擴展性提出了很大的挑戰(zhàn)。為了迎戰(zhàn)雙十一各產品線對有可能成為瓶頸部分的流量進行預估和擴容成為刻不容緩的任務。在本文要分享的案例中，應用方根據歷史數據預估讀請求的訪問峰值為7w QPS，約為平時的5-6倍，合計每天支持56億次的讀請求。當時OceanBase集群部署規(guī)模是36臺云服務器，存儲總數據量為200億行記錄，每天支持24億次的讀請求。
當前集群的讀取性能遠不能滿足需求，我們首先進行了一次擴容，上線了10臺Chunkserver/Mergeserver服務器。由于OceanBase本身具有比較強的可擴展性，為集群加機器是一件非常簡單的操作。中心節(jié)點Rootserver在新機器注冊上線后，會啟動Rebalance功能以Tablet為單位對靜態(tài)數據進行數據遷移，見下圖的示意，最終達到所有ChunkServer上數據分片的均衡分布。
擴容完成后引入線上流量回放機制進行壓力測試，以驗證當前集群的性能是否可以滿足應用的雙十一需求。我們使用了10臺服務器，共2000-4000個線程并發(fā)回放線上讀流量對集群進行壓測，很快發(fā)現集群整體的QPS在達到4萬左右后，壓測客戶端出現大量超時現象，平均響應延遲已經超過閾值100ms，即使不斷調整壓力，系統的整體QPS也沒有任何增大。此時觀察整個集群機器的負載狀態(tài)發(fā)現只有極個別服務器的負載超高，是其他機器的4倍左右，其他機器基本處于空閑狀態(tài)，CPU、網絡、磁盤IO都凸現了嚴重的不均衡問題。
負載不均衡導致了整體的吞吐取決于負載最高的那臺Server，這正是前文提到的典型 “短板理論”問題。
客戶端連接到OceanBase之后一次讀請求的讀流程如下圖所示：
Client 從RootServer獲取到MergeServer 列表；
Client將請求發(fā)送到某一臺MergeServer；
MergeServer從RootServer獲取請求對應的ChunkServer位置信息；
MergeServer將請求按照Tablet拆分成多個子請求發(fā)送到對應的ChunkServer；
ChunkServer向UpdateServer請求最新的動態(tài)數據，與靜態(tài)數據進行合并；
MergeServer合并所有子請求的數據，返回給Client；
OceanBase的讀請求流程看起來如此復雜，實際上第1步和第3步中Client與RootServer以及MergeServer與RootServer的兩次交互會利用緩存機制來避免，即提高了效率，同時也極大降低了RootServer的負載。
分析以上的流程可知，在第2步客戶端選擇MergeServer時如果調度不均衡會導致某臺MergeServer機器過載；在第4步MergeServer把子請求發(fā)送到數據所在的ChunkServer時，由于每個tablet會有多個副本，選擇副本的策略如果不均衡也會造成ChunkServer機器過載。由于集群部署會在同一臺機器會同時啟動ChunkServer和MergeServer，無法簡單區(qū)分過載的模塊。通過查看OceanBase內部各模塊的提供的監(jiān)控信息比如QPS、Cache命中率、磁盤IO數量等，發(fā)現負載不均問題是由第二個調度問題引發(fā)，即MergeServer對ChunkServer的訪問出現了不均衡導致了部分ChunkServer的過載。
ChunkServer是存儲靜態(tài)Tablet分片數據的節(jié)點，分析其負載不均的原因包含如下可能：
數據不均衡： ChunkServer上數據大小的分布是不均衡的，比如某些節(jié)點因為存儲Tablet分片數據量多少的差異性而造成的不均衡；
流量不均衡：數據即使是基本均衡的情況下，仍然會因為某些節(jié)點存在數據熱點等原因而造成流量是不均衡的。
通過對RootServer管理的所有tablet數據分片所在位置信息Metadata進行統計，我們發(fā)現各個ChunkServer上的tablet數據量差異不大，這同時也說明擴容加入新的Server之后，集群的Rebalance是有效的（后來我們在其他應用的集群也發(fā)現了存在數據不均衡問題，本文暫不解釋）。
盡管排除了數據不均衡問題，流量不均衡又存在如下的幾種可能性：
存在訪問熱點：比如熱銷的商品，這些熱點數據會導致ChunkServer成為訪問熱點，造成了負載不均；
請求差異性較大：系統負載和處理請求所耗費的CPU\Memory\磁盤IO資源成正比，而資源的耗費一般又和處理的數據量是成正比的，即可能是因為存在某些大用戶而導致沒有數據訪問熱點的情況下，負載仍然是不均衡的。
經過如上的分析至少已經確定ChunkServer流量不均衡問題和步驟4緊密相關的，而目前所采用的tablet副本選擇的策略是隨機法。一般而言隨機化的負載均衡策略簡單、高效、無狀態(tài)，結合業(yè)務場景的特點進行分析，熱點數據所占的比例并不會太高，把ChunkServer上的Tablet按照訪問次數進行統計也發(fā)現并沒有超乎想象的“大熱點”，基本服從正太分布。在此我向大家推薦一個架構學習交流圈。交流學習企鵝圈號：948368769 里面會分享一些資深架構師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務架構的原理，JVM性能優(yōu)化、分布式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多
可見熱點Tablet雖訪問頻率稍高對負載的貢獻率相對較大，但是熱點tablet的占比很低，相反所有非熱點tablet對負載的貢獻率總和還是很高的，這種情況就好比“長尾效應”[3]。
如果把熱點ChunkServer上非熱點Tablet的訪問調度到其他Server，是可以緩解流量不均問題的，因此我們設計了新的負載均衡算法為：以實時統計的ChunkServer上所有tablet的訪問次數為Ticket，每次對Tablet的讀請求會選擇副本中得票率最低的ChunkServer。
同時考慮到流量不均衡的第二個原因是請求的差異較大問題，ChunkServer對外提供的接口分為Get和Scan兩種，Scan是掃描一個范圍的所有行數據，Get是獲取指定一行數據，因此兩種訪問方式的次數需要劃分賦予不同的權重(α,β)參與最終Ticket的運算：
除此之外，簡單的區(qū)分兩種訪問模式還是遠遠不夠的，不同的Scan占用的資源也是存在較大差異的，引入平均響應時間（avg_time）這個重要因素也是十分必要的：
負載均衡算法要求具有自適應性和強的實時性，一方面新的訪問要實時累積參與下次的負載均衡的調度，另一方面歷史權重數據則需要根據統計周期進行非線性的衰減（y 衰減因子），減少對實時性的影響：
采用新的算法后，很好的緩解了負載不均衡的問題，整體負載提升了1倍，整體QPS吞吐提升到了8w。
負載均衡問題是老生常談的問題，解決不好就會出現“短板效應”，更甚至引發(fā)分布式系統中的連鎖反應即“雪崩”，從而演化成系統的災難。負載均衡的算法也層出不窮，有的出于成本最優(yōu)，有的是為了最小延遲，有的則是大化系統吞吐，目的不同算法自然各異，不存在包治百病的良方，并不是越復雜的算法越有效[4]，要綜合考慮算法所需數據獲取的Overhead，更多的是遵循“簡單實用”的法則，根據業(yè)務場景進行分析和嘗試。
正是這種靈活性的策略，對我們的系統設計提出了新的需求，要有一定的機制來監(jiān)控和驗證問題：比如可以實時獲取系統運行的各種內部狀態(tài)和數據，允許選擇不同負載均衡算法進行試驗等。
看了以上關于對OceanBase分布式系統負載均衡案例介紹與分析，如果大家還有什么地方需要了解的可以在創(chuàng)新互聯建站行業(yè)資訊里查找自己感興趣的或者找我們的專業(yè)技術工程師解答的，創(chuàng)新互聯建站技術工程師在行業(yè)內擁有十幾年的經驗了。
創(chuàng)新互聯www.cdcxhl.cn，專業(yè)提供香港、美國云服務器，動態(tài)BGP最優(yōu)骨干路由自動選擇，持續(xù)穩(wěn)定高效的網絡助力業(yè)務部署。公司持有工信部辦法的idc、isp許可證， 機房獨有T級流量清洗系統配攻擊溯源，準確進行流量調度，確保服務器高可用性。佳節(jié)活動現已開啟，新人活動云服務器買多久送多久。
重慶分公司
重慶分公司
