一、背景

表格存儲(chǔ)(原名OTS)是一款阿里自研的NoSQL多租戶分布式數(shù)據(jù)庫，本文主要會(huì)分享在表格存儲(chǔ)中，負(fù)載均衡系統(tǒng)如何解決熱點(diǎn)問題。

1、表格存儲(chǔ)架構(gòu)

下圖是表格存儲(chǔ)系統(tǒng)最基本的一個(gè)架構(gòu)圖：

實(shí)際上，表格存儲(chǔ)還有很多其他的模塊，這里我們主要看下和本文內(nèi)容相關(guān)的部分，并且也是最核心的一部分。

從下往上看，表格存儲(chǔ)是基于飛天內(nèi)核的產(chǎn)品，飛天內(nèi)核主要提供了分布式共享存儲(chǔ)、分布式鎖服務(wù)、通信組件等基礎(chǔ)功能。

然后上面是表格存儲(chǔ)的引擎部分，主要由worker和master組成，一個(gè)集群中有少量的master和大量的worker，master負(fù)責(zé)管理worker的狀態(tài)，并將partition調(diào)度到各個(gè)worker上提供對外的服務(wù)。

再上層是前端組件，提供統(tǒng)一的http服務(wù)，并把這些請求轉(zhuǎn)發(fā)到worker上。

2、負(fù)載均衡相關(guān)的背景

在表格存儲(chǔ)系統(tǒng)中，我們會(huì)對用戶數(shù)據(jù)按分片鍵進(jìn)行切分，切分之后的一個(gè)分片，我們叫做partition，它是表格存儲(chǔ)系統(tǒng)里面，調(diào)度的基本單元，所有調(diào)度都是基于partition的。

partition可以做如下操作：

• move：把partition從一臺(tái)機(jī)器遷移到另外一臺(tái)機(jī)器上進(jìn)行服務(wù)。
• split：把一個(gè)partition分裂成兩個(gè)partition。
• merge：把兩個(gè)partition合并成一個(gè)partition。
• group：group是隔離partition的主要手段，舉個(gè)例子：它一般是先將一批worker加入到指定group中，然后將instance、table或者partition也加入到該group，完成這些操作后，系統(tǒng)會(huì)將屬于指定group的instance、table的所有partition和顯示指定group的partition都固定調(diào)度在該group的worker上，達(dá)到隔離的目的。說簡單一點(diǎn)就是我給一些用戶分配指定的機(jī)器，這些機(jī)器專門給這些用戶服務(wù)。

上述的所有對partition的操作，包括move、split、merge、group，都是秒級別的。

3、熱點(diǎn)問題

在NoSQL多租戶系統(tǒng)中經(jīng)常遇到的熱點(diǎn)問題，主要分為以下兩類：

1)用戶訪問熱點(diǎn)

用戶訪問熱點(diǎn)又分為合理的突發(fā)式訪問熱點(diǎn)，以及不合理的突發(fā)式訪問熱點(diǎn)：

• 合理的突發(fā)式訪問指的是，用戶的表設(shè)計(jì)合理，只是業(yè)務(wù)量突然上漲導(dǎo)致的，比如說大促。
• 不合理的訪問熱點(diǎn)指的是，用戶的表設(shè)計(jì)不合理，在這個(gè)基礎(chǔ)上，業(yè)務(wù)量上漲導(dǎo)致的熱點(diǎn)。

2)機(jī)器熱點(diǎn)

機(jī)器的熱點(diǎn)問題指的是，該機(jī)器的cpu，網(wǎng)絡(luò)流量由于某些原因突然變高，該機(jī)器資源成為瓶頸，導(dǎo)致的熱點(diǎn)。

通常，熱點(diǎn)問題很難處理，主要有如下原因：

• 定位難：系統(tǒng)中的信息統(tǒng)計(jì)不夠全，導(dǎo)致了出現(xiàn)熱點(diǎn)問題，很難定位，只能靠猜。
• 解決難：即使定位了問題，有可能還很難處理，主要原因是系統(tǒng)中處理熱點(diǎn)的手段不足。
• 人工處理慢：即使能定位，也能解決，但是處理時(shí)間太長，嚴(yán)重影響服務(wù)的可用性。

在表格存儲(chǔ)系統(tǒng)中，對上述幾個(gè)難點(diǎn)，我們都有對應(yīng)的手段來解決。針對信息不全，定位難的問題，我們系統(tǒng)中有詳細(xì)的partition級別統(tǒng)計(jì)信息，并且秒級別的partition move、split、merge、group功能也能很好地處理問題。

