背景介紹

早期 Kafka 的定位是一個高吞吐的分佈式消息系統，目前則演變成了一個成熟的分佈式消息引擎，以及流處理平臺。本文主要針對Kafka的架構體系和Kafka消息的訂閱和發佈進行介紹。

1.afka-定義

Kafka是一個分佈式、數據流平臺. 具備以下基本能力:

1.發佈、訂閱消息流；

2.容錯方式存儲消息流到存儲介質；

3.處理即時消息。

2.Kafka-特點

1.解耦：

允許你獨⽴的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接⼝約束。

2.冗餘：

消息隊列把數據進⾏持久化直到它們已經被完全處理，通過這⼀⽅式規避了數據丟失⻛險。許多消息隊列所採⽤的"插⼊-獲取-刪除"範式中，在把⼀個消息從隊列中刪除之前，需要你的處理系統明確的指出該消息已經被處理完畢，從⽽確保你的數據被安全的保存直到你使⽤完畢。

3.擴展性：

因爲消息隊列解耦了你的處理過程，所以增⼤消息⼊隊和處理的頻率是很容易的，只要另外增加處理過程即可。

4.靈活性 & 峯值處理能⼒：

在訪問量劇增的情況下，應⽤仍然需要繼續發揮作⽤，但是這樣的突發流量並不常⻅。如果爲以能處理這類峯值訪問爲標準來投⼊資源隨時待命⽆疑是巨⼤的浪費。使⽤消息隊列能夠使關鍵組件頂住突發的訪問壓⼒，⽽不會因爲突發的超負荷的請求⽽完全崩潰。

5.可恢復性：

系統的⼀部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，所以即使⼀個處理消息的進程掛掉，加⼊隊列中的消息仍然可以在系統恢復後被處理。

6.順序保證：

在⼤多使⽤場景下，數據處理的順序都很重要。⼤部分消息隊列本來就是排序的，並且能保證數據會按照特定的順序來處理。（Kafka 保證⼀個 Partition 內的消息的有序性）。

7.緩衝：

有助於控制和優化數據流經過系統的速度，解決⽣產消息和消費消息的處理速度不⼀致的情況。

8.異步通信：

很多時候，⽤戶不想也不需要⽴即處理消息。消息隊列提供了異步處理機制，允許⽤戶把⼀個消息放⼊隊列，但並不⽴即處理它。想向隊列中放⼊多少消息就放多少，然後在需要的時候再去處理它們。

3. Kafka-架構圖及相關概念

Kafka發送端採用push模式將消息發送到Broker，Kafka消費端採用pull模式訂閱並消費信息。如圖3.1所示：

$ [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-72zRRExF-1591687049866)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps14.jpg)]$
圖3.1Kafka-架構圖

圖3.1大致的工作流程：Kafka集羣將 Record 流存儲在稱爲Topic的類別中，每個記錄由一個鍵、一個值和一個時間戳組成。Kafka存儲的消息來自任意多被稱爲Producer生產者的進程，Producer生產的數據會不斷追加到該log文件末端，且每條數據都有自己的Offset。數據可以被髮布到不同的Topic主題下的不同 Partition分區。在一個分區內，這些消息被索引並連同時間戳存儲在一起。被稱爲Consumer消費者的進程可以從分區訂閱消息，消費者組中的每個消費者，都會實時記錄自己消費到了哪個Offset，以便出錯恢復時，從上次的位置繼續消費。目前，Kafka依靠Zookeeper做分佈式協調服務，負責存儲和管理Kafka集羣中的元數據信息，包括集羣中的broker信息、topic信息、topic的分區與副本信息等。

4. Kafka-相關術語概念

1.producer：

消息⽣產者，發佈消息到 kafka 集羣的終端或服務。

2.broker：

kafka 集羣中安裝Kafka的服務器。

3.topic：

Topic是邏輯上的概念，每條發佈到 kafka 集羣的消息屬於的類別，即 kafka 是⾯向topic的(相當於數據庫中的表)

4.partition：

partition是物理上的概念，每個topic包含⼀個或多個 partition。kafka分配的單位是partition。

5.consumer：

從 kafka 集羣中消費消息的終端或服務。

