????????主題作為消息的歸類，可以再細(xì)分為一個或多個分區(qū)治泥，分區(qū)可以看作對消息的二級歸類暂幼。分區(qū)的劃分不僅為Kafka提供了可伸縮性筏勒、水平擴(kuò)展的功能，還通過多副本機(jī)制為Kafka提供數(shù)據(jù)冗余以提高數(shù)據(jù)可靠性旺嬉。

????????從Kafka的底層來說管行，主題和分區(qū)都是邏輯上的概念，分區(qū)可以有一到多個副本邪媳，每個副本對應(yīng)一到多個日志文件捐顷，每個日志文件對應(yīng)一到多個日志分段（LogSegment），每個日志文件可以細(xì)分為索引文件雨效、日志存儲文件和快照文件等迅涮。

1、主題的管理

1.1徽龟、創(chuàng)建主題

????????如果broker端配置參數(shù)auto.create.topics.enable配置為true（默認(rèn)值為true）叮姑，那么當(dāng)生產(chǎn)者向一個尚未創(chuàng)建的主題發(fā)送消息時，會自動創(chuàng)建一個分區(qū)數(shù)為num.partitions（默認(rèn)值為1）据悔、副本因子為default.replication.factor（默認(rèn)值為1）的主題戏溺。很多時候，這種自動創(chuàng)建主題的行為都是非預(yù)期的屠尊。除非有特殊應(yīng)用需求旷祸，否則不建議將auto.create.topics.enable設(shè)置為true。

????????更加推薦的是通過kafka-topics.sh腳本來創(chuàng)建主題讼昆。

? bin/kafka-topics.sh? --zookeeper localhost:2181/kafka? --create? --topic topic-create? --partion 4 --replication-factor 2

????????上面是創(chuàng)建分區(qū)數(shù)為4托享，副本因子是2的主題〗眨可以通過describe指令類型來查看分區(qū)副本的分配細(xì)節(jié)闰围。

????bin/kafka-topics.sh? --zookeeper localhost:2181/kafka? --describe? --topic topic-create

????????上述創(chuàng)建主題的時候，分區(qū)副本都是按照既定的內(nèi)部邏輯來進(jìn)行分配的既峡。kafka-topics.sh腳本還提供了一個replica-assignment參數(shù)來手動指定分區(qū)副本的分配方案羡榴。

????????bin/kafka-topics.sh? --zookeeper localhost:2181/kafka? --create? --topic topic-create? --replica-assignment 2:2,0:1,1:2,2:1

????????代表了主題中每個分區(qū)在broker的分配情況。

1.2运敢、分區(qū)副本的分配

????????生產(chǎn)者的分區(qū)分配是指為每條消息指定其要發(fā)往的分區(qū)校仑，消費(fèi)者的分區(qū)分配是指為消費(fèi)者指定其可以消費(fèi)消息的分區(qū)，而這里的分區(qū)分配是指為集群指定創(chuàng)建主題時的分區(qū)分配方案传惠，即在哪個broker中創(chuàng)建哪些分區(qū)的副本迄沫。

????????如果指定了replica-assignment參數(shù)，那么就按照指定的方案來進(jìn)行分區(qū)副本的創(chuàng)建卦方。如果沒有使用羊瘩，則按照內(nèi)部分配邏輯來計(jì)算分區(qū)分配方案。

1.3、修改主題

????????當(dāng)一個主題被創(chuàng)建后尘吗，依然允許我們進(jìn)行一些修改逝她，比如修改分區(qū)數(shù)量、修改配置等睬捶，都是通過alter指令完成黔宛。

????????bin/kafka-topics.sh? --zookeeper localhost:2181/kafka? --alter? --topic topic-create --partition 3

????????比如上述的修改分區(qū)數(shù)量。不過要注意的是侧戴，分區(qū)數(shù)量修改之后宁昭，如果是key強(qiáng)相關(guān)的業(yè)務(wù)會受到影響，修改分區(qū)數(shù)量要謹(jǐn)慎酗宋。

