作者 ｜ vivo 互聯(lián)網(wǎng)服務(wù)器團(tuán)隊(duì)-You Shuo

副本遷移是Kafka最高頻的操作，對(duì)于一個(gè)擁有幾十萬(wàn)個(gè)副本的集群，通過(guò)人工去完成副本遷移是一件很困難的事情。Cruise Control作為Kafka的運(yùn)維工具，它包含了Kafka 服務(wù)上下線、集群內(nèi)負(fù)載均衡、副本擴(kuò)縮容、副本缺失修復(fù)以及節(jié)點(diǎn)降級(jí)等功能。顯然，Cruise Control的出現(xiàn)，使得我們能夠更容易的運(yùn)維大規(guī)模Kafka集群。

備注：本文基于 Kafka 2.1.1開展。

一、  Kafka 負(fù)載均衡

1.1 生產(chǎn)者負(fù)載均衡

Kafka 客戶端可以使用分區(qū)器依據(jù)消息的key計(jì)算分區(qū)，如果在發(fā)送消息時(shí)未指定key，則默認(rèn)分區(qū)器會(huì)基于round robin算法為每條消息分配分區(qū)；

否則會(huì)基于murmur2哈希算法計(jì)算key的哈希值，并與分區(qū)數(shù)取模的到最后的分區(qū)編號(hào)。

很顯然，這并不是我們要討論的Kafka負(fù)載均衡，因?yàn)樯a(chǎn)者負(fù)載均衡看起來(lái)并不是那么的復(fù)雜。

1.2 消費(fèi)者負(fù)載均衡

考慮到消費(fèi)者上下線、topic分區(qū)數(shù)變更等情況，KafkaConsumer還需要負(fù)責(zé)與服務(wù)端交互執(zhí)行分區(qū)再分配操作，以保證消費(fèi)者能夠更加均衡的消費(fèi)topic分區(qū)，從而提升消費(fèi)的性能；

Kafka目前主流的分區(qū)分配策略有2種(默認(rèn)是range，可以通過(guò)partition.assignment.strategy參數(shù)指定)：

• range: 在保證均衡的前提下，將連續(xù)的分區(qū)分配給消費(fèi)者，對(duì)應(yīng)的實(shí)現(xiàn)是RangeAssignor；
• round-robin：在保證均衡的前提下，輪詢分配，對(duì)應(yīng)的實(shí)現(xiàn)是RoundRobinAssignor；
• 0.11.0.0版本引入了一種新的分區(qū)分配策略StickyAssignor，其優(yōu)勢(shì)在于能夠保證分區(qū)均衡的前提下盡量保持原有的分區(qū)分配結(jié)果，從而避免許多冗余的分區(qū)分配操作，減少分區(qū)再分配的執(zhí)行時(shí)間。

無(wú)論是生產(chǎn)者還是消費(fèi)者，Kafka 客戶端內(nèi)部已經(jīng)幫我們做了負(fù)載均衡了，那我們還有討論負(fù)載均衡的必要嗎？答案是肯定的，因?yàn)镵afka負(fù)載不均的主要問題存在于服務(wù)端而不是客戶端。

二、 Kafka 服務(wù)端為什么要做負(fù)載均衡

我們先來(lái)看一下Kafka集群的流量分布（圖1）以及新上線機(jī)器后集群的流量分布（圖2）：

圖1

圖2

從圖1可以看出資源組內(nèi)各broker的流量分布并不是很均衡，而且由于部分topic分區(qū)集中分布在某幾個(gè)broker上，當(dāng)topic流量突增的時(shí)候，會(huì)出現(xiàn)只有部分broker流量突增。

這種情況下，我們就需要擴(kuò)容topic分區(qū)或手動(dòng)執(zhí)行遷移動(dòng)操作。

圖2是我們Kafka集群的一個(gè)資源組擴(kuò)容后的流量分布情況，流量無(wú)法自動(dòng)的分?jǐn)偟叫聰U(kuò)容的節(jié)點(diǎn)上。此時(shí)，就需要我們手動(dòng)的觸發(fā)數(shù)據(jù)遷移，從而才能把流量引到新擴(kuò)容的節(jié)點(diǎn)上。