我們開發(fā)了一套負(fù)載均衡系統(tǒng)，它能收集信息、分析信息、解決問題，做到熱點(diǎn)問題快速自動(dòng)化解決，不需要人工參與。

二、負(fù)載均衡系統(tǒng)

接下來我們來看看表格存儲(chǔ)中的負(fù)載均衡系統(tǒng)是如何自動(dòng)化解決問題的。首先介紹負(fù)載均衡系統(tǒng)的架構(gòu)，然后分模塊來詳細(xì)闡述各個(gè)模塊的功能。

1、負(fù)載均衡架構(gòu)

下圖是負(fù)載均衡系統(tǒng)的架構(gòu)圖：

它主要包括LBAgent和LBMaster兩個(gè)角色，其中LBAgent和worker進(jìn)程部署在同一臺(tái)機(jī)器上，它負(fù)責(zé)收集這臺(tái)機(jī)器上的所有信息指標(biāo)，包括worker進(jìn)程和其他相關(guān)的進(jìn)程。收集之后，在內(nèi)存中維護(hù)近期的數(shù)據(jù)，同時(shí)把數(shù)據(jù)異步地寫到外部存儲(chǔ)系統(tǒng)中，在圖中我們叫做MetricStore。

然后往上一層的模塊是OpsServer，它是很薄的一層封裝，主要提供了所有命令的http服務(wù)。

再往上是LBMaster。LBMaster中的collector模塊通過OpsServer實(shí)時(shí)收集LBAgent的數(shù)據(jù)，并把近期的數(shù)據(jù)維護(hù)在內(nèi)存中，這個(gè)模塊我們叫做MetricsTable，它主要提供各種數(shù)據(jù)聚合和top排序的功能。

在線分析模塊(OnlineAnalyzer)會(huì)實(shí)時(shí)分析MetricsTable中的近期數(shù)據(jù)，來檢測是否有熱點(diǎn)等異常的問題。如果有，則對這些信息進(jìn)行進(jìn)一步分析，來產(chǎn)生相應(yīng)的解決action，并把這些action交給執(zhí)行模塊(Executor)。執(zhí)行模塊通過OpsServer把相應(yīng)的action發(fā)送給worker或者master，由worker或者master執(zhí)行action，最終解決熱點(diǎn)問題。

同時(shí)，LBMaster還有一個(gè)離線分析模塊(OfflineAnalyzer)，這個(gè)模塊主要從外部存儲(chǔ)系統(tǒng)MetricStore中讀取信息，并對這些信息進(jìn)行分析，以檢測系統(tǒng)中是否有潛在問題，如果有，則對這些問題產(chǎn)生相對應(yīng)的action，同樣通過OpsServer交給worker或者master來執(zhí)行，最終解決潛在的問題，做到防患于未然。

無論是在線分析模塊還是離線分析模塊，分析出的結(jié)果和action都會(huì)寫入到一個(gè)外部存儲(chǔ)系統(tǒng)中，這里叫做ResultDataStore，主要為了人工或者系統(tǒng)對這些action做進(jìn)一步的分析。

LBMaster還提供一個(gè)白屏化的管控平臺(tái)，這個(gè)管控平臺(tái)能夠?qū)崟r(shí)查詢LBMaster中的各種數(shù)據(jù)，同時(shí)也可以通過它來發(fā)送人工運(yùn)維命令。

2、信息收集模塊

信息收集模塊有兩個(gè)重點(diǎn)：

• 信息盡可能地全。
• 不能影響主路徑的性能。

在表格存儲(chǔ)系統(tǒng)中，任何一個(gè)模塊處理請求時(shí)，都會(huì)順便收集該模塊的相關(guān)信息，這些信息會(huì)隨著請求一起流動(dòng)。如下圖：

在圖中，經(jīng)過rpc模塊，就會(huì)收集rpc模塊中的統(tǒng)計(jì)信息;經(jīng)過m1、m2模塊時(shí)，也會(huì)一起收集m1、m2模塊的信息;最終在返回用戶前，異步地把信息推送到一個(gè)后臺(tái)計(jì)算模塊，這個(gè)模塊會(huì)在后臺(tái)用很少量的資源來匯總這些信息，并定期把信息推送給LBAgent。

由于這個(gè)后臺(tái)計(jì)算模塊，不在主路徑上執(zhí)行，是異步執(zhí)行的，并且只占用少量的資源，可能只有一個(gè)核的cpu，所以對主路徑的性能影響極小。