6.Consumer group：

high-level consumer API中，每個consumer都屬於⼀個consumer group，每條消息只能被

consumer group 中的⼀個 Consumer 消費，但可以被多個consumer group消費。

7.replica：

partition的副本，保障partition的⾼可⽤。

8.leader：

replica中的⼀個⻆⾊，producer和consumer只跟leader交互。

9.follower：

replica中的⼀個⻆⾊，從 leader中複製數據。

10.zookeeper：

kafka 通過zookeeper來存儲集羣的meta信息。

offset：

偏移量，分區中的消息位置，由Kafka自身維護，Consumer消費時也要保存一份offset以維護消費過的消息位置。Kafka 0.9 版本之前，Consumer默認將Offset保存在Zookeeper中，從0.9 版本開始，Consumer默認將Offset保存在Kafka一個內置的Topic中： __consumer_offsets。

message：

消息，或稱日誌消息，是Kafka服務端實際存儲的數據，每一條消息都由一個key、一個value 以及消息時間戳timestamp組成。

5.Kafka-消息訂閱和發佈

$[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-PdF5aBet-1591687049867)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps15.jpg)]$

圖5.1 Kafka-消息訂閱和發佈圖

圖5.1是Kafka消息發佈/訂閱的基本流程圖：一對多，生產者將消息發佈到Topic中，有多個消費者訂閱該主題，發佈到Topic的消息會被所有訂閱者消費，被消費的數據不會立即從Topic清除。

5.1.Kafka 消息發送機制

Kafka 生產端發送消息的機制非常重要，這也是Kafka高吞吐的基礎，生產端的基本流程如下圖所示：

$| | || ---- | ------------------------------------------------------------ || | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ZwRn93KI-1591687050519)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps16.jpg)] |$

圖5.2 Kafka-生產端的基本流程圖

圖5.2大致過程可以概括爲：Kafka自從0.8.2版本就引入了新版本 Producer API，新版Producer完全是採用異步方式發送消息。生產端構建的 ProducerRecord先是經過keySerializer、valueSerializer序列化後，再是經過 Partition 分區器處理，決定消息落到 topic具體某個分區中，最後把消息發送到客戶端的消息緩衝池accumulator 中，交由一個叫作Sender的線程發送到broker端。

按照上圖所示的流程，消息發送機制的設計主要分爲：異步發送、批量發送和消息重試。針對這三個方面的設計有如下簡單總結：

1.緩衝池 accumulator的最大大小由參數 buffer.memory 控制，默認是32M，當生產消息的速度過快導致buffer滿了的時候，將阻塞 max.block.ms時間，超時拋異常，所以buffer的大小可以根據實際的業務情況進行適當調整。

2.發送到緩衝buffer中消息將會被分爲一個一個的batch，分批次的發送到broker端，批次大小由參數 batch.size 控制，默認16KB。一般減小 batch 大小有利於降低消息延時，增加batch大小有利於提升吞吐量。Kafka生產端提供了另一個重要參數 linger.ms，該參數控制了batch 最大的空閒時間，超過該時間的 batch 也會被髮送到 broker 端。

3.Kafka生產端支持重試機制，對於某些原因導致消息發送失敗的，比如網絡抖動，開啓重試後 Producer 會嘗試再次發送消息。該功能由參數 retries控制，參數含義代表重試次數，默認值爲0表示不重試，建議設置大於0比如3。

5.2.Kafka存儲機制

在談論存儲機制之前，我們可以瞭解一下Broker的存儲策略，無論消息是否被消費，Kafka都會保留所有消息。有兩種策略可以刪除舊數據：

\1. 基於時間：log.retention.hours=168

\2. 基於大小：log.retention.bytes=1073741824

$| | || ---- | ------------------------------------------------------------ || | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-h3DR9ngM-1591687050520)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps17.jpg)] |$

圖5.3 Kafka-存儲機制的流程圖

需要注意的是，因爲Kafka讀取特定消息的時間複雜度爲O(1)，即與文件大小無關，所以這裏刪除過期文件與提高 Kafka 性能無關。