2.1  Kafka 存儲(chǔ)結(jié)構(gòu)

為什么會(huì)出現(xiàn)上述的問題呢？這個(gè)就需要從Kafka的存儲(chǔ)機(jī)制說(shuō)起。

下圖是Kafka topic的存儲(chǔ)結(jié)構(gòu)，其具體層級(jí)結(jié)構(gòu)描述如下：

1. 每個(gè)broker節(jié)點(diǎn)可以通過(guò)logDirs配置項(xiàng)指定多個(gè)log目錄，我們線上機(jī)器共有12塊盤，每塊盤都對(duì)應(yīng)一個(gè)log目錄。
2. 每個(gè)log目錄下會(huì)有若干個(gè)[topic]-[x]字樣的目錄，該目錄用于存儲(chǔ)指定topic指定分區(qū)的數(shù)據(jù)，對(duì)應(yīng)的如果該topic是3副本，那在集群的其他broker節(jié)點(diǎn)上會(huì)有兩個(gè)和該目錄同名的目錄。
3. 客戶端寫入kafka的數(shù)據(jù)最終會(huì)按照時(shí)間順序成對(duì)的生成.index、.timeindex、.snapshot以及.log文件，這些文件保存在對(duì)應(yīng)的topic分區(qū)目錄下。
4. 為了實(shí)現(xiàn)高可用目的，我們線上的topic一般都是2副本/3副本，topic分區(qū)的每個(gè)副本都分布在不同的broker節(jié)點(diǎn)上，有時(shí)為了降低機(jī)架故障帶來(lái)的風(fēng)險(xiǎn)，topic分區(qū)的不同副本也會(huì)被要求分配在不同機(jī)架的broker節(jié)點(diǎn)上。

了解完Kafka存儲(chǔ)機(jī)制之后，我們可以清晰的了解到，客戶端寫入Kafka的數(shù)據(jù)會(huì)按照topic分區(qū)被路由到broker的不同log目錄下，只要我們不人工干預(yù)，那每次路由的結(jié)果都不會(huì)改變。因?yàn)槊看温酚山Y(jié)果都不會(huì)改變，那么問題來(lái)了：

隨著topic數(shù)量不斷增多，每個(gè)topic的分區(qū)數(shù)量又不一致，最終就會(huì)出現(xiàn)topic分區(qū)在Kafka集群內(nèi)分配不均的情況。

比如：topic1是10個(gè)分區(qū)、topic2是15個(gè)分區(qū)、topic3是3個(gè)分區(qū)，我們集群有6臺(tái)機(jī)器。那6臺(tái)broker上總會(huì)有4臺(tái)broker有兩個(gè)topic1的分區(qū)，有3臺(tái)broke上有3個(gè)topic3分區(qū)等等。

這樣的問題就會(huì)導(dǎo)致分區(qū)多的broker上的出入流量可能要比其他broker上要高，如果要考慮同一topic不同分區(qū)流量不一致、不同topic流量又不一致，再加上我們線上有7000個(gè)topic、13萬(wàn)個(gè)分區(qū)、27萬(wàn)個(gè)副本等等這些。

這么復(fù)雜的情況下，集群內(nèi)總會(huì)有broker負(fù)載特別高，有的broker負(fù)載特別低，當(dāng)broker負(fù)載高到一定的時(shí)候，此時(shí)就需要我們的運(yùn)維同學(xué)介入進(jìn)來(lái)了，我們需要幫這些broker減減壓，從而間接的提升集群總體的負(fù)載能力。

當(dāng)集群整體負(fù)載都很高，業(yè)務(wù)流量會(huì)持續(xù)增長(zhǎng)的時(shí)候，我們會(huì)往集群內(nèi)擴(kuò)機(jī)器。有些同學(xué)想擴(kuò)機(jī)器是好事呀，這會(huì)有什么問題呢？問題和上面是一樣的，因?yàn)榘l(fā)往topic分區(qū)的數(shù)據(jù)，其路由結(jié)果不會(huì)改變，如果沒有人工干預(yù)的話，那新擴(kuò)進(jìn)來(lái)機(jī)器的流量就始終是0，集群內(nèi)原來(lái)的broker負(fù)載依然得不到減輕。

