聊聊不同版本 Kafka Producer 的分區(qū)策略

作者：IT明哥 2024-09-04 09:18:03

某微服務(wù)，使用 log4j kafka appender 寫日志到 kafka 中。業(yè)務(wù)同學反饋，微服務(wù)日志中有頻繁出現(xiàn)類似如下的kafka連接斷開的日志，希望分析下kafka連接斷開的原因，并確認是否會因此丟失微服務(wù)日志。

1 問題現(xiàn)象

2024-08-08 07:10:06.994 -INFO [kafka-producer-network-thread | producer-1] org.apache.kafka.clients. NetworkClient -[Producer clientId=producer-1] Node 2 disconnected.）

kafka連接斷開的具體日志如下圖所示：

圖片

2 問題分析

由于kafka集群有多個broker節(jié)點，kafka topic 也有多個分區(qū)，所以微服務(wù)作為 kafka producer，在底層會建立對個 tcp 連接，以發(fā)送日志到各個 kafka topic partition。
通過 awk 篩選微服務(wù)日志可見，微服務(wù)針對同一個 kafka broker的tcp 連接，并不會頻繁斷開，且斷開的時點，一般是在業(yè)務(wù)低峰期，打印日志不多的時候：

圖片

為進一步確認問題，在微服務(wù)節(jié)點上，可以查看下 TCP 連接的狀態(tài)(可以通過命令 netstat -apn -t|grep -i 9092 或 ss -antop |grep -i 9092)，甚至通過 tcpdump 抓包分析下（可以通過命令nohup tcpdump tcp port 9092 -i any -s100 -B 8192 -p -n -w /tmp/9092.pcap >> /tmp/9092.out 2>&1 &）。
在生產(chǎn)環(huán)境中，使用上述命令，抓了近2個小時的包，并對 tcpdump 包文件進行了分析，如下圖可見，所有的tcp連接斷開，都是由微服務(wù)（即 kafka producer）主動斷開的，且具體來說，是微服務(wù)長達540秒，都不需要發(fā)送日志到某個具體的kafka topic partition時，因超時主動斷開的：

圖片

image

圖片

image

圖片

3.問題原因

3.1 kafka 對空閑連接檢查和清理機制-producer 參數(shù)connections.max.idle.ms

為減輕對kafka broker 服務(wù)端的壓力，kafka producer 有空閑連接的檢查和清理機制:

當某個tcp連接長時間idle時，kafka producer就會主動關(guān)閉該空閑連接，并打印日志org.apache.kafka.clients. NetworkClient -[Producer clientId=producer-1] Node 2 disconnected；
判斷空閑連接的空閑閾值，就是參數(shù) connections.max.idle.ms，該參數(shù)默認 540000 即 9 分鐘，這也與上述tcpdump抓包體現(xiàn)的，kafka producer 在540秒的空閑后，主動斷開連接的現(xiàn)象一致：

圖片

3.2 Kafka在key=null 時的分區(qū)策略- Sticky Partitioner vs Round Robin Partitioner

Kafka producer 寫ProducerRecord到kafka topic時， ProducerRecord對應(yīng)的具體 partiton分區(qū)，是由Partitioner分區(qū)器決定的。當 ProducerRecord 的key=null 時，會采用默認的分區(qū)器，在Kafka 2.3 及kafka2.3以下版本，默認的分區(qū)策略是Round Robin Partitioner；而Kafka 2.4 及以上版本，默認的分區(qū)策略是Sticky Partitioner。
目前該微服務(wù)，寫日志到 kafka 時，log4j2.xml中都沒有配置 kafka record key，且采用的是kafka-clients-3.4.0.jar，所以此時會使用 Sticky Partitioner 而不是 Round Robin Partitioner，相鄰的多個ProducerRecord都會屬于同一個 record batch，都會 “sticky” 到同一個分區(qū)，所以在日志低峰期,可能長時間都不會發(fā)送日志到某些分區(qū)，如果該時間超過了producer 參數(shù) connections.max.idle.ms（默認 540000 即 9 分鐘），則該分區(qū)對應(yīng)的 TCP 連接，就會被 PRODUCER 主動關(guān)閉，如果 kafka 分區(qū)較多比如100個，而微服務(wù)日志較少且 batch.size 和 linger.ms 較大，該現(xiàn)象會更加明顯。

4 問題總結(jié)