圖5.3中Topic是邏輯上的概念，而Partition是物理上的概念，由於生產者生產的消息會不斷追加到log文件末尾，爲防止log文件過大導致數據定位效率低下，Kafka採取了分片和索引機制。每個Partition分爲多個Segment，每個Segment對應兩個文件：“.index”索引文件和 “.log”數據文件。

5.3 Kafka分區機制

5.3.1.分區原因

①方便在集羣中擴展，每個 Partition 可以通過調整以適應它所在的機器，而一個Topic又可以有多個Partition組成，因此可以以 Partition 爲單位讀寫了。

②可以提高併發，因此可以以Partition爲單位讀寫了。

注：Kafka並不支持讀寫分區，生產消費端所有的讀寫請求都是由leader副本處理的，follower副本的主要工作就是從leader副本處異步拉取消息，進行消息數據的同步，並不對外提供讀寫服務。

5.3.2.分區原則

Kafka 有兩種分配策略，一個是RoundRobin(下面會提及到，輪詢算法)，一個是 Range，默認爲Range(按主題進行分區)，當消費者組內消費者發生變化時，會觸發分區分配策略(方法重新分配)。

我們需要將Producer發送的數據封裝成一個ProducerRecord對象。該對象需要指定一些參數：

topic：string類型，NotNull。

partition：int 類型，可選。

timestamp：long類型，可選。

key：string類型，可選。

value：string類型，可選。

headers：array類型，Nullable。

①指明Partition的情況下，直接將給定的Value作爲Partition的值。

②沒有指明Partition但有Key的情況下，將Key的Hash值與分區數取餘得到Partition值。

③既沒有 Partition 有沒有Key的情況下，第一次調用時隨機生成一個整數(後面每次調用都在這個整數上自增)，將這個值與可用的分區數取餘，得到Partition值，也就是常說的Round-Robin輪詢算法。

5.3.3.RoundRobin和Range分區的區別

①RoundRobin

$| | || ---- | ------------------------------------------------------------ || | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-X4Fui38T-1591687050522)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps18.jpg)] |$

圖5.4 RoundRobin方式分區圖

RoundRobin輪詢方式將分區所有作爲一個整體進行Hash排序，消費者組內分配分區個數最大差別爲1，是按照組來分的，可以解決多個消費者消費數據不均衡的問題。

但是，當消費者組內訂閱不同主題時，可能造成消費混亂，如圖5.5所示，Consumer0訂閱主題A，Consumer1訂閱主題B。

$| | || ---- | ------------------------------------------------------------ || | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-gTQaZGCJ-1591687050522)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps19.jpg)] |$

圖5.5 RoundRobin方式造成消費混亂圖

將A、B主題的分區排序後分配給消費者組，TopicB分區中的數據可能分配到 Consumer0中。

②Range

$| | || ---- | ------------------------------------------------------------ || | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-saCWDay6-1591687050523)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps20.jpg)] |$

圖5.6 Range方式分區圖

Range 方式是按照主題來分的，不會產生輪詢方式的消費混亂問題。

但是，如圖5.7所示，Consumer0、Consumer1 同時訂閱了主題A和B，可能造成消息分配不對等問題，當消費者組內訂閱的主題越多，分區分配可能越不均衡。

$| | || ---- | ------------------------------------------------------------ || | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-6w8oDyYa-1591687050524)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps21.jpg)] |$

圖5.7 Range方式消息分配不對等圖

5.4.Kafka 副本機制

副本機制也稱Replication機制是Kafka實現高可靠、高可用的基礎。Kafka中有leader和follower兩類副本。

5.4.1.副本的作用

Kafka默認只會給分區設置一個副本，由broker端參數 default.replication.factor 控制，默認值爲 1，通常我們會修改該默認值，或者命令行創建 topic 時指定 replication-factor 參數，生產建議設置 3 副本。副本作用主要有兩方面：

①消息冗餘存儲，提高 Kafka 數據的可靠性；

②提高 Kafka服務的可用性，follower副本能夠在leader副本掛掉或者broker宕機的時候參與leader選舉，繼續對外提供讀寫服務。

5.4.2.讀寫分離*