三、如何對(duì) Kafka 做負(fù)載均衡

3.1 人工生成遷移計(jì)劃和遷移

如下圖所示，我們模擬一個(gè)簡(jiǎn)單的場(chǎng)景，其中的T0-P0-R0表示topic-分區(qū)-副本，假設(shè)topic各分區(qū)流量相同，假設(shè)每個(gè)分區(qū)R0副本是leader。

我們可以看到，有兩個(gè)topic T0和T1，T0是5分區(qū)2副本（出入流量為10和5），T1是3分區(qū)2副本（出入流量為5和1），如果嚴(yán)格考慮機(jī)架的話，那topic副本的分布可能如下：

假設(shè)我們現(xiàn)在新擴(kuò)入一臺(tái)broker3(Rack2)，如下圖所示：由于之前考慮了topic在機(jī)架上的分布，所以從整體上看，broker2的負(fù)載要高一些。

我們現(xiàn)在想把broker2上的一些分區(qū)遷移到新擴(kuò)進(jìn)來(lái)的broker3上，綜合考慮機(jī)架、流量、副本個(gè)數(shù)等因素，我們將T0-P2-R0、T0-P3-R1、T0-P4-R0、T1-P0-R1四個(gè)分區(qū)遷移到broker3上。

看起來(lái)還不是很均衡，我們?cè)賹1-P2分區(qū)切換一下leader：

經(jīng)歷一番折騰后，整個(gè)集群就均衡許多了，關(guān)于上面遷移副本和leader切換的命令參考如下：

Kafka 副本遷移腳本

# 副本遷移腳本：kafka-reassign-partitions.sh
# 1. 配置遷移文件
$ vi topic-reassignment.json
{"version":1,"partitions":[
{"topic":"T0","partition":2,"replicas":[broker3,broker1]},
{"topic":"T0","partition":3,"replicas":[broker0,broker3]},
{"topic":"T0","partition":4,"replicas":[broker3,broker1]},
{"topic":"T1","partition":0,"replicas":[broker2,broker3]},
{"topic":"T1","partition":2,"replicas":[broker2,broker0]}
]}
# 2. 執(zhí)行遷移命令
bin/kafka-reassign-partitions.sh --throttle 73400320 --zookeeper zkurl --execute --reassignment-json-file topic-reassignment.json
# 3. 查看遷移狀態(tài)/清除限速配置
bin/kafka-reassign-partitions.sh --zookeeper zkurl --verify --reassignment-json-file topic-reassignment.json

3.2 使用負(fù)載均衡工具-cruise control

經(jīng)過(guò)對(duì)Kafka存儲(chǔ)結(jié)構(gòu)、人工干預(yù)topic分區(qū)分布等的了解后，我們可以看到Kafka運(yùn)維起來(lái)是非常繁瑣的，那有沒有一些工具可以幫助我們解決這些問題呢？

答案是肯定的。

cruise control是LinkedIn針對(duì)Kafka集群運(yùn)維困難問題而開發(fā)的一個(gè)項(xiàng)目，cruise control能夠?qū)afka集群各種資源進(jìn)行動(dòng)態(tài)負(fù)載均衡，這些資源包括：CPU、磁盤使用率、入流量、出流量、副本分布等，同時(shí)cruise control也具有首選leader切換和topic配置變更等功能。

3.2.1 cruise cotnrol 架構(gòu)

我們先簡(jiǎn)單介紹下cruise control的架構(gòu)。

如下圖所示，其主要由Monitor、Analyzer、Executor和Anomaly Detector 四部分組成：

（來(lái)源：cruise control 官網(wǎng)）

（1）Monitor

Monitor分為客戶端Metrics Reporter和服務(wù)端Metrics Sampler：

• Metrics Reporter實(shí)現(xiàn)了Kafka的指標(biāo)上報(bào)接口MetricsReporter，以特定的格式將原生的Kafka指標(biāo)上報(bào)到topic __CruiseControlMetrics中。

