Kafka史上最詳細(xì)原理總結(jié)分為上下兩部分，承上啟下

Kafka史上最詳細(xì)原理總結(jié)上

Kafka史上最詳細(xì)原理總結(jié)下

本篇為Kafka史上最詳細(xì)原理總結(jié)下讯泣，承接Kafka史上最詳細(xì)原理總結(jié)上

3.Partition Replication原則

Kafka高效文件存儲(chǔ)設(shè)計(jì)特點(diǎn)

• Kafka把topic中一個(gè)parition大文件分成多個(gè)小文件段纫普，通過(guò)多個(gè)小文件段，就容易定期清除或刪除已經(jīng)消費(fèi)完文件，減少磁盤占用昨稼。
• 通過(guò)索引信息可以快速定位message和確定response的最大大小。
• 通過(guò)index元數(shù)據(jù)全部映射到memory，可以避免segment file的IO磁盤操作。
• 通過(guò)索引文件稀疏存儲(chǔ)举娩，可以大幅降低index文件元數(shù)據(jù)占用空間大小芙代。

1. Kafka集群partition replication默認(rèn)自動(dòng)分配分析

下面以一個(gè)Kafka集群中4個(gè)Broker舉例谬泌，創(chuàng)建1個(gè)topic包含4個(gè)Partition，2 Replication；數(shù)據(jù)Producer流動(dòng)如圖所示：

(1)

image

(2)當(dāng)集群中新增2節(jié)點(diǎn)父丰，Partition增加到6個(gè)時(shí)分布情況如下：

image

副本分配邏輯規(guī)則如下：

• 在Kafka集群中坟漱，每個(gè)Broker都有均等分配Partition的Leader機(jī)會(huì)沟突。
• 上述圖Broker Partition中庸论，箭頭指向?yàn)楦北荆訮artition-0為例:broker1中parition-0為L(zhǎng)eader秀鞭，Broker2中Partition-0為副本豆巨。
• 上述圖種每個(gè)Broker(按照BrokerId有序)依次分配主Partition,下一個(gè)Broker為副本萍膛，如此循環(huán)迭代分配，多副本都遵循此規(guī)則。

副本分配算法如下：

• 將所有N Broker和待分配的i個(gè)Partition排序.
• 將第i個(gè)Partition分配到第(i mod n)個(gè)Broker上.
• 將第i個(gè)Partition的第j個(gè)副本分配到第((i + j) mod n)個(gè)Broker上.

4.Kafka Broker一些特性

4.1 無(wú)狀態(tài)的Kafka Broker :

1. Broker沒(méi)有副本機(jī)制吸祟，一旦broker宕機(jī)过吻，該broker的消息將都不可用逼纸。

2. Broker不保存訂閱者的狀態(tài)，由訂閱者自己保存滓鸠。

3. 無(wú)狀態(tài)導(dǎo)致消息的刪除成為難題（可能刪除的消息正在被訂閱），kafka采用基于時(shí)間的SLA(服務(wù)水平保證)渔工，消息保存一定時(shí)間（通常為7天）后會(huì)被刪除氛谜。

4. 消息訂閱者可以rewind back到任意位置重新進(jìn)行消費(fèi)酱塔，當(dāng)訂閱者故障時(shí)捌蚊，可以選擇最小的offset進(jìn)行重新讀取消費(fèi)消息。

4.2 message的交付與生命周期 ：

1. 不是嚴(yán)格的JMS髓窜， 因此kafka對(duì)消息的重復(fù)、丟失崖媚、錯(cuò)誤以及順序型沒(méi)有嚴(yán)格的要求敢课。（這是與AMQ最大的區(qū)別）

2. kafka提供at-least-once delivery,即當(dāng)consumer宕機(jī)后圾结，有些消息可能會(huì)被重復(fù)delivery抵恋。