為減輕對服務(wù)端kafka broker的壓力，kafka producer 有空閑連接的檢查和清理機制，當某個tcp連接的idle時長大于參數(shù)connections.max.idle.ms時(該參數(shù)默認 540000 即 9 分鐘)，kafka producer就會主動關(guān)閉該空閑連接，并打印日志org.apache.kafka.clients. NetworkClient -[Producer clientId=producer-1] Node 2 disconnected，此時所有的日志都會被正常落地，不會丟失日志數(shù)據(jù)；
當使用Kafka 2.4 及以上版本的 kafka producer時，如果沒有指定ProducerRecord的key，當業(yè)務(wù)低峰期微服務(wù)日志較少且 batch.size 和 linger.ms 較大時，上述kafka producer主動關(guān)閉空閑連接的現(xiàn)象會更加明顯，因為此時會使用默認的分區(qū)策略Sticky Partitioner，此時相鄰的多個ProducerRecord都會屬于同一個 record batch，都會 “sticky” 到同一個分區(qū)，所以可能長時間都不會發(fā)送日志到某些分區(qū)，如果該空閑時間超過了上述producer 參數(shù) connections.max.idle.ms，則該分區(qū)對應(yīng)的 TCP 連接，就會被 PRODUCER 主動關(guān)閉。

5.技術(shù)背景

5.1 KAFKA 客戶端和服務(wù)端在版本上的雙向兼容性

KAFKA 客戶端和服務(wù)端在版本上具有雙向兼容性，即客戶端和服務(wù)端的版本可以不同：Kafka has a "bidirectional" client compatibility policy. In other words, new clients can talk to old servers, and old clients can talk to new servers. This allows users to upgrade either clients or servers without experiencing any downtime.
在上述案例中，kafka 集群服務(wù)端，使用的是kafka_2.11-2.2.0.jar；
在上述案例中，該微服務(wù)，通過logj寫日志到kafka時，使用的 kafka producer 版本是 kafka-clients-3.4.0.jar
目前 apache kafka 最新版是 Kafka 3.8 （截止 202409）；

圖片

5.2 kafka 對空閑連接檢查和清理機制-producer 參數(shù)connections.max.idle.ms

為減輕對kafka broker 服務(wù)端的壓力，kafka producer 有空閑連接的檢查和清理機制:

當某個tcp連接長時間idle時，kafka producer就會主動關(guān)閉該空閑連接，并打印日志org.apache.kafka.clients. NetworkClient -[Producer clientId=producer-1] Node 2 disconnected；
判斷空閑連接的空閑閾值，就是參數(shù) connections.max.idle.ms，該參數(shù)默認 540000 即 9 分鐘，這也與上述tcpdump抓包體現(xiàn)的，kafka producer 在540秒的空閑后，主動斷開連接的現(xiàn)象一致；

5.3 Kafka在 key=null 時的分區(qū)策略- Sticky Partitioner vs Round Robin Partitioner

Kafka producer 寫ProducerRecord到kafka topic時， ProducerRecord對應(yīng)的具體 partiton分區(qū)，是由Partitioner分區(qū)器決定的;
當 ProducerRecord 的key=null 時，會采用默認的分區(qū)器，在Kafka 2.3 及kafka2.3以下版本，默認的分區(qū)策略是Round Robin Partitioner；而Kafka 2.4 及以上版本，默認的分區(qū)策略是Sticky Partitioner。
When key=null, the producer has a default partitioner that varies: Round Robin: for Kafka 2.3 and below；Sticky Partitioner: for Kafka 2.4 and above:

With Kafka producer <= v2.3: when there’s no partition and no key specified, the default partitioner sends data in a round-robin fashion. This results in more batches (one batch per partition) and smaller batches (imagine with 100 partitions). And this is a problem because smaller batches lead to more requests as well as higher latency.

With Kafka producer >= v2.4: Sticky Partitioner improves the performance of the producer especially with high throughput. It is a performance goal to have all the records sent to a single partition and not multiple partitions to improve batching. The producer sticky partitioner will “stick” to a partition until the batch is full or linger.ms has elapsed; After sending the batch, kafka producer will change the partition that is "sticky". This will lead to larger batches and reduced latency (because we have larger requests, and the batch.size is more likely to be reached). Over time, the records are still spread evenly across partitions, so the balance of the cluster is not affected.

5.4 相關(guān)源碼與參考鏈接

-- 相關(guān)源碼
org.apache.kafka.clients.producer.Partitioner
org.apache.kafka.clients.producer.internals.DefaultPartitioner
org.apache.kafka.clients.producer.UniformStickyPartitioner
org.apache.kafka.clients.producer.RoundRobinPartitioner
-- 參考連接：
KIP-480: Sticky Partitioner
KIP-794: Strictly Uniform Sticky Partitioner
https://cwiki.apache.org/confluence/display/KAFKA/KIP-794%3A+Strictly+Uniform+Sticky+Partitioner
https://cwiki.apache.org/confluence/display/KAFKA/KIP-480%3A+Sticky+Partitioner

責任編輯：武曉燕來源：明哥的IT隨筆

分區(qū)策略