• Metrics Sampler從__CruiseControlMetrics中獲取原生指標(biāo)后按照broker和分區(qū)級(jí)指標(biāo)分別進(jìn)行聚合，聚合后的指標(biāo)包含了broker、分區(qū)負(fù)載的均值、最大值等統(tǒng)計(jì)值，這些中間結(jié)果將被發(fā)送topic __KafkaCruiseControlModelTrainingSamples和__KafkaCruiseControlPartitionMetricSamples中；

（2）Analyzer

Analyzer作為cruise control的核心部分，它根據(jù)用戶提供的優(yōu)化目標(biāo)和基于Monitor生成的集群負(fù)載模型生成遷移計(jì)劃。

在cruise control中，“用戶提供的優(yōu)化目標(biāo)”包括硬性目標(biāo)和軟性目標(biāo)兩大類，硬性目標(biāo)是Analyzer在做預(yù)遷移的時(shí)候必須滿足的一類目標(biāo)（例如：副本在遷移后必須滿足機(jī)架分散性原則），軟性目標(biāo)則是盡可能要達(dá)到的目標(biāo)，如果某一副本在遷移后只能同時(shí)滿足硬性目標(biāo)和軟性目標(biāo)中的一類，則以硬性目標(biāo)為主，如果存在硬性目標(biāo)無(wú)法滿足的情況則本次分析失敗。

Analyzer可能需要改進(jìn)的地方：

1. 由于Monitor生成的是整個(gè)集群的負(fù)載模型，我們的Kafka平臺(tái)將Kafka集群劃分為多個(gè)資源組，不同資源組的資源利用率存在很大差別，所以原生的集群負(fù)載模型不再適用于我們的應(yīng)用場(chǎng)景。
2. 大多數(shù)業(yè)務(wù)沒有指定key進(jìn)行生產(chǎn)，所以各分區(qū)的負(fù)載偏差不大。如果topic分區(qū)副本均勻分布在資源組內(nèi)，則資源組也隨之變得均衡。
3. 原生的cruise control會(huì)從集群維度來(lái)展開均衡工作，指定資源組后可以從資源組維度展開均衡工作，但無(wú)法滿足跨資源組遷移的場(chǎng)景。

（3）Executor

Executor作為一個(gè)執(zhí)行者，它執(zhí)行Analyzer分析得到的遷移計(jì)劃。它會(huì)將遷移計(jì)劃以接口的形式分批提交到Kafka集群上，后續(xù)Kafka會(huì)按照提交上來(lái)的遷移腳本執(zhí)行副本遷移。

Executor可能需要改進(jìn)的地方：

cruise control 在執(zhí)行副本遷移類的功能時(shí)，不能觸發(fā)集群首選leader切換：有時(shí)在集群均衡過(guò)程中出現(xiàn)了宕機(jī)重啟，以問題機(jī)器作為首選leader的分區(qū)，其leader不能自動(dòng)切換回來(lái)，造成集群內(nèi)其他節(jié)點(diǎn)壓力陡增，此時(shí)往往會(huì)產(chǎn)生連鎖反應(yīng)。

(4)Anomaly Detector

Anomaly Detector是一個(gè)定時(shí)任務(wù)，它會(huì)定期檢測(cè)Kafka集群是否不均衡或者是否有副本缺失這些異常情況，當(dāng)Kafka集群出現(xiàn)這些情況后，Anomaly Detector會(huì)自動(dòng)觸發(fā)一次集群內(nèi)的負(fù)載均衡。

在后面的主要功能描述中，我會(huì)主要介紹Monitor和Analyzer的處理邏輯。

3.2.2 均衡 broker 出入流量 / 機(jī)器上下線均衡

對(duì)于Kafka集群內(nèi)各broker之間流量負(fù)載不均的原因、示意圖以及解決方案，我們?cè)谏厦嬉呀?jīng)介紹過(guò)了，那么cruise control是如何解決這個(gè)問題的。