3. 因每個(gè)partition只會(huì)被consumer group內(nèi)的一個(gè)consumer消費(fèi)，故kafka保證每個(gè)partition內(nèi)的消息會(huì)被順序的訂閱墙歪。

4. Kafka為每條消息為每條消息計(jì)算CRC校驗(yàn)猫胁，用于錯(cuò)誤檢測(cè)，crc校驗(yàn)不通過(guò)的消息會(huì)直接被丟棄掉郑藏。

4.3 壓縮

Kafka支持以集合（batch）為單位發(fā)送消息，在此基礎(chǔ)上，Kafka還支持對(duì)消息集合進(jìn)行壓縮嬉探，Producer端可以通過(guò)GZIP或Snappy格式對(duì)消息集合進(jìn)行壓縮。Producer端進(jìn)行壓縮之后芹敌，在Consumer端需進(jìn)行解壓辞嗡。壓縮的好處就是減少傳輸?shù)臄?shù)據(jù)量买窟，減輕對(duì)網(wǎng)絡(luò)傳輸?shù)膲毫σ耆矗趯?duì)大數(shù)據(jù)處理上柔昼，瓶頸往往體現(xiàn)在網(wǎng)絡(luò)上而不是CPU。

那么如何區(qū)分消息是壓縮的還是未壓縮的呢炎辨，Kafka在消息頭部添加了一個(gè)描述壓縮屬性字節(jié)捕透，這個(gè)字節(jié)的后兩位表示消息的壓縮采用的編碼，如果后兩位為0碴萧，則表示消息未被壓縮乙嘀。

4.4 消息可靠性

在消息系統(tǒng)中，保證消息在生產(chǎn)和消費(fèi)過(guò)程中的可靠性是十分重要的破喻，在實(shí)際消息傳遞過(guò)程中虎谢，可能會(huì)出現(xiàn)如下三中情況：

• 一個(gè)消息發(fā)送失敗

• 一個(gè)消息被發(fā)送多次

• 最理想的情況：exactly-once ,一個(gè)消息發(fā)送成功且僅發(fā)送了一次

有許多系統(tǒng)聲稱它們實(shí)現(xiàn)了exactly-once，但是它們其實(shí)忽略了生產(chǎn)者或消費(fèi)者在生產(chǎn)和消費(fèi)過(guò)程中有可能失敗的情況曹质。比如雖然一個(gè)Producer成功發(fā)送一個(gè)消息婴噩，但是消息在發(fā)送途中丟失，或者成功發(fā)送到broker羽德，也被consumer成功取走几莽，但是這個(gè)consumer在處理取過(guò)來(lái)的消息時(shí)失敗了。

從Producer端看：Kafka是這么處理的宅静，當(dāng)一個(gè)消息被發(fā)送后章蚣，Producer會(huì)等待broker成功接收到消息的反饋（可通過(guò)參數(shù)控制等待時(shí)間），如果消息在途中丟失或是其中一個(gè)broker掛掉姨夹，Producer會(huì)重新發(fā)送（我們知道Kafka有備份機(jī)制纤垂，可以通過(guò)參數(shù)控制是否等待所有備份節(jié)點(diǎn)都收到消息）矾策。

從Consumer端看：前面講到過(guò)partition，broker端記錄了partition中的一個(gè)offset值洒忧，這個(gè)值指向Consumer下一個(gè)即將消費(fèi)message蝴韭。當(dāng)Consumer收到了消息，但卻在處理過(guò)程中掛掉熙侍，此時(shí)Consumer可以通過(guò)這個(gè)offset值重新找到上一個(gè)消息再進(jìn)行處理榄鉴。Consumer還有權(quán)限控制這個(gè)offset值，對(duì)持久化到broker端的消息做任意處理蛉抓。

4.5 備份機(jī)制