????????目前kafak只支持增加分區(qū)數(shù)量积仗，不支持減少分區(qū)數(shù)量，原因：

????????按照現(xiàn)在的代碼邏輯蜕猫，此功能完全可以實(shí)現(xiàn)寂曹，為什么不這樣做。因?yàn)閷?shí)現(xiàn)此功能需要考慮的因素太多回右。比如被刪除的分區(qū)中的消息如何處理隆圆？如果隨著分區(qū)一起消失則消息的可靠性得不到保障，如果需要保留怎么保留呢翔烁？如果直接存儲到現(xiàn)有的分區(qū)尾部渺氧，消息的時間戳就不會遞增，如此對于Spark這類需要時間戳的組建會受到影響蹬屹，如果分散插入現(xiàn)有的分區(qū)侣背，那么在消息量很大的時候，內(nèi)部的數(shù)據(jù)復(fù)制會占用很大的資源慨默，而且在復(fù)制期間贩耐，主題的可靠性怎么得到保障呢？因此厦取，這個功能的收益點(diǎn)是很低的潮太。

????????除了修改分區(qū)數(shù)，alter指令還可以修改主題的配置虾攻，比如修改max.message.bytes從10000修改到20000铡买。

????????bin/kafka-topics.sh? --zookeeper localhost:2181/kafka? --alter? --topic topic-create --config max.message.bytes=20000

2、分區(qū)的管理

????????Kafka雖然通過多副本機(jī)制來提高可靠性台谢，但是Kafka只有l(wèi)eader副本負(fù)責(zé)讀寫寻狂，follower副本只負(fù)責(zé)在內(nèi)部進(jìn)行消息的同步。也就是說朋沮，Kafka并不實(shí)現(xiàn)類似redis、數(shù)據(jù)庫等讀寫分離功能。

????????在創(chuàng)建分區(qū)的時候樊拓，分區(qū)的副本都會盡可能均勻分配到Kafka集群的各個節(jié)點(diǎn)上纠亚。對應(yīng)的leader副本分配也會比較平均。Kafka集群的一個broker中最多只能有它的一個副本筋夏。

????????隨著時間的更替蒂胞，broker不可避免的會出現(xiàn)宕機(jī)的問題，當(dāng)分區(qū)的broke節(jié)點(diǎn)發(fā)生故障的時候条篷，其中一個follower節(jié)點(diǎn)就會成為新的leader節(jié)點(diǎn)骗随，這樣會導(dǎo)致集群的負(fù)載不均衡。（比如一個broker上的leader副本會多一些赴叹，其他broker上的leader副本少一些鸿染，畢竟只有l(wèi)eader節(jié)點(diǎn)負(fù)責(zé)讀寫，有的broker節(jié)點(diǎn)就會負(fù)載高一點(diǎn)）乞巧。

????????為了能有效得治理負(fù)載失衡的情況涨椒，Kafka引進(jìn)了優(yōu)先副本的概念。比如分區(qū)0的AR集合是[1,2,0]绽媒，那么分區(qū)0的優(yōu)先副本就是broker1蚕冬。理想情況下，優(yōu)先副本就應(yīng)該是leader副本是辕。

????????所謂的優(yōu)先副本選舉就是通過一定的方式促使優(yōu)先副本選舉為leader副本囤热，以此來達(dá)到集群的負(fù)載的均衡，也叫“分區(qū)平衡”获三。但是分區(qū)平衡并不意味著Kafka 集群的負(fù)載均衡旁蔼，因?yàn)檫€要考慮到集群中的分區(qū)分配是否據(jù)哼。比如有的leader副本負(fù)載很高石窑，TPS有3000多牌芋，有的很低。

????????這里很多內(nèi)容不細(xì)究松逊。躺屁。。经宏。犀暑。。烁兰。耐亏。。沪斟。广辰。。

3、如何選擇合適的分區(qū)數(shù)

3.1择吊、性能測試工具

????????生產(chǎn)者的性能測試工具kafka-producer-perf-test.sh李根，消費(fèi)者性能測試工具kafka-consumer-perf-test.sh。