其實(shí)cruise control均衡集群的思路和我們手動(dòng)去均衡集群的思路大體一致，只不過(guò)它需要Kafka集群詳細(xì)的指標(biāo)數(shù)據(jù)，以這些指標(biāo)為基礎(chǔ)，去計(jì)算各broker之間的負(fù)載差距，并根據(jù)我們關(guān)注的資源去做分析，從而得出最終的遷移計(jì)劃。

服務(wù)端在接收到均衡請(qǐng)求后，Monitor會(huì)先根據(jù)緩存的集群指標(biāo)數(shù)據(jù)構(gòu)建一個(gè)能夠描述整個(gè)集群負(fù)載分布的模型。

下圖簡(jiǎn)單描述了整個(gè)集群負(fù)載信息的生成過(guò)程，smaple fetcher線程會(huì)將獲取到的原生指標(biāo)加載成可讀性更好的Metric Sample，并對(duì)其進(jìn)行進(jìn)一步的加工，得到帶有brokerid、partition分區(qū)等信息的統(tǒng)計(jì)指標(biāo)，這些指標(biāo)保存在對(duì)應(yīng)broker、replica的load屬性中，所以broker和repilca會(huì)包含流量負(fù)載、存儲(chǔ)大小、當(dāng)前副本是否是leader等信息。

Analyzer 會(huì)遍歷我們指定的broker（默認(rèn)是集群所有的broker），由于每臺(tái)broker及其下面的topic分區(qū)副本都有詳細(xì)的指標(biāo)信息，分析算法直接根據(jù)這些指標(biāo)和指定資源對(duì)broker進(jìn)行排序。

本例子的資源就是topic分區(qū)leader副本數(shù)量，接著Analyzer會(huì)根據(jù)我們提前設(shè)置的最大/最小閾值、離散因子等來(lái)判斷當(dāng)前broker上某topic的leader副本數(shù)量是否需要增加或縮減，如果是增加，則變更c(diǎn)lustermodel將負(fù)載比較高的broker上對(duì)應(yīng)的topic leader副本遷移到當(dāng)前broker上，反之亦然，在后面的改造點(diǎn)中，我們會(huì)對(duì)Analyzer的工作過(guò)程做簡(jiǎn)單的描述。

遍歷過(guò)所有broker，并且針對(duì)我們指定的所有資源都進(jìn)行分析之后，就得出了最終版的clustermodel，再與我們最初生成的clustermodel對(duì)比，就生成了topic遷移計(jì)劃。

cruise control會(huì)根據(jù)我們指定的遷移策略分批次的將topic遷移計(jì)劃提交給kafka集群執(zhí)行。

遷移計(jì)劃示意圖如下：

3.2.3 首選 leader 切換

切換非首選leader副本，遷移計(jì)劃示意圖如下：

3.2.4 topic配置變更

改變topic副本個(gè)數(shù)，遷移計(jì)劃示意圖如下：

3.3  改造 cruise control

3.3.1 指定資源組進(jìn)行均衡

當(dāng)集群規(guī)模非常龐大的時(shí)候，我們想要均衡整個(gè)集群就變得非常困難，往往均衡一次就需要半個(gè)月甚至更長(zhǎng)時(shí)間，這在無(wú)形之中也加大了我們運(yùn)維同學(xué)的壓力。

針對(duì)這個(gè)場(chǎng)景，我們對(duì)cruise control也進(jìn)行了改造，我們從邏輯上將Kafka集群劃分成多個(gè)資源組，使得業(yè)務(wù)擁有自己的資源組，當(dāng)某個(gè)業(yè)務(wù)出現(xiàn)流量波動(dòng)的時(shí)候，不會(huì)影響到其他的業(yè)務(wù)。

通過(guò)指定資源組，我們每次只需要對(duì)集群的一小部分或多個(gè)部分進(jìn)行均衡即可，大大縮短了均衡的時(shí)間，使得均衡的過(guò)程更加可控。

改造后的cruise control可以做到如下幾點(diǎn)：