備份機(jī)制是Kafka0.8版本的新特性庆尘，備份機(jī)制的出現(xiàn)大大提高了Kafka集群的可靠性、穩(wěn)定性巷送。有了備份機(jī)制后驶忌，Kafka允許集群中的節(jié)點(diǎn)掛掉后而不影響整個(gè)集群工作。一個(gè)備份數(shù)量為n的集群允許n-1個(gè)節(jié)點(diǎn)失敗笑跛。在所有備份節(jié)點(diǎn)中付魔，有一個(gè)節(jié)點(diǎn)作為lead節(jié)點(diǎn)，這個(gè)節(jié)點(diǎn)保存了其它備份節(jié)點(diǎn)列表飞蹂，并維持各個(gè)備份間的狀體同步几苍。下面這幅圖解釋了Kafka的備份機(jī)制:

image

4.6 Kafka高效性相關(guān)設(shè)計(jì)

4.6.1 消息的持久化

Kafka高度依賴文件系統(tǒng)來(lái)存儲(chǔ)和緩存消息(AMQ的nessage是持久化到mysql數(shù)據(jù)庫(kù)中的)，因?yàn)橐话愕娜苏J(rèn)為磁盤是緩慢的陈哑，這導(dǎo)致人們對(duì)持久化結(jié)構(gòu)具有競(jìng)爭(zhēng)性持懷疑態(tài)度妻坝。其實(shí)，磁盤的快或者慢惊窖，這決定于我們?nèi)绾问褂么疟P刽宪。因?yàn)榇疟P線性寫(xiě)的速度遠(yuǎn)遠(yuǎn)大于隨機(jī)寫(xiě)。線性讀寫(xiě)在大多數(shù)應(yīng)用場(chǎng)景下是可以預(yù)測(cè)的界酒。

4.6.2 常數(shù)時(shí)間性能保證

每個(gè)Topic的Partition的是一個(gè)大文件夾圣拄，里面有無(wú)數(shù)個(gè)小文件夾segment，但partition是一個(gè)隊(duì)列毁欣，隊(duì)列中的元素是segment,消費(fèi)的時(shí)候先從第0個(gè)segment開(kāi)始消費(fèi)售担，新來(lái)message存在最后一個(gè)消息隊(duì)列中。對(duì)于segment也是對(duì)隊(duì)列署辉，隊(duì)列元素是message,有對(duì)應(yīng)的offsite標(biāo)識(shí)是哪個(gè)message。消費(fèi)的時(shí)候先從這個(gè)segment的第一個(gè)message開(kāi)始消費(fèi)岩四，新來(lái)的message存在segment的最后哭尝。

消息系統(tǒng)的持久化隊(duì)列可以構(gòu)建在對(duì)一個(gè)文件的讀和追加上，就像一般情況下的日志解決方案剖煌。它有一個(gè)優(yōu)點(diǎn)材鹦，所有的操作都是常數(shù)時(shí)間，并且讀寫(xiě)之間不會(huì)相互阻塞桶唐。這種設(shè)計(jì)具有極大的性能優(yōu)勢(shì)：最終系統(tǒng)性能和數(shù)據(jù)大小完全無(wú)關(guān)，服務(wù)器可以充分利用廉價(jià)的硬盤來(lái)提供高效的消息服務(wù)尤泽。

事實(shí)上還有一點(diǎn)，磁盤空間的無(wú)限增大而不影響性能這點(diǎn)坯约，意味著我們可以提供一般消息系統(tǒng)無(wú)法提供的特性熊咽。比如說(shuō)闹丐，消息被消費(fèi)后不是立馬被刪除横殴，我們可以將這些消息保留一段相對(duì)比較長(zhǎng)的時(shí)間（比如一個(gè)星期）卿拴。