通過這種方式，我們既保證了能收集到各個(gè)模塊的信息，同時(shí)盡可能地減少了對主路徑性能的影響。

3、LBAgent模塊

LBAgent模塊主要有三個(gè)功能：

• 收集單機(jī)上的所有信息。
• 對這些信息進(jìn)行預(yù)聚合。
• 異步地持久化所有信息。

如圖所示：

LBAgent端的接收信息模塊不僅會(huì)收到worker進(jìn)程的信息，還會(huì)收到系統(tǒng)中其他相關(guān)進(jìn)程的信息。收到信息之后，LBAgent在內(nèi)存中維護(hù)近期收集的信息，同時(shí)異步地將信息持久化到外部存儲(chǔ)系統(tǒng)(MetricStore)中，以保存更長時(shí)間。LBMaster通過接口周期性地獲取LBAgent內(nèi)存中維護(hù)的信息。

4、LBMaster模塊

LBMater模塊是負(fù)載均衡系統(tǒng)最核心的模塊。它的主要功能是：

• 收集集群所有信息。
• 多維度信息的top查詢，包括但不限于錯(cuò)誤率、延時(shí)、qps等信息。
• 分析信息、產(chǎn)生action、執(zhí)⾏action。
• 自我反饋策略的有效性。

我們結(jié)合下圖來看：

collector負(fù)責(zé)收集信息，MetricsTable負(fù)責(zé)多維度信息的top查詢，OnlineAnalyzer和OfflineAnalyzer模塊分別分析在線實(shí)時(shí)信息和離線信息，ActionExecutor模塊負(fù)責(zé)執(zhí)行分析模塊產(chǎn)出的action。

在action執(zhí)行完成之后，ActionEvaluation模塊會(huì)比較action執(zhí)行前后的信息變化來判斷這個(gè)action的效果，通過這種方式來反饋該action是否真正解決了問題。

此外，LBMaster還有一個(gè)配置相關(guān)的模塊，各個(gè)模塊都有靈活的配置，配置存儲(chǔ)在外部存儲(chǔ)系統(tǒng)中，配置模塊會(huì)讀取這些信息，然后同步給所有模塊。所有模塊的配置都支持實(shí)時(shí)地動(dòng)態(tài)更新。

總結(jié)下，LBMaster的有如下特點(diǎn)：

• 冷熱數(shù)據(jù)存儲(chǔ)分離：其中熱數(shù)據(jù)存儲(chǔ)在內(nèi)存中，保留最近小時(shí)級別的數(shù)據(jù)，冷數(shù)據(jù)存儲(chǔ)在外部存儲(chǔ)系統(tǒng)中，可以按需保留數(shù)月甚至幾年。
• 離線在線模塊分離：從架構(gòu)圖中可以看到，離線模塊和在線模塊的路徑不會(huì)相互影響。
• 配置靈活、動(dòng)態(tài)加載：LBMaster支持靈活的配置，并且能夠不升級動(dòng)態(tài)加載。
• 白屏化操作及信息展示：LBMaster中的所有信息都支持白屏化的展示，并且還可以白屏化發(fā)送運(yùn)維命令給LBMaster，LBMaster會(huì)執(zhí)行這些運(yùn)維命令。
• 高可用：由于LBMaster在整個(gè)負(fù)載均衡系統(tǒng)中起著核心的作用，所以它還要做到高可用。

接下來，我們從在線和離線兩方面來看下負(fù)載均衡處理問題的情況。

5、在線分析路徑

首先看在線分析路徑。在線分析主要是分析短期信息，發(fā)現(xiàn)問題，最終解決問題，它主要有如下特點(diǎn)：

• 數(shù)據(jù)實(shí)時(shí)性要求極高，分析頻率高，秒級別發(fā)現(xiàn)并處理問題。
• 數(shù)據(jù)量小、全部維護(hù)在內(nèi)存表中。
• 主路徑不依賴任何外部系統(tǒng)。

我們從架構(gòu)圖來看在線分析路徑，可以發(fā)現(xiàn)：

• 整個(gè)數(shù)據(jù)流路徑，從worker到LBAgent再到LBMaster，以及控制流路徑從LBMaster到worker、master，除了分析的結(jié)果會(huì)異步地寫外部存儲(chǔ)系統(tǒng)外，不涉及任何外部系統(tǒng)。
• 并且分析結(jié)果寫外部存儲(chǔ)系統(tǒng)的失敗也不影響主路徑的執(zhí)行，它是一個(gè)異步的操作。所有這些設(shè)計(jì)都是為了滿足實(shí)時(shí)性的要求。