1. 通過(guò)均衡參數(shù)，我們可以只均衡某個(gè)或多個(gè)資源組的broker。
2. 更改topic配置，比如增加topic副本時(shí)，新擴(kuò)的副本需要和topic原先的副本在同一個(gè)資源組內(nèi)。
3. 在資源組內(nèi)分析broker上的資源是遷入還是遷出。對(duì)于每一類資源目標(biāo)，cruise control是計(jì)算資源組范圍內(nèi)的統(tǒng)計(jì)指標(biāo)，然后結(jié)合閾值和離散因子來(lái)分析broker是遷出資源還是遷入資源。

如下圖所示，我們將集群、資源組、以及資源組下的topic這些元數(shù)據(jù)保存在數(shù)據(jù)庫(kù)中，Analyzer得以在指定的資源組范圍內(nèi)，對(duì)每個(gè)broker按照資源分布目標(biāo)做均衡分析。

例如：當(dāng)對(duì)broker-0做均衡分析的時(shí)候，Analyzer會(huì)遍歷goals列表，每個(gè)goals負(fù)責(zé)一類資源負(fù)載目標(biāo)（cpu、入流量等），當(dāng)均衡分析到達(dá)goal-0的時(shí)候，goal-0會(huì)判斷broker-0的負(fù)載是否超出上限閾值，如果超出，則需要將broker-0的一些topic副本遷移到負(fù)載較低的broker上；反之，則需要將其他broker上的副本遷移到broker-0上。

其中，下面的recheck goals是排在后面的goal在做均衡分析的時(shí)候，在更新cluster model之前會(huì)判斷本次遷移會(huì)不會(huì)與之前的goal沖突，如果沖突，那就不更新cluster model，當(dāng)前的goal會(huì)繼續(xù)嘗試往其他broker上遷移，直到找到適合的遷移目標(biāo)，然后更新cluster model。

3.3.2 topic/topic分區(qū)往指定broker上遷移

考慮這些場(chǎng)景：

1. 一個(gè)項(xiàng)目下會(huì)有幾個(gè)資源組，由于業(yè)務(wù)變更，業(yè)務(wù)想要把A資源組下的topic遷移到B資源組。
2. 業(yè)務(wù)想要把公共資源組的topic遷移到C資源組。
3. 均衡完成之后，發(fā)現(xiàn)總有幾個(gè)topic/分區(qū)分布不是很均勻。

面對(duì)這些場(chǎng)景，我們上面指定資源組進(jìn)行均衡的功能就滿足不了我們的需求了。所以，我們針對(duì)上述場(chǎng)景改造后的cruise control可以做到如下幾點(diǎn)：

1. 只均衡指定的topic或topic分區(qū)；
2. 均衡的topic或topic分區(qū)只往指定的broker上遷移。

3.3.3 新增目標(biāo)分析——topic分區(qū)leader副本分散性

業(yè)務(wù)方大多都是沒有指定key進(jìn)行發(fā)送數(shù)據(jù)的，所以同一topic每個(gè)分區(qū)的流量、存儲(chǔ)都是接近的，即每一個(gè)topic的各個(gè)分區(qū)的leader副本盡可能均勻的分布在集群的broker上時(shí)，那集群的負(fù)載就會(huì)很均勻。

有同學(xué)會(huì)問了，topic分區(qū)數(shù)并不總是能夠整除broker數(shù)量，那最后各broker的負(fù)載不還是不一致嘛？

答案是肯定的，只通過(guò)分區(qū)的leader副本還不能做到最終的均衡。

針對(duì)上述場(chǎng)景改造后的cruise control可以做到如下幾點(diǎn)：

1. 新增一類資源分析：topic分區(qū)leader副本分散性。
2. 首先保證每個(gè)topic的leader副本和follower副本盡可能的均勻分布在資源組的broker上。
3. 在2的基礎(chǔ)上，副本會(huì)盡可能的往負(fù)載較低的broker上分布。

如下圖所示，針對(duì)每一個(gè)topic的副本，Analyzer會(huì)依次計(jì)算當(dāng)前broker的topic leader數(shù)是否超過(guò)閾值上限，如果超過(guò)，則Analyzer會(huì)按照topic的leader副本數(shù)量、topic的follower副本數(shù)量、broker的出流量負(fù)載等來(lái)選出AR中的follower副本作為新的leader進(jìn)行切換，如果AR副本中也沒有符合要求的broker，則會(huì)選擇AR列表以外的broker。