5.Kafka 生產(chǎn)者-消費(fèi)者

 消息系統(tǒng)通常都會(huì)由生產(chǎn)者衫仑，消費(fèi)者，Broker三大部分組成堕花，生產(chǎn)者會(huì)將消息寫(xiě)入到Broker，消費(fèi)者會(huì)從Broker中讀取出消息航徙，不同的MQ實(shí)現(xiàn)的Broker實(shí)現(xiàn)會(huì)有所不同，不過(guò)Broker的本質(zhì)都是要負(fù)責(zé)將消息落地到服務(wù)端的存儲(chǔ)系統(tǒng)中到踏。具體步驟如下：

1. 生產(chǎn)者客戶端應(yīng)用程序產(chǎn)生消息：

   1. 客戶端連接對(duì)象將消息包裝到請(qǐng)求中發(fā)送到服務(wù)端

   2. 服務(wù)端的入口也有一個(gè)連接對(duì)象負(fù)責(zé)接收請(qǐng)求，并將消息以文件的形式存儲(chǔ)起來(lái)

   3. 服務(wù)端返回響應(yīng)結(jié)果給生產(chǎn)者客戶端

2. 消費(fèi)者客戶端應(yīng)用程序消費(fèi)消息：

   1. 客戶端連接對(duì)象將消費(fèi)信息也包裝到請(qǐng)求中發(fā)送給服務(wù)端

   2. 服務(wù)端從文件存儲(chǔ)系統(tǒng)中取出消息

   3. 服務(wù)端返回響應(yīng)結(jié)果給消費(fèi)者客戶端

   4. 客戶端將響應(yīng)結(jié)果還原成消息并開(kāi)始處理消息

                                                                        圖4-1 客戶端和服務(wù)端交互
      

5.1 Producers

Producers直接發(fā)送消息到broker上的leader partition楣富，不需要經(jīng)過(guò)任何中介或其他路由轉(zhuǎn)發(fā)伴榔。為了實(shí)現(xiàn)這個(gè)特性，kafka集群中的每個(gè)broker都可以響應(yīng)producer的請(qǐng)求踪少，并返回topic的一些元信息，這些元信息包括哪些機(jī)器是存活的兼犯，topic的leader partition都在哪，現(xiàn)階段哪些leader partition是可以直接被訪問(wèn)的切黔。

Producer客戶端自己控制著消息被推送到哪些partition。實(shí)現(xiàn)的方式可以是隨機(jī)分配纬霞、實(shí)現(xiàn)一類隨機(jī)負(fù)載均衡算法，或者指定一些分區(qū)算法瞳抓。Kafka提供了接口供用戶實(shí)現(xiàn)自定義的partition绢陌，用戶可以為每個(gè)消息指定一個(gè)partitionKey挨下，通過(guò)這個(gè)key來(lái)實(shí)現(xiàn)一些hash分區(qū)算法脐湾。比如，把userid作為partitionkey的話秤掌，相同userid的消息將會(huì)被推送到同一個(gè)partition。

以Batch的方式推送數(shù)據(jù)可以極大的提高處理效率茵乱，kafka Producer 可以將消息在內(nèi)存中累計(jì)到一定數(shù)量后作為一個(gè)batch發(fā)送請(qǐng)求孟岛。Batch的數(shù)量大小可以通過(guò)Producer的參數(shù)控制，參數(shù)值可以設(shè)置為累計(jì)的消息的數(shù)量（如500條）渠羞、累計(jì)的時(shí)間間隔（如100ms）或者累計(jì)的數(shù)據(jù)大小(64KB)。通過(guò)增加batch的大小次询，可以減少網(wǎng)絡(luò)請(qǐng)求和磁盤IO的次數(shù)，當(dāng)然具體參數(shù)設(shè)置需要在效率和時(shí)效性方面做一個(gè)權(quán)衡送巡。