上文提及到Kafka不支持讀寫分區，Kafka 之所以這樣設計，主要是爲了保證讀寫一致性，因爲副本同步是一個異步的過程，如果當 follower 副本還沒完全和leader同步時，從follower副本讀取數據可能會讀不到最新的消息。

這就涉及到ISR副本同步策略，Kafka爲了維護分區副本的同步，引入 ISR（In-Sync Replicas）副本集合的概念，ISR是分區中正在與leader副本進行同步的replica列表，且必定包含leader副本。

ISR 列表是持久化在 Zookeeper 中的，任何在ISR列表中的副本都有資格參與leader選舉。

圖5.8 Kafka-副本同步策略圖

ISR 是動態變化的，所以ISR列表就有爲空的時候，ISR爲空說明 leader副本也“掛掉”了，此時Kafka 就要重新選舉出新的leader。當ISR 爲空，就需要Unclean leader選舉。Kafka broker端提供了一個參數unclean.leader.election.enable，用於控制是否允許非同步副本參與 leader選舉。如果開啓Unclean leader選舉，可能會造成數據丟失，但可以保證始終有一個leader副本對外提供服務。

這就是典型的CAP理論，即一個系統不可能同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition Tolerance）中的兩個。所以在這個問題上，Kafka 賦予了我們選擇 C 或 A 的權利。

5.5.Kafka數據可靠性保證

Kafka有ACK機制，爲保證Producer發送的數據，能可靠地發送到指定的Topic，Topic的每個Partition收到Producer發送的數據後，都需要向Producer發送ACK(ACKnowledge確認收到)。

如果 Producer收到 ACK，就會進行下一輪的發送，否則重新發送數據。

5.5.1.通過副本同步策略

確保有 Follower與 Leader同步完成，Leader再發送ACK，這樣才能保證Leader掛掉之後，能在 Follower中選舉出新的 Leader而不丟數據。那麼多少個Follower同步完才發送ACK機制，分爲：半數以上完成和全部完成，它們的區別主要是延遲和當機器出現故障時所需要的副本數不同。

5.5.2.ISR機制

5.4章節提到過。

5.5.3.ACK應答機制

對於某些不太重要的數據，對數據的可靠性要求不是很高，能夠容忍數據的少量丟失，所以沒必要等ISR中的 Follower 全部接受成功。這裏主要是設計ACK參數的三種配置0，1和-1：

0：Producer不等待Broker的ACK，這提供了最低延遲，Broker一收到數據還沒有寫入磁盤就已經返回，當Broker故障時有可能丟失數據。

1：Producer等待 Broker的 ACK，Partition的Leader落盤成功後返回ACK，如果在 Follower 同步成功之前 Leader 故障，那麼將會丟失數據。

-1(all)：Producer等待Broker的ACK，Partition的Leader和Follower全部落盤成功後才返回ACK。但是在Broker發送ACK時，Leader發生故障，則會造成數據重複。

5.5.4.故障處理細節

$| | || ---- | ------------------------------------------------------------ || | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-soNAlLkb-1591687050526)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps23.jpg)] |$

圖5.9 Kafka-LEO\HW位置圖

LEO：每個副本最大的 Offset。HW：消費者能見到的最大的Offset，ISR隊列中最小的LEO。

Follower 故障：Follower發生故障後會被臨時踢出ISR集合，待該 Follower恢復後，Follower會讀取本地磁盤記錄的上次的HW，並將log文件高於HW的部分截取掉，從HW開始向Leader進行同步數據操作。

等該Follower的LEO大於等於該Partition的HW，即Follower追上 Leader 後，就可以重新加入 ISR 了。

Leader故障：Leader 發生故障後，會從ISR中選出一個新的 Leader，之後，爲保證多個副本之間的數據一致性，其餘的Follower會先將各自的 log文件高於HW的部分截掉，然後從新的Leader同步數據。

注意：這隻能保證副本之間的數據一致性，並不能保證數據不丟失或者不重複。

6.[補充]Kafka-控制器介紹

控制器（Controller）是Kafka的核心組件，它的主要作用是在 Zookeeper的幫助下管理和協調整個Kafka集羣。集羣中任意一個broker 都能充當控制器的角色，但在運行過程中，只能有一個broker成爲控制器。