3.3.4 最終均衡效果

下圖是某個(gè)資源組均衡后的流量分布，各節(jié)點(diǎn)間流量偏差非常小，這種情況下，既可以增強(qiáng)集群扛住流量異常突增的能力又可以提升集群整體資源利用率和服務(wù)穩(wěn)定性，降低成本。

3.4 安裝/部署cruise control

3.4.1 客戶端部署：指標(biāo)采集

【步驟1】：創(chuàng)建Kafka賬號(hào)，用于后面生產(chǎn)和消費(fèi)指標(biāo)數(shù)據(jù)

【步驟2】：創(chuàng)建3個(gè)Kafka內(nèi)部topic：a是用來(lái)存儲(chǔ)Kafka服務(wù)原生jmx指標(biāo)；b和c分別是用來(lái)存儲(chǔ)cruise control處理過(guò)后的分區(qū)和模型指標(biāo)；

【步驟3】：給步驟1創(chuàng)建的賬號(hào)授予讀/寫以及集群的操作權(quán)限，用于讀/寫步驟2創(chuàng)建的topic；

【步驟4】：修改kafka的server.properties，增加如下配置：

在Kafka服務(wù)上配置采集程序

# 修改kafka的server.properties
metric.reporters=com.linkedin.kafka.cruisecontrol.metricsreporter.CruiseControlMetricsReporter
cruise.control.metrics.reporter.bootstrap.servers=域名:9092
cruise.control.metrics.reporter.security.protocol=SASL_PLAINTEXT
cruise.control.metrics.reporter.sasl.mechanism=SCRAM-SHA-256
cruise.control.metrics.reporter.sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username=\"ys\" password=\"ys\";

【步驟5】：添加cruise-control-metrics-reporter的jar包到Kafka的lib目錄下：mv cruise-control-metrics-reporter-2.0.104-SNAPSHOT.jar kafka_dir/lib/；

【步驟6】：重啟Kafka服務(wù)。

3.4.2 服務(wù)端部署：指標(biāo)聚合/均衡分析

（1）到https://github.com/linkedin/cruise-control 下載zip文件并解壓；

（2）將自己本地cruise control子模塊下生成的jar包替換cruise control的：

mv cruise-control-2.0.xxx-SNAPSHOT.jar 
cruise-control/build/libs；

（3）修改cruise control配置文件，主要關(guān)注如下配置：

# 修改cruise control配置文件
security.protocol=SASL_PLAINTEXT
sasl.mechanism=SCRAM-SHA-256
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username=\"ys\" password=\"ys\";
bootstrap.servers=域名:9092
zookeeper.connect=zkURL

（4）修改數(shù)據(jù)庫(kù)連接配置：

# 集群id
cluster_id=xxx  
db_url=jdbc:mysql://hostxxxx:3306/databasexxx
db_user=xxx
db_pwd=xxx

四、總結(jié)

通過(guò)以上的介紹，我們可以看出Kafka存在比較明顯的兩個(gè)缺陷：

1. Kafka每個(gè)partition replica與機(jī)器的磁盤綁定，partition replica由一系列的Segment組成，所以往往單分區(qū)存儲(chǔ)會(huì)占用比較大的磁盤空間，對(duì)于磁盤會(huì)有很大壓力。
2. 在集群擴(kuò)容broker時(shí)必須做Rebalance，需要broker有良好的執(zhí)行流程，保證沒有任何故障的情況下使得各broker負(fù)載均衡。

cruise control就是針對(duì)Kafka集群運(yùn)維困難問題而誕生的，它能夠很好的解決kafka運(yùn)維困難的問題。

參考文章：

1. linkedIn/cruise-control?2. Introduction to Kafka Cruise Control?3. Cloudera Cruise Control REST API Reference

4. http://dockone.io/article/2434664

5. https://www.zhenchao.org/2019/06/22/kafka/kafka-log-manage/