Producers可以異步的并行的向kafka發(fā)送消息盒卸，但是通常producer在發(fā)送完消息之后會(huì)得到一個(gè)future響應(yīng)，返回的是offset值或者發(fā)送過(guò)程中遇到的錯(cuò)誤蔽介。這其中有個(gè)非常重要的參數(shù)“acks”,這個(gè)參數(shù)決定了producer要求leader partition 收到確認(rèn)的副本個(gè)數(shù)糟需，如果acks設(shè)置數(shù)量為0谷朝，表示producer不會(huì)等待broker的響應(yīng)武花，所以圆凰，producer無(wú)法知道消息是否發(fā)送成功体箕，這樣有可能會(huì)導(dǎo)致數(shù)據(jù)丟失，但同時(shí)跃须，acks值為0會(huì)得到最大的系統(tǒng)吞吐量。

若acks設(shè)置為1菇民，表示producer會(huì)在leader partition收到消息時(shí)得到broker的一個(gè)確認(rèn)投储，這樣會(huì)有更好的可靠性，因?yàn)榭蛻舳藭?huì)等待直到broker確認(rèn)收到消息玛荞。若設(shè)置為-1，producer會(huì)在所有備份的partition收到消息時(shí)得到broker的確認(rèn)勋眯，這個(gè)設(shè)置可以得到最高的可靠性保證。

Kafka 消息有一個(gè)定長(zhǎng)的header和變長(zhǎng)的字節(jié)數(shù)組組成塞蹭。因?yàn)閗afka消息支持字節(jié)數(shù)組嚼酝，也就使得kafka可以支持任何用戶自定義的序列號(hào)格式或者其它已有的格式如Apache Avro、protobuf等闽巩。Kafka沒(méi)有限定單個(gè)消息的大小，但我們推薦消息大小不要超過(guò)1MB,通常一般消息大小都在1~10kB之前涎跨。

發(fā)布消息時(shí)，kafka client先構(gòu)造一條消息撞牢，將消息加入到消息集set中（kafka支持批量發(fā)布，可以往消息集合中添加多條消息屋彪，一次行發(fā)布），send消息時(shí)畜挥，producer client需指定消息所屬的topic。

5.2 Consumers

Kafka提供了兩套consumer api躯泰，分為high-level api和sample-api。Sample-api 是一個(gè)底層的API麦向，它維持了一個(gè)和單一broker的連接客叉，并且這個(gè)API是完全無(wú)狀態(tài)的，每次請(qǐng)求都需要指定offset值十办，因此，這套API也是最靈活的向族。

在kafka中，當(dāng)前讀到哪條消息的offset值是由consumer來(lái)維護(hù)的件相，因此，consumer可以自己決定如何讀取kafka中的數(shù)據(jù)泛范。比如，consumer可以通過(guò)重設(shè)offset值來(lái)重新消費(fèi)已消費(fèi)過(guò)的數(shù)據(jù)罢荡。不管有沒(méi)有被消費(fèi)对扶，kafka會(huì)保存數(shù)據(jù)一段時(shí)間，這個(gè)時(shí)間周期是可配置的浪南，只有到了過(guò)期時(shí)間，kafka才會(huì)刪除這些數(shù)據(jù)络凿。（這一點(diǎn)與AMQ不一樣昂羡，AMQ的message一般來(lái)說(shuō)都是持久化到mysql中的摔踱，消費(fèi)完的message會(huì)被delete掉）

High-level API封裝了對(duì)集群中一系列broker的訪問(wèn)，可以透明的消費(fèi)一個(gè)topic赴穗。它自己維持了已消費(fèi)消息的狀態(tài)，即每次消費(fèi)的都是下一個(gè)消息。

High-level API還支持以組的形式消費(fèi)topic潜支，如果consumers有同一個(gè)組名柿汛，那么kafka就相當(dāng)于一個(gè)隊(duì)列消息服務(wù)，而各個(gè)consumer均衡的消費(fèi)相應(yīng)partition中的數(shù)據(jù)络断。若consumers有不同的組名，那么此時(shí)kafka就相當(dāng)與一個(gè)廣播服務(wù)貌笨，會(huì)把topic中的所有消息廣播到每個(gè)consumer。