????????bin/kafka-producer-perf-test.sh --topic topic-test --num-records 100000 --record-size 1024 --throught 1 -- producer-props bootstrap.servers-localhost:9092 acks=1

????????上面就是測試生產(chǎn)者几睛。打印的數(shù)據(jù)是：

????????502 records sent, 100.3records/sec(0.10 MB/sec), 2.5ms avg latency, 266.0 max lantcy

????????501 records sent, 99.5records/sec(0.10 MB/sec), 2.5ms avg latency, 266.0 max lantcy

????????可以看到發(fā)送數(shù)據(jù)的效率房轿。

3.2、分區(qū)數(shù)越高吞吐量越高嗎

????????理論上所森，如果一個主題中的分區(qū)數(shù)越多囱持，理論上所能達(dá)到的吞吐量就越大。實(shí)際上不是這樣的焕济，會有一個閾值纷妆，超過這個閾值吞吐量反而會下降。

3.3吼蚁、分區(qū)數(shù)的上限

????????如果創(chuàng)建1萬個分區(qū)的主題凭需，你會發(fā)現(xiàn)Kafka進(jìn)程要崩潰。是內(nèi)存不足嗎肝匆，其實(shí)不是的粒蜈，這點(diǎn)內(nèi)存還不足以讓Kafka“畏懼”。

????????我們會發(fā)現(xiàn)服務(wù)日志中出現(xiàn)大量的異常： Too many open files旗国。

????????主要是受限于Linux系統(tǒng)文件描述符不足枯怖。

????????當(dāng)然可以修改系統(tǒng)的文件描述符，具體不細(xì)究能曾。

3.4度硝、考量因素

????????從吞吐量考慮，增加合適的分區(qū)數(shù)可以在一定程度上提升吞吐量寿冕，但超過對應(yīng)的閾值后吞吐量不升反降蕊程。如果對吞吐量有一定要求，則建議在投入生產(chǎn)環(huán)境之前做吞吐量相關(guān)的測試驼唱。

????????在創(chuàng)建topic之后藻茂，我們確實(shí)還可以增加分區(qū)數(shù)，但是基于key計(jì)算的主題需要謹(jǐn)慎對待玫恳。對于和key高關(guān)聯(lián)的應(yīng)用辨赐，在常見主題的時候可以適當(dāng)去多創(chuàng)建一些分區(qū)，以備長遠(yuǎn)打算京办。

????????分區(qū)數(shù)的多少還會影響系統(tǒng)的可用性掀序。分區(qū)在leader角色切換的過程中會變得不可用，不過對于單個分區(qū)來說這個過程非常短暫惭婿，但是如果集群中某個broker節(jié)點(diǎn)宕機(jī)不恭，那么就會有大量的leader角色切換叶雹，這個切換過程會消耗很大一筆時間，并且在整個時間窗口內(nèi)這些分區(qū)也會變得不可用县袱。

????????如何選擇合適的分區(qū)數(shù)浑娜？從某種意義上來說佑力，要取決于實(shí)戰(zhàn)經(jīng)驗(yàn)式散，更透徹的說，是要從Kafka本身打颤、業(yè)務(wù)使用暴拄、硬件資源等等方面綜合考慮。一般情況下编饺，根據(jù)吞吐量以及是否與key相關(guān)的規(guī)則來設(shè)定分區(qū)數(shù)即可乖篷，后期可以增加分區(qū)數(shù)、增加broker或分區(qū)重分配手段來進(jìn)行改造透且。如果有一定準(zhǔn)則撕蔼，建議將分取設(shè)定為broker數(shù)量的倍數(shù)。

4秽誊、問題

????????當(dāng)所有ISR副本都不可用時鲸沮，kafka會怎樣？unclean.leader.election.enable參數(shù)锅论，默認(rèn)為false讼溺，表示選舉leader副本是否必須從ISR中選擇，默認(rèn)是必須最易。參考文章：https://blog.csdn.net/u013256816/article/details/80790185