在表格存儲(chǔ)系統(tǒng)中有很多在分析的策略，下面舉兩個(gè)例子：

例1：熱點(diǎn)問題導(dǎo)致讀寫隊(duì)列滿報(bào)錯(cuò)

• 首先，負(fù)載均衡系統(tǒng)分析信息會(huì)發(fā)現(xiàn)worker1的隊(duì)列被打滿，報(bào)錯(cuò)，到達(dá)了單partition的服務(wù)瓶頸。
• 然后進(jìn)一步分析發(fā)現(xiàn)可以做split來解決這個(gè)問題，因此負(fù)載均衡系統(tǒng)發(fā)出split partition1的action，action通過worker和master執(zhí)行后，partition1被切分為partition11和partition12，并調(diào)度到兩臺(tái)機(jī)器上服務(wù)。通過這種方式解決了熱點(diǎn)問題。

例2：機(jī)器資源滿導(dǎo)致的問題

負(fù)載均衡系統(tǒng)分析信息發(fā)現(xiàn)worker1的資源被打滿，然后開始分析原因，發(fā)現(xiàn)是partition2導(dǎo)致的，進(jìn)一步分析發(fā)現(xiàn)partition2的訪問模式有問題。

比如說是單partitionkey的訪問，或者順序?qū)懺L問，這種訪問模式，split不能解決問題，所以負(fù)載均衡系統(tǒng)發(fā)出隔離partition2的action，action執(zhí)行后，partition2被單獨(dú)隔離到一臺(tái)機(jī)器上服務(wù)。

此時(shí)，partition2不影響其他任何用戶，并且也獨(dú)享整體機(jī)器的資源，系統(tǒng)給它提供了強(qiáng)服務(wù)能力。

6、離線分析路徑

與在線分析路徑恰好相反的是，離線分析主要是分析長期信息，發(fā)現(xiàn)潛在的問題，并最終消除這些潛在問題，做到防患于未然。和在線路徑相比，它的特點(diǎn)是：

• 數(shù)據(jù)實(shí)時(shí)性要求低，分析頻率低，小時(shí)級別發(fā)現(xiàn)并處理問題。
• 由于數(shù)據(jù)量大，信息維護(hù)在外部存儲(chǔ)系統(tǒng)中。
• 計(jì)算量大，所以分析的時(shí)候可以依賴外部分析系統(tǒng)。

從架構(gòu)圖來看，離線分析路徑的數(shù)據(jù)來源于外部存儲(chǔ)系統(tǒng)，并且由于分析的數(shù)據(jù)量很大，它會(huì)先借助外部分析系統(tǒng)做初步的分析，然后把分析結(jié)果寫入到一張結(jié)果表中。

LBMaster的離線分析模塊，對結(jié)果表中的信息做進(jìn)一步的分析，然后發(fā)現(xiàn)問題，產(chǎn)生action。借助外部分析系統(tǒng)，大大減少了LBMaster的資源消耗，也大大增加了分析的能力。

接下來簡單介紹兩個(gè)離線分析策略的例子：

首先是auto merge，在NoSQL系統(tǒng)中，有部分的partition剛開始訪問量很大，所以被切分成很多partition，隨后這些partition的訪問量可能會(huì)很低，甚至幾乎沒有，那么我們就可以將這些partition進(jìn)行merge，來節(jié)約系統(tǒng)資源。

但是，不能通過短期統(tǒng)計(jì)數(shù)據(jù)判斷一個(gè)partition訪問量低就對它做merge，因?yàn)橛行﹑artition的訪問模式是周期性的，所以要通過長期統(tǒng)計(jì)數(shù)據(jù)來判斷一個(gè)partition能否做merge。

另外一個(gè)例子是，我們可以通過對長期數(shù)據(jù)的分析來預(yù)測某些用戶的訪問峰值，提前做好資源的調(diào)整。

7、效果展示

接下來，展示一些負(fù)載均衡系統(tǒng)上線后的效果。選取的都是有明顯熱點(diǎn)的業(yè)務(wù)，所以效果都非常明顯。

如下圖所示，負(fù)載均衡系統(tǒng)上線后，讀操作的錯(cuò)誤率和延時(shí)明顯降低，吞吐量明顯提高：

如下圖所示，負(fù)載均衡系統(tǒng)上線后，寫操作的錯(cuò)誤率明顯降低，并且在發(fā)現(xiàn)熱點(diǎn)的時(shí)候，即錯(cuò)誤率突然升高時(shí)，能立刻處理掉：