High level api和Low level api是針對(duì)consumer而言的昌腰，和producer無(wú)關(guān)膀跌。

High level api是consumer讀的partition的offsite是存在zookeeper上。High level api 會(huì)啟動(dòng)另外一個(gè)線程去每隔一段時(shí)間捅伤，offsite自動(dòng)同步到zookeeper上。換句話說(shuō)丛忆，如果使用了High level api， 每個(gè)message只能被讀一次座哩，一旦讀了這條message之后粮彤，無(wú)論我consumer的處理是否ok姜骡。High level api的另外一個(gè)線程會(huì)自動(dòng)的把offiste+1同步到zookeeper上屿良。如果consumer讀取數(shù)據(jù)出了問(wèn)題，offsite也會(huì)在zookeeper上同步尘惧。因此，如果consumer處理失敗了啥么，會(huì)繼續(xù)執(zhí)行下一條贰逾。這往往是不對(duì)的行為。因此疙剑，Best Practice是一旦consumer處理失敗，直接讓整個(gè)conusmer group拋Exception終止嚼蚀，但是最后讀的這一條數(shù)據(jù)是丟失了管挟，因?yàn)樵趜ookeeper里面的offsite已經(jīng)+1了。等再次啟動(dòng)conusmer group的時(shí)候哮独，已經(jīng)從下一條開(kāi)始讀取處理了。

Low level api是consumer讀的partition的offsite在consumer自己的程序中維護(hù)舟扎。不會(huì)同步到zookeeper上悴务。但是為了kafka manager能夠方便的監(jiān)控，一般也會(huì)手動(dòng)的同步到zookeeper上讯檐。這樣的好處是一旦讀取某個(gè)message的consumer失敗了，這條message的offsite我們自己維護(hù)叨恨，我們不會(huì)+1挖垛。下次再啟動(dòng)的時(shí)候秉颗，還會(huì)從這個(gè)offsite開(kāi)始讀送矩。這樣可以做到exactly once對(duì)于數(shù)據(jù)的準(zhǔn)確性有保證。

對(duì)于Consumer group：

1. 允許consumer group（包含多個(gè)consumer栋荸，如一個(gè)集群同時(shí)消費(fèi)）對(duì)一個(gè)topic進(jìn)行消費(fèi)，不同的consumer group之間獨(dú)立消費(fèi)爱沟。

2. 為了對(duì)減小一個(gè)consumer group中不同consumer之間的分布式協(xié)調(diào)開(kāi)銷匆背，指定partition為最小的并行消費(fèi)單位，即一個(gè)group內(nèi)的consumer只能消費(fèi)不同的partition。

image

Consumer與Partition的關(guān)系：

• 如果consumer比partition多闽铐，是浪費(fèi)，因?yàn)閗afka的設(shè)計(jì)是在一個(gè)partition上是不允許并發(fā)的踢星，所以consumer數(shù)不要大于partition數(shù)

• 如果consumer比partition少隙咸，一個(gè)consumer會(huì)對(duì)應(yīng)于多個(gè)partitions，這里主要合理分配consumer數(shù)和partition數(shù)五督，否則會(huì)導(dǎo)致partition里面的數(shù)據(jù)被取的不均勻

• 如果consumer從多個(gè)partition讀到數(shù)據(jù)充包，不保證數(shù)據(jù)間的順序性，kafka只保證在一個(gè)partition上數(shù)據(jù)是有序的基矮，但多個(gè)partition，根據(jù)你讀的順序會(huì)有不同

• 增減consumer本砰，broker钢悲，partition會(huì)導(dǎo)致rebalance舔株，所以rebalance后consumer對(duì)應(yīng)的partition會(huì)發(fā)生變化

• High-level接口中獲取不到數(shù)據(jù)的時(shí)候是會(huì)block的