6.1.Zookeeper的Znode節點和Watch機制介紹

控制器的產生依賴於Zookeeper的ZNode模型和Watcher機制。Zookeeper的數據模型是類似Unix操作系統的ZNode Tree即ZNode樹，ZNode 是Zookeeper中的數據節點，是Zookeeper存儲數據的最小單元，每個 ZNode 可以保存數據，也可以掛載子節點，根節點是 /。基本的拓撲圖如圖6.1：

$| | || ---- | ------------------------------------------------------------ || | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-WiQq4gok-1591687050527)(file:///C:\Users\Dell\AppData\Local\Temp\ksohtml20904\wps24.jpg)] |$

圖6.1 Zookeeper的Znode節點圖

Zookeeper有兩類ZNode節點，分別是持久性節點和臨時節點。持久性節點是指客戶端與Zookeeper斷開會話後，該節點依舊存在，直到執行刪除操作纔會清除節點。臨時節點的生命週期是和客戶端的會話綁定在一起，客戶端與Zookeeper斷開會話後，臨時節點就會被自動刪除。

Watcher 機制是Zookeeper非常重要的特性，它可以在ZNode節點上綁定監聽事件，比如可以監聽節點數據變更、節點刪除、子節點狀態變更等事件，通過這個事件機制，可以基於Zookeeper實現分佈式鎖、集羣管理等功能。

6.2.控制器選舉

當集羣中的任意broker啓動時，都會嘗試去Zookeeper中創建 /controller節點，第一個成功創建/controller節點的broker則會被指定爲控制器，**其他broker則會監聽該節點的變化。**當運行中的控制器突然宕機或意外終止時，其他broker能夠快速地感知到，然後再次嘗試創建 /controller節點，創建成功的broker會成爲新的控制器。

6.3.控制器功能

控制器主要作用是管理和協調Kafka集羣，那麼Kafka控制器都做了哪些事情呢，具體如下：

主題管理：創建、刪除topic，以及增加topic分區等操作都是由控制器執行。

分區重分配：執行Kafka的reassign腳本對topic分區重分配的操作，也是由控制器實現。

Preferred leader選舉： Preferred replica即優先副本，表示的是分配副本中的第一個副本。Preferred leader 選舉就是指 Kafka 在某些情況下出現leader負載不均衡時，會選擇preferred 副本作爲新 leader 的一種方案。這也是控制器的職責範圍。

集羣成員管理：控制器能夠監控新 broker 的增加，broker的主動關閉與被動宕機，進而做其他工作。這裏也是利用前面所說的 Zookeeper的 ZNode模型和Watcher機制，控制器會監聽 Zookeeper中/brokers/ids下臨時節點的變化。

數據服務：控制器上保存了最全的集羣元數據信息，其他所有broker 會定期接收控制器發來的元數據更新請求，從而更新其內存中的緩存數據。

從上面內容我們大概知道，控制器可以說是Kafka的心臟，管理和協調着整個Kafka集羣，因此控制器自身的性能和穩定性就變得至關重要。

社區在這方面做了大量工作，特別是在0.11版本中對控制器進行了重構，其中最大的改進把控制器內部多線程的設計改成了單線程加事件隊列的方案，消除了多線程的資源消耗和線程安全問題，另外一個改進是把之前同步操作Zookeeper 改爲了異步操作，消除了Zookeeper端的性能瓶頸，大大提升了控制器的穩定性。

7.[補充]Kafka-消費端Rebalance機制

前面介紹消費者術語時，提到了消費組的概念，一個topic可以讓若干個消費者進行消費，若干個消費者組成一個Consumer Group即消費組，一條消息只能被消費組中的一個消費者進行消費。我們用圖7.1表示Kafka的消費模型。

圖7.1 Kafka的消費模型圖

7.1.Rebalance概念

就Kafka消費端而言，有一個難以避免的問題就是消費者的重平衡即 Rebalance。Rebalance是讓一個消費組的所有消費者就如何消費訂閱 topic的所有分區達成共識的過程，在Rebalance 過程中，所有Consumer 實例都會停止消費，等待Rebalance的完成。因爲要停止消費等待重平衡完成，因此 Rebalance會嚴重影響消費端的TPS，是應當儘量避免的。

7.2.Rebalance發生條件

關於何時會發生 Rebalance，總結起來有三種情況：

①消費組的消費者成員數量發生變化

②消費主題的數量發生變化

③消費主題的分區數量發生變化

其中後兩種情況一般是計劃內的，比如爲了提高消息吞吐量增加 topic分區數，這些情況一般是不可避免的，後面我們會重點討論如何避免因爲組內消費者成員數發生變化導致的Rebalance。

7.3.Kafka協調器

在介紹如何避免Rebalance問題之前，先來認識下Kafka的協調器 Coordinator，和之前Kafka控制器類似，Coordinator也是Kafka的核心組件。

主要有兩類 Kafka 協調器：

①組協調器（Group Coordinator）

②消費者協調器（Consumer Coordinator）

Kafka 爲了更好的實現消費組成員管理、位移管理，以及Rebalance 等，broker 服務端引入了組協調器（Group Coordinator），消費端引入了消費者協調器（Consumer Coordinator）。每個 broker 啓動的時候，都會創建一個GroupCoordinator實例，負責消費組註冊、消費者成員記錄、offset等元數據操作，這裏也可以看出每個broker都有自己的 Coordinator組件。另外，每個Consumer實例化時，同時會創建一個 ConsumerCoordinator 實例，負責消費組下各個消費者和服務端組協調器之前的通信。可以用圖7.2表示協調器原理：

圖7.2 Kafka協調器原理圖

客戶端的消費者協調器Consumer Coordinator和服務端的組協調器 Group Coordinator會通過心跳不斷保持通信。

7.4.如何避免消費組Rebalance

接下來我們討論下如何避免組內消費者成員發生變化導致的 Rebalance。組內成員發生變化無非就兩種情況，一種是有新的消費者加入，通常是我們爲了提高消費速度增加了消費者數量，比如增加了消費線程或者多部署了一份消費程序，這種情況可以認爲是正常的；另一種是有消費者退出，這種情況多是和我們消費端代碼有關，是我們要重點避免的。

正常情況下，每個消費者都會定期向組協調器 Group Coordinator發送心跳，表明自己還在存活，如果消費者不能及時的發送心跳，組協調器會認爲該消費者已經“死”了，就會導致消費者離組引發Rebalance問題。這裏涉及兩個消費端參數session.timeout.ms和heartbeat.interval.ms，含義分別是組協調器認爲消費組存活的期限，和消費者發送心跳的時間間隔，其中heartbeat.interval.ms 默認值是3s，session.timeout.ms在 0.10.1 版本之前默認 30s，之後默認10s。另外，0.10.1版本還有兩個值得注意的地方：

從該版本開始，Kafka維護了單獨的心跳線程，之前版本中 Kafka 是使用業務主線程發送的心跳。增加了一個重要的參數 max.poll.interval.ms，表示Consumer兩次調用pull方法拉取數據的最大時間間隔，默認值5min，對於那些忙於業務邏輯處理導致超過max.poll.interval.ms時間的消費者將會離開消費組，此時將發生一次Rebalance。

此外，如果 Consumer 端頻繁FullGC也可能會導致消費端長時間停頓，從而引發 Rebalance。因此，我們總結如何避免消費組Rebalance問題，主要從以下幾方面入手：

合理配置session.timeout.ms和heartbeat.interval.ms，建議 0.10.1之前適當調大 session 超時時間儘量規避 Rebalance。根據實際業務調整max.poll.interval.ms，通常建議調大避免Rebalance，但注意0.10.1版本之前沒有該參數。監控消費端的GC情況，避免由於頻繁FullGC導致線程長時間停頓引發 Rebalance。

合理調整以上參數，可以減少生產環境中Rebalance發生的機率，提升 Consumer端的TPS和穩定性。

x.poll.interval.ms，表示Consumer兩次調用pull方法拉取數據的最大時間間隔，默認值5min，對於那些忙於業務邏輯處理導致超過max.poll.interval.ms時間的消費者將會離開消費組，此時將發生一次Rebalance。