三、總結(jié)

從我自己做負(fù)載均衡系統(tǒng)的實(shí)踐中總結(jié)了幾點(diǎn)經(jīng)驗(yàn)：

每個(gè)模塊的信息統(tǒng)計(jì)是根本

如果沒有信息統(tǒng)計(jì)，或者信息統(tǒng)計(jì)不全，都會(huì)導(dǎo)致問題定位不出來或是定位錯(cuò)誤，整個(gè)負(fù)載均衡系統(tǒng)都無從談起。并且這部分的工作量絕對不小，不是很簡單就能做到信息全，并且也幾乎不影響性能的。

把人工處理自動(dòng)化是高效的策略

很多人剛開始都會(huì)覺得負(fù)載均衡要用到非常多的機(jī)器學(xué)習(xí)算法，這個(gè)可能是對的。

但是對于前期來說，我們把人工處理方式來進(jìn)行自動(dòng)化處理，可能就能解決90%以上的線上問題，并不需要高大上的機(jī)器學(xué)習(xí)算法。在經(jīng)過這個(gè)階段之后，一些難點(diǎn)問題，或者預(yù)測性的策略方面，再去考慮機(jī)器學(xué)習(xí)的東西。

策略配置豐富，控制靈活

每個(gè)策略都要有一些閾值或者條件，這些條件都不能寫死在系統(tǒng)中，都要由配置的方式來傳入，因?yàn)榫€上的情況差異非常大，只有這樣才能有機(jī)會(huì)針對不同的業(yè)務(wù)、不同的場景進(jìn)行配置定制。

系統(tǒng)快速迭代，支持差異化配置

負(fù)載均衡系統(tǒng)是一個(gè)要求快速迭代的系統(tǒng)，比如今天發(fā)現(xiàn)線上一類問題，就需要盡快寫出策略上線，來解決線上的問題。

再者，由于每個(gè)業(yè)務(wù)的特點(diǎn)不同，訪問模式的差異非常大，對可用性的要求也會(huì)有很大區(qū)別。

所以這里就需要非常靈活的配置，對于不同的業(yè)務(wù)，也許是同一個(gè)策略都會(huì)需要不同的配置才能達(dá)對這個(gè)業(yè)務(wù)而言的理想效果。

Q & A

Q1：請問表的統(tǒng)計(jì)信息都統(tǒng)計(jì)些什么?既然有工作者隊(duì)列，為什么還需要擔(dān)心處理熱點(diǎn)問題?

A1：在系統(tǒng)中，有部分隊(duì)列不是獨(dú)享的，可能是整個(gè)進(jìn)程所有partition都共享的，如果一個(gè)partition出現(xiàn)了熱點(diǎn)訪問，占用了所有的資源，可能會(huì)導(dǎo)致這臺(tái)機(jī)器上所有partition的訪問都受到影響。

Q2：那么不采用hash環(huán)的分布式策略，比起明確分區(qū)鍵值有什么壞處?為什么要選用后者?

A2：hash分片主要的問題是，一旦確定之后動(dòng)態(tài)調(diào)整比較困難，基于分片鍵的方式，能比較容易做到動(dòng)態(tài)調(diào)整，比如split。而hash分片，如果剛開始分片有問題，后續(xù)再調(diào)整就比較困難。

Q3：我們這邊用的是RabbitMQ，沒有想過要另找一套的思路。當(dāng)時(shí)自己創(chuàng)建這個(gè)的時(shí)候有沒有參考別的解決方案?然后如何抉擇的?

A3：你這里的隊(duì)列服務(wù)可能和我說的不太一樣。如果你們是基于隊(duì)列服務(wù)做得系統(tǒng)，那么隊(duì)列服務(wù)相關(guān)的負(fù)載均衡你們基本上就無能為力，要看隊(duì)列服務(wù)這個(gè)產(chǎn)品來做，如果你們自己的系統(tǒng)本身也有熱點(diǎn)問題，那么本次分享應(yīng)該對你有所幫助。

直播回放

https://m.qlchat.com/topic/details?topicId=2000003638109687

[[259174]]

陳新進(jìn) 阿里云技術(shù)專家

參與阿里云自研NoSQL存儲(chǔ)系統(tǒng)（表格存儲(chǔ)）六年以上研發(fā)；

主要負(fù)責(zé)產(chǎn)品的master模塊和負(fù)載均衡系統(tǒng)，在系統(tǒng)穩(wěn)定性和可用性方面有一定的積累。