負(fù)載低的情況下可以每個(gè)線程消費(fèi)多個(gè)partition咖楣。但負(fù)載高的情況下，Consumer 線程數(shù)最好和Partition數(shù)量保持一致诱贿。如果還是消費(fèi)不過(guò)來(lái)，應(yīng)該再開(kāi) Consumer 進(jìn)程料扰，進(jìn)程內(nèi)線程數(shù)同樣和分區(qū)數(shù)一致焙蹭。

消費(fèi)消息時(shí)，kafka client需指定topic以及partition number（每個(gè)partition對(duì)應(yīng)一個(gè)邏輯日志流孔厉，如topic代表某個(gè)產(chǎn)品線，partition代表產(chǎn)品線的日志按天切分的結(jié)果）粪般，consumer client訂閱后污桦，就可迭代讀取消息，如果沒(méi)有消息凡橱，consumer client會(huì)阻塞直到有新的消息發(fā)布。consumer可以累積確認(rèn)接收到的消息顾稀，當(dāng)其確認(rèn)了某個(gè)offset的消息变抽，意味著之前的消息也都已成功接收到，此時(shí)broker會(huì)更新zookeeper上地offset registry诡宗。

5.3 高效的數(shù)據(jù)傳輸

1. 發(fā)布者每次可發(fā)布多條消息（將消息加到一個(gè)消息集合中發(fā)布）击儡， consumer每次迭代消費(fèi)一條消息。

2. 不創(chuàng)建單獨(dú)的cache阳谍，使用系統(tǒng)的page cache螃概。發(fā)布者順序發(fā)布鸽疾，訂閱者通常比發(fā)布者滯后一點(diǎn)點(diǎn)，直接使用Linux的page cache效果也比較后冒窍，同時(shí)減少了cache管理及垃圾收集的開(kāi)銷豺鼻。

3. 使用sendfile優(yōu)化網(wǎng)絡(luò)傳輸，減少一次內(nèi)存拷貝儒飒。

6.Kafka 與 Zookeeper

6.1 Zookeeper 協(xié)調(diào)控制

1. 管理broker與consumer的動(dòng)態(tài)加入與離開(kāi)桩了。(Producer不需要管理，隨便一臺(tái)計(jì)算機(jī)都可以作為Producer向Kakfa Broker發(fā)消息)

2. 觸發(fā)負(fù)載均衡井誉，當(dāng)broker或consumer加入或離開(kāi)時(shí)會(huì)觸發(fā)負(fù)載均衡算法，使得一

   個(gè)consumer group內(nèi)的多個(gè)consumer的消費(fèi)負(fù)載平衡。（因?yàn)橐粋€(gè)comsumer消費(fèi)一個(gè)或多個(gè)partition爪模，一個(gè)partition只能被一個(gè)consumer消費(fèi)）

3. 維護(hù)消費(fèi)關(guān)系及每個(gè)partition的消費(fèi)信息。

6.2 Zookeeper上的細(xì)節(jié)：

1. 每個(gè)broker啟動(dòng)后會(huì)在zookeeper上注冊(cè)一個(gè)臨時(shí)的broker registry洁段，包含broker的ip地址和端口號(hào)共郭，所存儲(chǔ)的topics和partitions信息。

2. 每個(gè)consumer啟動(dòng)后會(huì)在zookeeper上注冊(cè)一個(gè)臨時(shí)的consumer registry：包含consumer所屬的consumer group以及訂閱的topics除嘹。

3. 每個(gè)consumer group關(guān)聯(lián)一個(gè)臨時(shí)的owner registry和一個(gè)持久的offset registry尉咕。對(duì)于被訂閱的每個(gè)partition包含一個(gè)owner registry，內(nèi)容為訂閱這個(gè)partition的consumer id年缎；同時(shí)包含一個(gè)offset registry铃慷，內(nèi)容為上一次訂閱的offset蜕该。

原文出處：

Kafka史上最詳細(xì)原理總結(jié)

Kafka史上最詳細(xì)原理總結(jié)