一汉买、Kafka應(yīng)用
本文主要總結(jié)當(dāng)Kafka集群流量達(dá)到 萬(wàn)億級(jí)記錄/天或者十萬(wàn)億級(jí)記錄/天 甚至更高后，我們需要具備哪些能力才能保障集群高可用邻悬、高可靠症昏、高性能、高吞吐父丰、安全的運(yùn)行肝谭。
這里總結(jié)內(nèi)容主要針對(duì)Kafka2.1.1版本，包括集群版本升級(jí)、數(shù)據(jù)遷移分苇、流量限制添诉、監(jiān)控告警、負(fù)載均衡医寿、集群擴(kuò)/縮容栏赴、資源隔離、集群容災(zāi)靖秩、集群安全须眷、性能優(yōu)化、平臺(tái)化沟突、開(kāi)源版本缺陷花颗、社區(qū)動(dòng)態(tài)等方面。本文主要是介紹核心脈絡(luò)惠拭，不做過(guò)多細(xì)節(jié)講解扩劝。下面我們先來(lái)看看Kafka作為數(shù)據(jù)中樞的一些核心應(yīng)用場(chǎng)景。
下圖展示了一些主流的數(shù)據(jù)處理流程职辅，Kafka起到一個(gè)數(shù)據(jù)中樞的作用棒呛。
接下來(lái)看看我們Kafka平臺(tái)整體架構(gòu)；
1.1 版本升級(jí)
1.1.1 開(kāi)源版本如何進(jìn)行版本滾動(dòng)升級(jí)與回退
官網(wǎng)地址：http://kafka.apache.org
1.1.1.2 源碼改造如何升級(jí)與回退
由于在升級(jí)過(guò)程中域携，必然出現(xiàn)新舊代碼邏輯交替的情況簇秒。集群內(nèi)部部分節(jié)點(diǎn)是開(kāi)源版本，另外一部分節(jié)點(diǎn)是改造后的版本秀鞭。所以趋观，需要考慮在升級(jí)過(guò)程中，新舊代碼混合的情況锋边，如何兼容以及出現(xiàn)故障時(shí)如何回退皱坛。
1.2 數(shù)據(jù)遷移
由于Kafka集群的架構(gòu)特點(diǎn)，這必然導(dǎo)致集群內(nèi)流量負(fù)載不均衡的情況豆巨，所以我們需要做一些數(shù)據(jù)遷移來(lái)實(shí)現(xiàn)集群不同節(jié)點(diǎn)間的流量均衡麸恍。Kafka開(kāi)源版本為數(shù)據(jù)遷移提供了一個(gè)腳本工具“bin/kafka-reassign-partitions.sh”，如果自己沒(méi)有實(shí)現(xiàn)自動(dòng)負(fù)載均衡搀矫，可以使用此腳本抹沪。
開(kāi)源版本提供的這個(gè)腳本生成遷移計(jì)劃完全是人工干預(yù)的亿乳，當(dāng)集群規(guī)模非常大時(shí)颊郎，遷移效率變得非常低下，一般以天為單位進(jìn)行計(jì)算盯孙。當(dāng)然卦羡，我們可以實(shí)現(xiàn)一套自動(dòng)化的均衡程序噪馏，當(dāng)負(fù)載均衡實(shí)現(xiàn)自動(dòng)化以后麦到，基本使用調(diào)用內(nèi)部提供的API，由程序去幫我們生成遷移計(jì)劃及執(zhí)行遷移任務(wù)欠肾。需要注意的是瓶颠，遷移計(jì)劃有指定數(shù)據(jù)目錄和不指定數(shù)據(jù)目錄兩種，指定數(shù)據(jù)目錄的需要配置ACL安全認(rèn)證刺桃。
官網(wǎng)地址：http://kafka.apache.org
1.2.1 broker間數(shù)據(jù)遷移
不指定數(shù)據(jù)目錄
//未指定遷移目錄的遷移計(jì)劃
{
"version":1,
"partitions":[
{"topic":"yyj4","partition":0,"replicas":[1000003,1000004]},
{"topic":"yyj4","partition":1,"replicas":[1000003,1000004]},
{"topic":"yyj4","partition":2,"replicas":[1000003,1000004]}
]
}
指定數(shù)據(jù)目錄
//指定遷移目錄的遷移計(jì)劃
{
"version":1,
"partitions":[
{"topic":"yyj1","partition":0,"replicas":[1000006,1000005],"log_dirs":["/data1/bigdata/mydata1","/data1/bigdata/mydata3"]},
{"topic":"yyj1","partition":1,"replicas":[1000006,1000005],"log_dirs":["/data1/bigdata/mydata1","/data1/bigdata/mydata3"]},
{"topic":"yyj1","partition":2,"replicas":[1000006,1000005],"log_dirs":["/data1/bigdata/mydata1","/data1/bigdata/mydata3"]}
]
}
1.2.2 broker內(nèi)部磁盤間數(shù)據(jù)遷移
生產(chǎn)環(huán)境的服務(wù)器一般都是掛載多塊硬盤粹淋，比如4塊/12塊等；那么可能出現(xiàn)在Kafka集群內(nèi)部瑟慈，各broker間流量比較均衡桃移，但是在broker內(nèi)部，各磁盤間流量不均衡葛碧，導(dǎo)致部分磁盤過(guò)載借杰，從而影響集群性能和穩(wěn)定，也沒(méi)有較好的利用硬件資源进泼。在這種情況下蔗衡，我們就需要對(duì)broker內(nèi)部多塊磁盤的流量做負(fù)載均衡，讓流量更均勻的分布到各磁盤上乳绕。
1.2.3 并發(fā)數(shù)據(jù)遷移
當(dāng)前Kafka開(kāi)源版本（2.1.1版本）提供的副本遷移工具“bin/kafka-reassign-partitions.sh”在同一個(gè)集群內(nèi)只能實(shí)現(xiàn)遷移任務(wù)的串行绞惦。對(duì)于集群內(nèi)已經(jīng)實(shí)現(xiàn)多個(gè)資源組物理隔離的情況，由于各資源組不會(huì)相互影響刷袍，但是卻不能友好的進(jìn)行并行的提交遷移任務(wù)，遷移效率有點(diǎn)低下樊展，這種不足直到2.6.0版本才得以解決呻纹。如果需要實(shí)現(xiàn)并發(fā)數(shù)據(jù)遷移，可以選擇升級(jí)Kafka版本或者修改Kafka源碼专缠。
1.2.4 終止數(shù)據(jù)遷移
當(dāng)前Kafka開(kāi)源版本（2.1.1版本）提供的副本遷移工具“bin/kafka-reassign-partitions.sh”在啟動(dòng)遷移任務(wù)后雷酪，無(wú)法終止遷移。當(dāng)遷移任務(wù)對(duì)集群的穩(wěn)定性或者性能有影響時(shí)涝婉，將變得束手無(wú)策哥力，只能等待遷移任務(wù)執(zhí)行完畢（成功或者失敗）墩弯，這種不足直到2.6.0版本才得以解決吩跋。如果需要實(shí)現(xiàn)終止數(shù)據(jù)遷移，可以選擇升級(jí)Kafka版本或者修改Kafka源碼渔工。
1.3 流量限制
1.3.1 生產(chǎn)消費(fèi)流量限制
經(jīng)常會(huì)出現(xiàn)一些突發(fā)的锌钮，不可預(yù)測(cè)的異常生產(chǎn)或者消費(fèi)流量會(huì)對(duì)集群的IO等資源產(chǎn)生巨大壓力，最終影響整個(gè)集群的穩(wěn)定與性能引矩。那么我們可以對(duì)用戶的生產(chǎn)梁丘、消費(fèi)侵浸、副本間數(shù)據(jù)同步進(jìn)行流量限制，這個(gè)限流機(jī)制并不是為了限制用戶氛谜，而是避免突發(fā)的流量影響集群的穩(wěn)定和性能掏觉，給用戶可以更好的服務(wù)。
如下圖所示值漫，節(jié)點(diǎn)入流量由140MB/s左右突增到250MB/s澳腹，而出流量則從400MB/s左右突增至800MB/s。如果沒(méi)有限流機(jī)制惭嚣，那么集群的多個(gè)節(jié)點(diǎn)將有被這些異常流量打掛的風(fēng)險(xiǎn)遵湖，甚至造成集群雪崩。
圖片生產(chǎn)/消費(fèi)流量限制官網(wǎng)地址：點(diǎn)擊鏈接
對(duì)于生產(chǎn)者和消費(fèi)者的流量限制晚吞，官網(wǎng)提供了以下幾種維度組合進(jìn)行限制（當(dāng)然延旧，下面限流機(jī)制存在一定缺陷，后面在“Kafka開(kāi)源版本功能缺陷”我們將提到）：
/config/users/<user>/clients/<client-id> //根據(jù)用戶和客戶端ID組合限流
/config/users/<user>/clients/<default>
/config/users/<user>//根據(jù)用戶限流 這種限流方式是我們最常用的方式
/config/users/<default>/clients/<client-id>
/config/users/<default>/clients/<default>
/config/users/<default>
/config/clients/<client-id>
/config/clients/<default>
在啟動(dòng)Kafka的broker服務(wù)時(shí)需要開(kāi)啟JMX參數(shù)配置槽地，方便通過(guò)其他應(yīng)用程序采集Kafka的各項(xiàng)JMX指標(biāo)進(jìn)行服務(wù)監(jiān)控迁沫。當(dāng)用戶需要調(diào)整限流閾值時(shí)，根據(jù)單個(gè)broker所能承受的流量進(jìn)行智能評(píng)估捌蚊，無(wú)需人工干預(yù)判斷是否可以調(diào)整集畅；對(duì)于用戶流量限制，主要需要參考的指標(biāo)包括以下兩個(gè)：
（1）消費(fèi)流量指標(biāo)：ObjectName：kafka.server:type=Fetch,user=acl認(rèn)證用戶名稱 屬性：byte-rate（用戶在當(dāng)前broker的出流量）缅糟、throttle-time（用戶在當(dāng)前broker的出流量被限制時(shí)間）
（2）生產(chǎn)流量指標(biāo)：ObjectName：kafka.server:type=Produce,user=acl認(rèn)證用戶名稱 屬性：byte-rate（用戶在當(dāng)前broker的入流量）挺智、throttle-time（用戶在當(dāng)前broker的入流量被限制時(shí)間）
1.3.2 follower同步leader/數(shù)據(jù)遷移流量限制
副本遷移/數(shù)據(jù)同步流量限制官網(wǎng)地址：鏈接
涉及參數(shù)如下：
//副本同步限流配置共涉及以下4個(gè)參數(shù)
leader.replication.throttled.rate
follower.replication.throttled.rate
leader.replication.throttled.replicas
follower.replication.throttled.replicas
輔助指標(biāo)如下：
（1）副本同步出流量指標(biāo)：ObjectName：kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesOutPerSec
（2）副本同步入流量指標(biāo)：ObjectName：kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesInPerSec
1.4 監(jiān)控告警
關(guān)于Kafka的監(jiān)控有一些開(kāi)源的工具可用使用，比如下面這幾種：
Kafka Eagle赦颇；
KafkaOffsetMonitor赴涵；
我們已經(jīng)把Kafka Manager作為我們查看一些基本指標(biāo)的工具嵌入平臺(tái)媒怯，然而這些開(kāi)源工具不能很好的融入到我們自己的業(yè)務(wù)系統(tǒng)或者平臺(tái)上。所以髓窜，我們需要自己去實(shí)現(xiàn)一套粒度更細(xì)扇苞、監(jiān)控更智能、告警更精準(zhǔn)的系統(tǒng)寄纵。其監(jiān)控覆蓋范圍應(yīng)該包括基礎(chǔ)硬件鳖敷、操作系統(tǒng)（操作系統(tǒng)偶爾出現(xiàn)系統(tǒng)進(jìn)程hang住情況，導(dǎo)致broker假死程拭，無(wú)法正常提供服務(wù)）哄陶、Kafka的broker服務(wù)、Kafka客戶端應(yīng)用程序哺壶、zookeeper集群屋吨、上下游全鏈路監(jiān)控蜒谤。
1.4.1 硬件監(jiān)控
網(wǎng)絡(luò)監(jiān)控：
核心指標(biāo)包括網(wǎng)絡(luò)入流量、網(wǎng)絡(luò)出流量至扰、網(wǎng)絡(luò)丟包鳍徽、網(wǎng)絡(luò)重傳、處于TIME.WAIT的TCP連接數(shù)敢课、交換機(jī)阶祭、機(jī)房帶寬、DNS服務(wù)器監(jiān)控（如果DNS服務(wù)器異常直秆，可能出現(xiàn)流量黑洞濒募，引起大面積業(yè)務(wù)故障）等。
磁盤監(jiān)控：
核心指標(biāo)包括監(jiān)控磁盤write圾结、磁盤read（如果消費(fèi)時(shí)沒(méi)有延時(shí)瑰剃，或者只有少量延時(shí)，一般都沒(méi)有磁盤read操作）筝野、磁盤ioutil晌姚、磁盤iowait（這個(gè)指標(biāo)如果過(guò)高說(shuō)明磁盤負(fù)載較大）、磁盤存儲(chǔ)空間歇竟、磁盤壞盤挥唠、磁盤壞塊/壞道（壞道或者壞塊將導(dǎo)致broker處于半死不活狀態(tài)，由于有crc校驗(yàn)焕议，消費(fèi)者將被卡妆δァ）等。
CPU監(jiān)控：
監(jiān)控CPU空閑率/負(fù)載盅安，主板故障等唤锉，通常CPU使用率比較低不是Kafka的瓶頸。
內(nèi)存/交換區(qū)監(jiān)控：
內(nèi)存使用率宽堆，內(nèi)存故障腌紧。一般情況下茸习，服務(wù)器上除了啟動(dòng)Kafka的broker時(shí)分配的堆內(nèi)存以外畜隶，其他內(nèi)存基本全部被用來(lái)做PageCache。
緩存命中率監(jiān)控：
由于是否讀磁盤對(duì)Kafka的性能影響很大号胚，所以我們需要監(jiān)控Linux的PageCache緩存命中率籽慢，如果緩存命中率高，則說(shuō)明消費(fèi)者基本命中緩存猫胁。
詳細(xì)內(nèi)容請(qǐng)閱讀文章：《Linux Page Cache調(diào)優(yōu)在Kafka中的應(yīng)用》箱亿。
系統(tǒng)日志：
我們需要對(duì)操作系統(tǒng)的錯(cuò)誤日志進(jìn)行監(jiān)控告警，及時(shí)發(fā)現(xiàn)一些硬件故障弃秆。
1.4.2 broker服務(wù)監(jiān)控
broker服務(wù)的監(jiān)控届惋，主要是通過(guò)在broker服務(wù)啟動(dòng)時(shí)指定JMX端口髓帽，然后通過(guò)實(shí)現(xiàn)一套指標(biāo)采集程序去采集JMX指標(biāo)。（服務(wù)端指標(biāo)官網(wǎng)地址）
broker級(jí)監(jiān)控：broker進(jìn)程脑豹、broker入流量字節(jié)大小/記錄數(shù)郑藏、broker出流量字節(jié)大小/記錄數(shù)、副本同步入流量瘩欺、副本同步出流量必盖、broker間流量偏差、broker連接數(shù)俱饿、broker請(qǐng)求隊(duì)列數(shù)歌粥、broker網(wǎng)絡(luò)空閑率、broker生產(chǎn)延時(shí)拍埠、broker消費(fèi)延時(shí)失驶、broker生產(chǎn)請(qǐng)求數(shù)、broker消費(fèi)請(qǐng)求數(shù)械拍、broker上分布leader個(gè)數(shù)突勇、broker上分布副本個(gè)數(shù)、broker上各磁盤流量坷虑、broker GC等甲馋。
topic級(jí)監(jiān)控：topic入流量字節(jié)大小/記錄數(shù)、topic出流量字節(jié)大小/記錄數(shù)迄损、無(wú)流量topic定躏、topic流量突變（突增/突降）、topic消費(fèi)延時(shí)芹敌。
partition級(jí)監(jiān)控：分區(qū)入流量字節(jié)大小/記錄數(shù)痊远、分區(qū)出流量字節(jié)大小/記錄數(shù)、topic分區(qū)副本缺失氏捞、分區(qū)消費(fèi)延遲記錄碧聪、分區(qū)leader切換、分區(qū)數(shù)據(jù)傾斜（生產(chǎn)消息時(shí)液茎，如果指定了消息的key容易造成數(shù)據(jù)傾斜逞姿，這嚴(yán)重影響Kafka的服務(wù)性能）、分區(qū)存儲(chǔ)大欣Φ取（可以治理單分區(qū)過(guò)大的topic）滞造。
用戶級(jí)監(jiān)控：用戶出/入流量字節(jié)大小、用戶出/入流量被限制時(shí)間栋烤、用戶流量突變（突增/突降）谒养。
broker服務(wù)日志監(jiān)控：對(duì)server端打印的錯(cuò)誤日志進(jìn)行監(jiān)控告警，及時(shí)發(fā)現(xiàn)服務(wù)異常明郭。
1.4.3.客戶端監(jiān)控
客戶端監(jiān)控主要是自己實(shí)現(xiàn)一套指標(biāo)上報(bào)程序买窟，這個(gè)程序需要實(shí)現(xiàn)
org.apache.kafka.common.metrics.MetricsReporter 接口丰泊。然后在生產(chǎn)者或者消費(fèi)者的配置中加入配置項(xiàng) metric.reporters，如下所示：
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "");
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, IntegerSerializer.class.getName());
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
//ClientMetricsReporter類實(shí)現(xiàn)org.apache.kafka.common.metrics.MetricsReporter接口
props.put(ProducerConfig.METRIC_REPORTER_CLASSES_CONFIG, ClientMetricsReporter.class.getName());
...
客戶端指標(biāo)官網(wǎng)地址：
http://kafka.apache.org/21/documentation.html#selector_monitoring
http://kafka.apache.org/21/documentation.html#common_node_monitoring
http://kafka.apache.org/21/documentation.html#producer_monitoring
http://kafka.apache.org/21/documentation.html#producer_sender_monitoring
http://kafka.apache.org/21/documentation.html#consumer_monitoring
http://kafka.apache.org/21/documentation.html#consumer_fetch_monitoring
客戶端監(jiān)控流程架構(gòu)如下圖所示：
1.4.3.1 生產(chǎn)者客戶端監(jiān)控
維度：用戶名稱始绍、客戶端ID趁耗、客戶端IP、topic名稱疆虚、集群名稱苛败、brokerIP；
指標(biāo)：連接數(shù)径簿、IO等待時(shí)間罢屈、生產(chǎn)流量大小、生產(chǎn)記錄數(shù)篇亭、請(qǐng)求次數(shù)缠捌、請(qǐng)求延時(shí)、發(fā)送錯(cuò)誤/重試次數(shù)等译蒂。
1.4.3.2 消費(fèi)者客戶端監(jiān)控
維度：用戶名稱曼月、客戶端ID、客戶端IP柔昼、topic名稱哑芹、集群名稱、消費(fèi)組捕透、brokerIP聪姿、topic分區(qū)；
指標(biāo)：連接數(shù)乙嘀、io等待時(shí)間末购、消費(fèi)流量大小、消費(fèi)記錄數(shù)虎谢、消費(fèi)延時(shí)盟榴、topic分區(qū)消費(fèi)延遲記錄等。
1.4.4 Zookeeper監(jiān)控
Zookeeper進(jìn)程監(jiān)控婴噩；
Zookeeper的leader切換監(jiān)控擎场；
Zookeeper服務(wù)的錯(cuò)誤日志監(jiān)控；
1.4.5 全鏈路監(jiān)控
當(dāng)數(shù)據(jù)鏈路非常長(zhǎng)的時(shí)候（比如：業(yè)務(wù)應(yīng)用->埋點(diǎn)SDk->數(shù)據(jù)采集->Kafka->實(shí)時(shí)計(jì)算->業(yè)務(wù)應(yīng)用）讳推，我們定位問(wèn)題通常需要經(jīng)過(guò)多個(gè)團(tuán)隊(duì)反復(fù)溝通與排查才能發(fā)現(xiàn)問(wèn)題到底出現(xiàn)在哪個(gè)環(huán)節(jié)顶籽，這樣排查問(wèn)題效率比較低下玩般。在這種情況下银觅，我們就需要與上下游一起梳理整個(gè)鏈路的監(jiān)控。出現(xiàn)問(wèn)題時(shí)坏为，第一時(shí)間定位問(wèn)題出現(xiàn)在哪個(gè)環(huán)節(jié)究驴，縮短問(wèn)題定位與故障恢復(fù)時(shí)間镊绪。
1.5 資源隔離
1.5.1 相同集群不同業(yè)務(wù)資源物理隔離
我們對(duì)所有集群中不同對(duì)業(yè)務(wù)進(jìn)行資源組物理隔離，避免各業(yè)務(wù)之間相互影響洒忧。在這里蝴韭，我們假設(shè)集群有4個(gè)broker節(jié)點(diǎn)（Broker1/Broker2/Broker3/Broker4），2個(gè)業(yè)務(wù)（業(yè)務(wù)A/業(yè)務(wù)B）熙侍，他們分別擁有topic分區(qū)分布如下圖所示榄鉴，兩個(gè)業(yè)務(wù)topic都分散在集群的各個(gè)broker上，并且在磁盤層面也存在交叉蛉抓。
試想一下庆尘，如果我們其中一個(gè)業(yè)務(wù)異常，比如流量突增巷送，導(dǎo)致broker節(jié)點(diǎn)異呈患桑或者被打掛。那么這時(shí)候另外一個(gè)業(yè)務(wù)也將受到影響笑跛，這樣將大大的影響了我們服務(wù)的可用性付魔，造成故障，擴(kuò)大了故障影響范圍飞蹂。
針對(duì)這些痛點(diǎn)几苍，我們可以對(duì)集群中的業(yè)務(wù)進(jìn)行物理資源隔離，各業(yè)務(wù)獨(dú)享資源陈哑，進(jìn)行資源組劃分（這里把4各broker劃分為Group1和Group2兩個(gè)資源組）如下圖所示擦剑，不同業(yè)務(wù)的topic分布在自己的資源組內(nèi)，當(dāng)其中一個(gè)業(yè)務(wù)異常時(shí)芥颈，不會(huì)波及另外一個(gè)業(yè)務(wù)惠勒，這樣就可以有效的縮小我們的故障范圍，提高服務(wù)可用性爬坑。
1.6 集群歸類
我們把集群根據(jù)業(yè)務(wù)特點(diǎn)進(jìn)行拆分為日志集群纠屋、監(jiān)控集群、計(jì)費(fèi)集群盾计、搜索集群售担、離線集群、在線集群等署辉，不同場(chǎng)景業(yè)務(wù)放在不同集群族铆，避免不同業(yè)務(wù)相互影響。
1.7 擴(kuò)容/縮容
1.7.1 topic擴(kuò)容分區(qū)
隨著topic數(shù)據(jù)量增長(zhǎng)哭尝，我們最初創(chuàng)建的topic指定的分區(qū)個(gè)數(shù)可能已經(jīng)無(wú)法滿足數(shù)量流量要求哥攘，所以我們需要對(duì)topic的分區(qū)進(jìn)行擴(kuò)展。擴(kuò)容分區(qū)時(shí)需要考慮一下幾點(diǎn)：
必須保證topic分區(qū)leader與follower輪詢的分布在資源組內(nèi)所有broker上，讓流量分布更加均衡逝淹，同時(shí)需要考慮相同分區(qū)不同副本跨機(jī)架分布以提高容災(zāi)能力耕姊；
當(dāng)topic分區(qū)leader個(gè)數(shù)除以資源組節(jié)點(diǎn)個(gè)數(shù)有余數(shù)時(shí)，需要把余數(shù)分區(qū)leader優(yōu)先考慮放入流量較低的broker栅葡。
1.7.2 broker上線
隨著業(yè)務(wù)量增多茉兰，數(shù)據(jù)量不斷增大，我們的集群也需要進(jìn)行broker節(jié)點(diǎn)擴(kuò)容欣簇。關(guān)于擴(kuò)容规脸，我們需要實(shí)現(xiàn)以下幾點(diǎn)：
擴(kuò)容智能評(píng)估：根據(jù)集群負(fù)載，把是否需要擴(kuò)容評(píng)估程序化熊咽、智能化燃辖；
智能擴(kuò)容：當(dāng)評(píng)估需要擴(kuò)容后，把擴(kuò)容流程以及流量均衡平臺(tái)化网棍。
1.7.3 broker下線
某些場(chǎng)景下黔龟，我們需要下線我們的broker，主要包括以下幾個(gè)場(chǎng)景：
一些老化的服務(wù)器需要下線滥玷，實(shí)現(xiàn)節(jié)點(diǎn)下線平臺(tái)化氏身；
服務(wù)器故障，broker故障無(wú)法恢復(fù)惑畴，我們需要下線故障服務(wù)器蛋欣，實(shí)現(xiàn)節(jié)點(diǎn)下線平臺(tái)化；
有更優(yōu)配置的服務(wù)器替換已有broker節(jié)點(diǎn)如贷，實(shí)現(xiàn)下線節(jié)點(diǎn)平臺(tái)化陷虎。
1.8 負(fù)載均衡
我們?yōu)槭裁葱枰?fù)載均衡呢？首先杠袱，我們來(lái)看第一張圖尚猿，下圖是我們集群某個(gè)資源組剛擴(kuò)容后的流量分布情況，流量無(wú)法自動(dòng)的分?jǐn)偟轿覀冃聰U(kuò)容后的節(jié)點(diǎn)上楣富。那么這個(gè)時(shí)候需要我們手動(dòng)去觸發(fā)數(shù)據(jù)遷移凿掂，把部分副本遷移至新節(jié)點(diǎn)上才能實(shí)現(xiàn)流量均衡。
下面纹蝴，我們來(lái)看一下第二張圖庄萎。這張圖我們可以看出流量分布非常不均衡，最低和最高流量偏差數(shù)倍以上塘安。這和Kafka的架構(gòu)特點(diǎn)有關(guān)糠涛，當(dāng)集群規(guī)模與數(shù)據(jù)量達(dá)到一定量后，必然出現(xiàn)當(dāng)問(wèn)題兼犯。這種情況下忍捡，我們也需要進(jìn)行負(fù)載均衡集漾。
我們?cè)賮?lái)看看第三張圖。這里我們可以看出出流量只有部分節(jié)點(diǎn)突增锉罐，這就是topic分區(qū)在集群內(nèi)部不夠分散，集中分布到了某幾個(gè)broker導(dǎo)致绕娘，這種情況我們也需要進(jìn)行擴(kuò)容分區(qū)和均衡脓规。
我們比較理想的流量分布應(yīng)該如下圖所示，各節(jié)點(diǎn)間流量偏差非常小险领，這種情況下侨舆，既可以增強(qiáng)集群扛住流量異常突增的能力又可以提升集群整體資源利用率和服務(wù)穩(wěn)定性，降低成本绢陌。
負(fù)載均衡我們需要實(shí)現(xiàn)以下效果：
1）生成副本遷移計(jì)劃以及執(zhí)行遷移任務(wù)平臺(tái)化挨下、自動(dòng)化、智能化脐湾；
2）執(zhí)行均衡后broker間流量比較均勻臭笆，且單個(gè)topic分區(qū)均勻分布在所有broker節(jié)點(diǎn)上；
3）執(zhí)行均衡后broker內(nèi)部多塊磁盤間流量比較均衡秤掌；
要實(shí)現(xiàn)這個(gè)效果愁铺，我們需要開(kāi)發(fā)一套自己的負(fù)載均衡工具，如對(duì)開(kāi)源的 cruise control進(jìn)行二次開(kāi)發(fā)闻鉴；此工具的核心主要在生成遷移計(jì)劃的策略茵乱，遷移計(jì)劃的生成方案直接影響到最后集群負(fù)載均衡的效果。參考內(nèi)容：
cruise control架構(gòu)圖如下：
在生成遷移計(jì)劃時(shí)孟岛，我們需要考慮以下幾點(diǎn)：
1）選擇核心指標(biāo)作為生成遷移計(jì)劃的依據(jù)瓶竭，比如出流量、入流量渠羞、機(jī)架斤贰、單topic分區(qū)分散性等；
2）優(yōu)化用來(lái)生成遷移計(jì)劃的指標(biāo)樣本次询，比如過(guò)濾流量突增/突降/掉零等異常樣本腋舌；
3）各資源組的遷移計(jì)劃需要使用的樣本全部為資源組內(nèi)部樣本，不涉及其他資源組渗蟹，無(wú)交叉块饺；
4）治理單分區(qū)過(guò)大topic，讓topic分區(qū)分布更分散雌芽，流量不集中在部分broker授艰，讓topic單分區(qū)數(shù)據(jù)量更小，這樣可以減少遷移的數(shù)據(jù)量世落，提升遷移速度淮腾；
5）已經(jīng)均勻分散在資源組內(nèi)的topic，加入遷移黑名單，不做遷移谷朝，這樣可以減少遷移的數(shù)據(jù)量洲押，提升遷移速度；
6）做topic治理圆凰，排除長(zhǎng)期無(wú)流量topic對(duì)均衡的干擾杈帐；
7）新建topic或者topic分區(qū)擴(kuò)容時(shí)，應(yīng)讓所有分區(qū)輪詢分布在所有broker節(jié)點(diǎn)专钉，輪詢后余數(shù)分區(qū)優(yōu)先分布流量較低的broker挑童；
8）擴(kuò)容broker節(jié)點(diǎn)后開(kāi)啟負(fù)載均衡時(shí)，優(yōu)先把同一broker分配了同一大流量（流量大而不是存儲(chǔ)空間大跃须，這里可以認(rèn)為是每秒的吞吐量）topic多個(gè)分區(qū)leader的站叼，遷移一部分到新broker節(jié)點(diǎn)；
9）提交遷移任務(wù)時(shí)菇民，同一批遷移計(jì)劃中的分區(qū)數(shù)據(jù)大小偏差應(yīng)該盡可能小尽楔，這樣可以避免遷移任務(wù)中小分區(qū)遷移完成后長(zhǎng)時(shí)間等待大分區(qū)的遷移，造成任務(wù)傾斜第练；
1.9 安全認(rèn)證
是不是我們的集群所有人都可以隨意訪問(wèn)呢翔试？當(dāng)然不是，為了集群的安全复旬，我們需要進(jìn)行權(quán)限認(rèn)證垦缅，屏蔽非法操作。主要包括以下幾個(gè)方面需要做安全認(rèn)證：
(1)生產(chǎn)者權(quán)限認(rèn)證驹碍；
(2)消費(fèi)者權(quán)限認(rèn)證壁涎；
(3)指定數(shù)據(jù)目錄遷移安全認(rèn)證；
官網(wǎng)地址：http://kafka.apache.org
1.10 集群容災(zāi)
跨機(jī)架容災(zāi)：
官網(wǎng)地址：http://kafka.apache.org
跨集群/機(jī)房容災(zāi)：如果有異地雙活等業(yè)務(wù)場(chǎng)景時(shí)志秃，可以參考Kafka2.7版本的MirrorMaker 2.0怔球。
GitHub地址：https://github.com
精確KIP地址 ：https://cwiki.apache.org
ZooKeeper集群上Kafka元數(shù)據(jù)恢復(fù)：我們會(huì)定期對(duì)ZooKeeper上的權(quán)限信息數(shù)據(jù)做備份處理，當(dāng)集群元數(shù)據(jù)異常時(shí)用于恢復(fù)浮还。
1.11 參數(shù)/配置優(yōu)化
broker服務(wù)參數(shù)優(yōu)化：這里我只列舉部分影響性能的核心參數(shù)竟坛。
num.network.threads
#創(chuàng)建Processor處理網(wǎng)絡(luò)請(qǐng)求線程個(gè)數(shù)，建議設(shè)置為broker當(dāng)CPU核心數(shù)*2钧舌，這個(gè)值太低經(jīng)常出現(xiàn)網(wǎng)絡(luò)空閑太低而缺失副本担汤。
num.io.threads
#創(chuàng)建KafkaRequestHandler處理具體請(qǐng)求線程個(gè)數(shù)，建議設(shè)置為broker磁盤個(gè)數(shù)*2
num.replica.fetchers
#建議設(shè)置為CPU核心數(shù)/4洼冻，適當(dāng)提高可以提升CPU利用率及follower同步leader數(shù)據(jù)當(dāng)并行度崭歧。
compression.type
#建議采用lz4壓縮類型，壓縮可以提升CPU利用率同時(shí)可以減少網(wǎng)絡(luò)傳輸數(shù)據(jù)量撞牢。
queued.max.requests
#如果是生產(chǎn)環(huán)境率碾，建議配置最少500以上叔营，默認(rèn)為500。
log.flush.scheduler.interval.ms
log.flush.interval.ms
log.flush.interval.messages
#這幾個(gè)參數(shù)表示日志數(shù)據(jù)刷新到磁盤的策略所宰，應(yīng)該保持默認(rèn)配置绒尊，刷盤策略讓操作系統(tǒng)去完成，由操作系統(tǒng)來(lái)決定什么時(shí)候把數(shù)據(jù)刷盤仔粥；
#如果設(shè)置來(lái)這個(gè)參數(shù)婴谱，可能對(duì)吞吐量影響非常大；
auto.leader.rebalance.enable
#表示是否開(kāi)啟leader自動(dòng)負(fù)載均衡件炉，默認(rèn)true勘究；我們應(yīng)該把這個(gè)參數(shù)設(shè)置為false矮湘，因?yàn)樽詣?dòng)負(fù)載均衡不可控斟冕，可能影響集群性能和穩(wěn)定；
生產(chǎn)優(yōu)化：這里我只列舉部分影響性能的核心參數(shù)缅阳。
linger.ms
#客戶端生產(chǎn)消息等待多久時(shí)間才發(fā)送到服務(wù)端磕蛇，單位：毫秒。和batch.size參數(shù)配合使用十办；適當(dāng)調(diào)大可以提升吞吐量秀撇，但是如果客戶端如果down機(jī)有丟失數(shù)據(jù)風(fēng)險(xiǎn)；
batch.size
#客戶端發(fā)送到服務(wù)端消息批次大小向族，和linger.ms參數(shù)配合使用呵燕；適當(dāng)調(diào)大可以提升吞吐量，但是如果客戶端如果down機(jī)有丟失數(shù)據(jù)風(fēng)險(xiǎn)件相；
compression.type
#建議采用lz4壓縮類型再扭，具備較高的壓縮比及吞吐量；由于Kafka對(duì)CPU的要求并不高夜矗，所以泛范，可以通過(guò)壓縮，充分利用CPU資源以提升網(wǎng)絡(luò)吞吐量紊撕；
buffer.memory
#客戶端緩沖區(qū)大小罢荡，如果topic比較大酱讶，且內(nèi)存比較充足茁彭，可以適當(dāng)調(diào)高這個(gè)參數(shù)牙甫，默認(rèn)只為33554432(32MB)
retries
#生產(chǎn)失敗后的重試次數(shù)差购，默認(rèn)0箱叁，可以適當(dāng)增加张吉。當(dāng)重試超過(guò)一定次數(shù)后仲翎，如果業(yè)務(wù)要求數(shù)據(jù)準(zhǔn)確性較高甘磨，建議做容錯(cuò)處理逞泄。
retry.backoff.ms
#生產(chǎn)失敗后患整，重試時(shí)間間隔拜效，默認(rèn)100ms，建議不要設(shè)置太大或者太小各谚。
除了一些核心參數(shù)優(yōu)化外紧憾，我們還需要考慮比如topic的分區(qū)個(gè)數(shù)和topic保留時(shí)間；如果分區(qū)個(gè)數(shù)太少昌渤，保留時(shí)間太長(zhǎng)赴穗，但是寫入數(shù)據(jù)量非常大的話，可能造成以下問(wèn)題：
1）topic分區(qū)集中落在某幾個(gè)broker節(jié)點(diǎn)上膀息，導(dǎo)致流量副本失衡般眉；
2）導(dǎo)致broker節(jié)點(diǎn)內(nèi)部某幾塊磁盤讀寫超負(fù)載，存儲(chǔ)被寫爆潜支；
1.11.1 消費(fèi)優(yōu)化
消費(fèi)最大的問(wèn)題甸赃，并且經(jīng)常出現(xiàn)的問(wèn)題就是消費(fèi)延時(shí)，拉歷史數(shù)據(jù)冗酿。當(dāng)大量拉取歷史數(shù)據(jù)時(shí)將出現(xiàn)大量讀盤操作埠对，污染pagecache，這個(gè)將加重磁盤的負(fù)載裁替，影響集群性能和穩(wěn)定项玛；
可以怎樣減少或者避免大量消費(fèi)延時(shí)呢？
1）當(dāng)topic數(shù)據(jù)量非常大時(shí)弱判，建議一個(gè)分區(qū)開(kāi)啟一個(gè)線程去消費(fèi)襟沮；
2）對(duì)topic消費(fèi)延時(shí)添加監(jiān)控告警，及時(shí)發(fā)現(xiàn)處理昌腰；
3）當(dāng)topic數(shù)據(jù)可以丟棄時(shí)开伏，遇到超大延時(shí)，比如單個(gè)分區(qū)延遲記錄超過(guò)千萬(wàn)甚至數(shù)億剥哑，那么可以重置topic的消費(fèi)點(diǎn)位進(jìn)行緊急處理硅则；【此方案一般在極端場(chǎng)景才使用】
4）避免重置topic的分區(qū)offset到很早的位置，這可能造成拉取大量歷史數(shù)據(jù)株婴；
1.11.2 Linux服務(wù)器參數(shù)優(yōu)化
我們需要對(duì)Linux的文件句柄怎虫、pagecache等參數(shù)進(jìn)行優(yōu)化±Ы椋可參考《Linux Page Cache調(diào)優(yōu)在Kafka中的應(yīng)用》大审。
1.12.硬件優(yōu)化
磁盤優(yōu)化
在條件允許的情況下，可以采用SSD固態(tài)硬盤替換HDD機(jī)械硬盤座哩，解決機(jī)械盤IO性能較低的問(wèn)題徒扶；如果沒(méi)有SSD固態(tài)硬盤，則可以對(duì)服務(wù)器上的多塊硬盤做硬RAID（一般采用RAID10）根穷，讓broker節(jié)點(diǎn)的IO負(fù)載更加均衡姜骡。如果是HDD機(jī)械硬盤导坟，一個(gè)broker可以掛載多塊硬盤，比如 12塊*4TB圈澈。
內(nèi)存
由于Kafka屬于高頻讀寫型服務(wù)惫周，而Linux的讀寫請(qǐng)求基本走的都是Page Cache，所以單節(jié)點(diǎn)內(nèi)存大一些對(duì)性能會(huì)有比較明顯的提升康栈。一般選擇256GB或者更高递递。
網(wǎng)絡(luò)
提升網(wǎng)絡(luò)帶寬：在條件允許的情況下，網(wǎng)絡(luò)帶寬越大越好啥么。因?yàn)檫@樣網(wǎng)絡(luò)帶寬才不會(huì)成為性能瓶頸登舞，最少也要達(dá)到萬(wàn)兆網(wǎng)絡(luò)（ 10Gb，網(wǎng)卡為全雙工）才能具備相對(duì)較高的吞吐量悬荣。如果是單通道菠秒，網(wǎng)絡(luò)出流量與入流量之和的上限理論值是1.25GB/s；如果是雙工雙通道隅熙，網(wǎng)絡(luò)出入流量理論值都可以達(dá)到1.25GB/s稽煤。
網(wǎng)絡(luò)隔離打標(biāo)：由于一個(gè)機(jī)房可能既部署有離線集群（比如HBase核芽、Spark囚戚、Hadoop等）又部署有實(shí)時(shí)集群（如Kafka）。那么實(shí)時(shí)集群和離線集群掛載到同一個(gè)交換機(jī)下的服務(wù)器將出現(xiàn)競(jìng)爭(zhēng)網(wǎng)絡(luò)帶寬的問(wèn)題轧简，離線集群可能對(duì)實(shí)時(shí)集群造成影響驰坊。所以我們需要進(jìn)行交換機(jī)層面的隔離，讓離線機(jī)器和實(shí)時(shí)集群不要掛載到相同的交換機(jī)下哮独。即使有掛載到相同交換機(jī)下面的拳芙，我們也將進(jìn)行網(wǎng)絡(luò)通行優(yōu)先級(jí)（金、銀皮璧、銅舟扎、鐵）標(biāo)記，當(dāng)網(wǎng)絡(luò)帶寬緊張的時(shí)候悴务，讓實(shí)時(shí)業(yè)務(wù)優(yōu)先通行睹限。
CPU
Kafka的瓶頸不在CPU，單節(jié)點(diǎn)一般有32核的CPU都足夠使用讯檐。
1.13.平臺(tái)化
現(xiàn)在問(wèn)題來(lái)了羡疗，前面我們提到很多監(jiān)控、優(yōu)化等手段别洪；難道我們管理員或者業(yè)務(wù)用戶對(duì)集群所有的操作都需要登錄集群服務(wù)器嗎叨恨？答案當(dāng)然是否定的，我們需要豐富的平臺(tái)化功能來(lái)支持挖垛。一方面是為了提升我們操作的效率痒钝，另外一方面也是為了提升集群的穩(wěn)定和降低出錯(cuò)的可能秉颗。
配置管理
黑屏操作，每次修改broker的server.properties配置文件都沒(méi)有變更記錄可追溯送矩，有時(shí)可能因?yàn)橛腥诵薷牧思号渲脤?dǎo)致一些故障站宗，卻找不到相關(guān)記錄。如果我們把配置管理做到平臺(tái)上益愈，每次變更都有跡可循梢灭，同時(shí)降低了變更出錯(cuò)的風(fēng)險(xiǎn)。
滾動(dòng)重啟
當(dāng)我們需要做線上變更時(shí)蒸其，有時(shí)候需要對(duì)集群對(duì)多個(gè)節(jié)點(diǎn)做滾動(dòng)重啟敏释，如果到命令行去操作，那效率將變得很低摸袁，而且需要人工去干預(yù)钥顽，浪費(fèi)人力。這個(gè)時(shí)候我們就需要把這種重復(fù)性的工作進(jìn)行平臺(tái)化靠汁，提升我們的操作效率蜂大。
集群管理
集群管理主要是把原來(lái)在命令行的一系列操作做到平臺(tái)上，用戶和管理員不再需要黑屏操作Kafka集群蝶怔；這樣做主要有以下優(yōu)點(diǎn)：
提升操作效率奶浦；
操作出錯(cuò)概率更小，集群更安全踢星；
所有操作有跡可循澳叉，可以追溯；
集群管理主要包括：broker管理沐悦、topic管理成洗、生產(chǎn)/消費(fèi)權(quán)限管理、用戶管理等
1.13.1 mock功能
在平臺(tái)上為用戶的topic提供生產(chǎn)樣例數(shù)據(jù)與消費(fèi)抽樣的功能藏否，用戶可以不用自己寫代碼也可以測(cè)試topic是否可以使用瓶殃，權(quán)限是否正常；
在平臺(tái)上為用戶的topic提供生產(chǎn)/消費(fèi)權(quán)限驗(yàn)證功能副签，讓用戶可以明確自己的賬號(hào)對(duì)某個(gè)topic有沒(méi)有讀寫權(quán)限遥椿；
1.13.2 權(quán)限管理
把用戶讀/寫權(quán)限管理等相關(guān)操作進(jìn)行平臺(tái)化。
1.13.3 擴(kuò)容/縮容
把broker節(jié)點(diǎn)上下線做到平臺(tái)上继薛，所有的上線和下線節(jié)點(diǎn)不再需要操作命令行修壕。
1.13.4 集群治理
1）無(wú)流量topic的治理，對(duì)集群中無(wú)流量topic進(jìn)行清理遏考，減少過(guò)多無(wú)用元數(shù)據(jù)對(duì)集群造成的壓力慈鸠；
2）topic分區(qū)數(shù)據(jù)大小治理，把topic分區(qū)數(shù)據(jù)量過(guò)大的topic（如單分區(qū)數(shù)據(jù)量超過(guò)100GB/天）進(jìn)行梳理，看看是否需要擴(kuò)容青团，避免數(shù)據(jù)集中在集群部分節(jié)點(diǎn)上譬巫；
3）topic分區(qū)數(shù)據(jù)傾斜治理，避免客戶端在生產(chǎn)消息的時(shí)候督笆，指定消息的key芦昔，但是key過(guò)于集中，消息只集中分布在部分分區(qū)娃肿，導(dǎo)致數(shù)據(jù)傾斜咕缎；
4）topic分區(qū)分散性治理，讓topic分區(qū)分布在集群盡可能多的broker上料扰，這樣可以避免因topic流量突增凭豪，流量只集中到少數(shù)節(jié)點(diǎn)上的風(fēng)險(xiǎn)，也可以避免某個(gè)broker異常對(duì)topic影響非常大晒杈；
5）topic分區(qū)消費(fèi)延時(shí)治理嫂伞；一般有延時(shí)消費(fèi)較多的時(shí)候有兩種情況，一種是集群性能下降拯钻，另外一種是業(yè)務(wù)方的消費(fèi)并發(fā)度不夠帖努，如果是消費(fèi)者并發(fā)不夠的化應(yīng)該與業(yè)務(wù)聯(lián)系增加消費(fèi)并發(fā)。
1.13.5 監(jiān)控告警
1）把所有指標(biāo)采集做成平臺(tái)可配置粪般，提供統(tǒng)一的指標(biāo)采集和指標(biāo)展示及告警平臺(tái)拼余，實(shí)現(xiàn)一體化監(jiān)控；
2）把上下游業(yè)務(wù)進(jìn)行關(guān)聯(lián)刊驴，做成全鏈路監(jiān)控姿搜；
3）用戶可以配置topic或者分區(qū)流量延時(shí)寡润、突變等監(jiān)控告警捆憎；
1.13.6 業(yè)務(wù)大屏
業(yè)務(wù)大屏主要指標(biāo)：集群個(gè)數(shù)、節(jié)點(diǎn)個(gè)數(shù)梭纹、日入流量大小躲惰、日入流量記錄、日出流量大小变抽、日出流量記錄础拨、每秒入流量大小、每秒入流量記錄绍载、每秒出流量大小诡宗、每秒出流量記錄、用戶個(gè)數(shù)击儡、生產(chǎn)延時(shí)塔沃、消費(fèi)延時(shí)、數(shù)據(jù)可靠性阳谍、服務(wù)可用性蛀柴、數(shù)據(jù)存儲(chǔ)大小螃概、資源組個(gè)數(shù)、topic個(gè)數(shù)鸽疾、分區(qū)個(gè)數(shù)吊洼、副本個(gè)數(shù)、消費(fèi)組個(gè)數(shù)等指標(biāo)制肮。
1.13.7 流量限制
把用戶流量現(xiàn)在做到平臺(tái)冒窍，在平臺(tái)進(jìn)行智能限流處理。
1.13.8 負(fù)載均衡
把自動(dòng)負(fù)載均衡功能做到平臺(tái)豺鼻，通過(guò)平臺(tái)進(jìn)行調(diào)度和管理超燃。
1.13.9 資源預(yù)算
當(dāng)集群達(dá)到一定規(guī)模，流量不斷增長(zhǎng)拘领，那么集群擴(kuò)容機(jī)器從哪里來(lái)呢意乓？業(yè)務(wù)的資源預(yù)算，讓集群里面的多個(gè)業(yè)務(wù)根據(jù)自己在集群中當(dāng)流量去分?jǐn)傉麄€(gè)集群的硬件成本约素；當(dāng)然届良，獨(dú)立集群與獨(dú)立隔離的資源組，預(yù)算方式可以單獨(dú)計(jì)算圣猎。
1.14.性能評(píng)估
1.14.1 單broker性能評(píng)估
我們做單broker性能評(píng)估的目的包括以下幾方面：
1)為我們進(jìn)行資源申請(qǐng)?jiān)u估提供依據(jù)士葫；
2)讓我們更了解集群的讀寫能力及瓶頸在哪里，針對(duì)瓶頸進(jìn)行優(yōu)化送悔；
3)為我們限流閾值設(shè)置提供依據(jù)慢显；
4)為我們?cè)u(píng)估什么時(shí)候應(yīng)該擴(kuò)容提供依據(jù)；
1.14.2 topic分區(qū)性能評(píng)估
1)為我們創(chuàng)建topic時(shí)欠啤，評(píng)估應(yīng)該指定多少分區(qū)合理提供依據(jù)荚藻；
2)為我們topic的分區(qū)擴(kuò)容評(píng)估提供依據(jù)；
1.14.3 單磁盤性能評(píng)估
1)為我們了解磁盤的真正讀寫能力洁段，為我們選擇更合適Kafka的磁盤類型提供依據(jù)应狱；
2)為我們做磁盤流量告警閾值設(shè)置提供依據(jù)；
1.14.4 集群規(guī)模限制摸底
1）我們需要了解單個(gè)集群規(guī)模的上限或者是元數(shù)據(jù)規(guī)模的上限祠丝，探索相關(guān)信息對(duì)集群性能和穩(wěn)定性的影響疾呻；
2）根據(jù)摸底情況，評(píng)估集群節(jié)點(diǎn)規(guī)模的合理范圍写半，及時(shí)預(yù)測(cè)風(fēng)險(xiǎn)岸蜗，進(jìn)行超大集群的拆分等工作；
1.15 DNS+LVS的網(wǎng)絡(luò)架構(gòu)
當(dāng)我們的集群節(jié)點(diǎn)達(dá)到一定規(guī)模叠蝇，比如單集群數(shù)百個(gè)broker節(jié)點(diǎn)璃岳，那么此時(shí)我們生產(chǎn)消費(fèi)客戶端指定bootstrap.servers配置時(shí)，如果指定呢？是隨便選擇其中幾個(gè)broker配置還是全部都配上呢矾睦？
其實(shí)以上做法都不合適晦款，如果只配置幾個(gè)IP，當(dāng)我們配置當(dāng)幾個(gè)broker節(jié)點(diǎn)下線后枚冗，我們當(dāng)應(yīng)用將無(wú)法連接到Kafka集群缓溅；如果配置所有IP，那更不現(xiàn)實(shí)啦赁温，幾百個(gè)IP坛怪，那么我們應(yīng)該怎么做呢？
方案：采用DNS+LVS網(wǎng)絡(luò)架構(gòu)股囊，最終生產(chǎn)者和消費(fèi)者客戶端只需要配置域名就可以啦袜匿。需要注意的是，有新節(jié)點(diǎn)加入集群時(shí)稚疹，需要添加映射居灯；有節(jié)點(diǎn)下線時(shí)，需要從映射中踢掉内狗，否則這批機(jī)器如果拿到其他的地方去使用怪嫌，如果端口和Kafka的一樣的話，原來(lái)集群部分請(qǐng)求將發(fā)送到這個(gè)已經(jīng)下線的服務(wù)器上來(lái)柳沙，造成生產(chǎn)環(huán)境重點(diǎn)故障岩灭。
二、開(kāi)源版本功能缺陷
RTMP協(xié)議主要的特點(diǎn)有：多路復(fù)用赂鲤，分包和應(yīng)用層協(xié)議噪径。以下將對(duì)這些特點(diǎn)進(jìn)行詳細(xì)的描述。
2.1 副本遷移
無(wú)法實(shí)現(xiàn)增量遷移数初；【我們已經(jīng)基于2.1.1版本源碼改造找爱，實(shí)現(xiàn)了增量遷移】
無(wú)法實(shí)現(xiàn)并發(fā)遷移；【開(kāi)源版本直到2.6.0才實(shí)現(xiàn)了并發(fā)遷移】
無(wú)法實(shí)現(xiàn)終止遷移妙真；【我們已經(jīng)基于2.1.1版本源碼改造缴允，實(shí)現(xiàn)了終止副本遷移】【開(kāi)源版本直到2.6.0才實(shí)現(xiàn)了暫停遷移，和終止遷移有些不一樣珍德，不會(huì)回滾元數(shù)據(jù)】
當(dāng)指定遷移數(shù)據(jù)目錄時(shí)，遷移過(guò)程中矗漾，如果把topic保留時(shí)間改短锈候，topic保留時(shí)間針對(duì)正在遷移topic分區(qū)不生效，topic分區(qū)過(guò)期數(shù)據(jù)無(wú)法刪除敞贡；【開(kāi)源版本bug泵琳，目前還沒(méi)有修復(fù)】
當(dāng)指定遷移數(shù)據(jù)目錄時(shí)，當(dāng)遷移計(jì)劃為以下場(chǎng)景時(shí)，整個(gè)遷移任務(wù)無(wú)法完成遷移获列，一直處于卡死狀態(tài)谷市；【開(kāi)源版本bug，目前還沒(méi)有修復(fù)】
遷移過(guò)程中击孩，如果有重啟broker節(jié)點(diǎn)迫悠，那個(gè)broker節(jié)點(diǎn)上的所有l(wèi)eader分區(qū)無(wú)法切換回來(lái)，導(dǎo)致節(jié)點(diǎn)流量全部轉(zhuǎn)移到其他節(jié)點(diǎn)巩梢，直到所有副本被遷移完畢后leader才會(huì)切換回來(lái)创泄；【開(kāi)源版本bug，目前還沒(méi)有修復(fù)】括蝠。
在原生的Kafka版本中存在以下指定數(shù)據(jù)目錄場(chǎng)景無(wú)法遷移完畢的情況鞠抑，此版本我們也不決定修復(fù)次bug：
1.針對(duì)同一個(gè)topic分區(qū)，如果部分目標(biāo)副本相比原副本是所屬broker發(fā)生變化忌警，部分目標(biāo)副本相比原副本是broker內(nèi)部所屬數(shù)據(jù)目錄發(fā)生變化搁拙；
那么副本所屬broker發(fā)生變化的那個(gè)目標(biāo)副本可以正常遷移完畢，目標(biāo)副本是在broker內(nèi)部數(shù)據(jù)目錄發(fā)生變化的無(wú)法正常完成遷移法绵；
但是舊副本依然可以正常提供生產(chǎn)感混、消費(fèi)服務(wù)，并且不影響下一次遷移任務(wù)的提交礼烈，下一次遷移任務(wù)只需要把此topic分區(qū)的副本列表所屬broker列表變更后提交依然可以正常完成遷移弧满，并且可以清理掉之前未完成的目標(biāo)副本；
這里假設(shè)topic yyj1的初始化副本分布情況如下：
{
"version":1,
"partitions":[
{"topic":"yyj","partition":0,"replicas":[1000003,1000001],"log_dirs":["/kfk211data/data31","/kfk211data/data13"]}
]
}
//遷移場(chǎng)景1：
{
"version":1,
"partitions":[
{"topic":"yyj","partition":0,"replicas":[1000003,1000002],"log_dirs":["/kfk211data/data32","/kfk211data/data23"]}
]
}
//遷移場(chǎng)景2：
{
"version":1,
"partitions":[
{"topic":"yyj","partition":0,"replicas":[1000002,1000001],"log_dirs":["/kfk211data/data22","/kfk211data/data13"]}
]
}
針對(duì)上述的topic yyj1的分布分布情況此熬，此時(shí)如果我們的遷移計(jì)劃為“遷移場(chǎng)景1”或遷移場(chǎng)景2“庭呜，那么都將出現(xiàn)有副本無(wú)法遷移完畢的情況。
但是這并不影響舊副本處理生產(chǎn)犀忱、消費(fèi)請(qǐng)求募谎，并且我們可以正常提交其他的遷移任務(wù)。
為了清理舊的未遷移完成的副本阴汇，我們只需要修改一次遷移計(jì)劃【新的目標(biāo)副本列表和當(dāng)前分區(qū)已分配副本列表完全不同即可】数冬，再次提交遷移即可。
這里搀庶，我們依然以上述的例子做遷移計(jì)劃修改如下：
{
"version":1,
"partitions":[
{"topic":"yyj","partition":0,"replicas":[1000004,1000005],"log_dirs":["/kfk211data/data42","/kfk211data/data53"]}
]
}
這樣我們就可以正常完成遷移拐纱。
2.2 流量協(xié)議
限流粒度較粗，不夠靈活精準(zhǔn)哥倔，不夠智能秸架。
當(dāng)前限流維度組合
/config/users/<user>/clients/<client-id>
/config/users/<user>/clients/<default>
/config/users/<user>
/config/users/<default>/clients/<client-id>
/config/users/<default>/clients/<default>
/config/users/<default>
/config/clients/<client-id>
/config/clients/<default>
存在問(wèn)題
當(dāng)同一個(gè)broker上有多個(gè)用戶同時(shí)進(jìn)行大量的生產(chǎn)和消費(fèi)時(shí)，想要讓broker可以正常運(yùn)行咆蒿，那必須在做限流時(shí)讓所有的用戶流量閾值之和不超過(guò)broker的吞吐上限东抹；如果超過(guò)broker上限蚂子，那么broker就存在被打掛的風(fēng)險(xiǎn)；然而缭黔，即使用戶流量沒(méi)有達(dá)到broker的流量上限食茎，但是，如果所有用戶流量集中到了某幾塊盤上馏谨，超過(guò)了磁盤的讀寫負(fù)載别渔，也會(huì)導(dǎo)致所有生產(chǎn)、消費(fèi)請(qǐng)求將被阻塞田巴，broker可能處于假死狀態(tài)钠糊。
解決方案
(1)改造源碼，實(shí)現(xiàn)單個(gè)broker流量上限限制壹哺，只要流量達(dá)到broker上限立即進(jìn)行限流處理抄伍，所有往這個(gè)broker寫的用戶都可以被限制住管宵；或者對(duì)用戶進(jìn)行優(yōu)先級(jí)處理截珍，放過(guò)高優(yōu)先級(jí)的，限制低優(yōu)先級(jí)的箩朴；
(2)改造源碼岗喉，實(shí)現(xiàn)broker上單塊磁盤流量上限限制（很多時(shí)候都是流量集中到某幾塊磁盤上，導(dǎo)致沒(méi)有達(dá)到broker流量上限卻超過(guò)了單磁盤讀寫能力上限）炸庞，只要磁盤流量達(dá)到上限，立即進(jìn)行限流處理埠居，所有往這個(gè)磁盤寫的用戶都可以被限制桌暮尽纸颜；或者對(duì)用戶進(jìn)行優(yōu)先級(jí)處理，放過(guò)高優(yōu)先級(jí)的胁孙，限制低優(yōu)先級(jí)的称鳞；
(3)改造源碼涮较，實(shí)現(xiàn)topic維度限流以及對(duì)topic分區(qū)的禁寫功能；
(4)改造源碼法希，實(shí)現(xiàn)用戶靶瘸、broker、磁盤屋剑、topic等維度組合精準(zhǔn)限流诗眨；
三、kafka發(fā)展趨勢(shì)
3.3 controller與broker分離巍膘，引入raft協(xié)議作為controller的仲裁機(jī)制（KIP-630）
3.7 下載與各版本特性說(shuō)明
3.8 Kafka所有KIP地址
四峡懈、如何貢獻(xiàn)社區(qū)
4.1 哪些點(diǎn)可以貢獻(xiàn)
http://kafka.apache.org/contributing
4.2 wiki貢獻(xiàn)地址
https://cwiki.apache.org/confluence/dashboard.action#all-updates
4.3 issues地址
1）https://issues.apache.org/jira/projects/KAFKA/issues/KAFKA-10444?filter=allopenissues
2）https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=all
4.4 主要committers
http://kafka.apache.org/committers
作者：vivo互聯(lián)網(wǎng)服務(wù)器團(tuán)隊(duì)-Yang Yijun
