一、分區數設置原則
1. 并發能力基準
分區數決定最大消費者并行度,建議設置為消費者組內消費者數量的整數倍
例如:消費者組有4個實例 → 分區數設為4/8/12等
這里定義的目的是為了讓消費者能均勻的分配到分區,避免打破負載均衡,觸發rebalance。
2. 吞吐量指標
單個分區寫入速度建議不超過10MB/s
消息TPS超過10萬時,可按公式計算:
分區數 = 目標吞吐量 / 單個分區吞吐量
這里回答不一定準確,因為一般情況下需要考慮部署kafka機器的性能,需要壓測出一個穩定數據,通過穩定數據去計算需要的分區數大小,比如TPS超過1萬,每條消息10k,就意味著每秒100萬k消息,100萬k/單個分區穩定數據(比如10萬k),這個時候就需要10個分區,然后搭配消費者負載均衡,設置12個分區。
3. 擴展性預留
建議初始設置時預留20-30%的擴展空間
最大分區數不宜超過200(避免元數據管理開銷過大)
二、副本數設置原則
1. 可靠性基線
生產環境必須設置≥3副本(ISR最小副本數建議2)
保證可靠性,部分broker宕機可能導致數據丟失,使用ISR機制有備份情況。
2. 集群規模對應
推薦設置規則:
- 開發環境:1-2副本
- 生產環境:3副本(集群≥5節點時)
- 金融級場景:5副本
3. 寫入性能權衡
副本數每增加1,寫入吞吐量下降約10%
高吞吐場景建議搭配acks=1
或0
配置使用
這里建議使用acks=1,至少保證一個副本有同步,除非是日志消息之類的,可以考慮ack=0,不然容災能力會很差。
三、特殊場景優化
# 需要嚴格順序的場景
num.partitions=1
- 將主題分區數強制設置為1,所有消息按寫入順序嚴格排列
- 犧牲橫向擴展能力,保證全局消息順序一致性
- 適用于金融交易、訂單狀態變更等強順序需求場景
unclean.leader.election.enable=false
- 禁止非ISR副本(低于高水位線,也就是未完全同步Leader)參與Leader選舉(默認值)
- 當所有ISR副本失效時,寧可停止服務也不選舉不同步副本
- 避免數據丟失但會降低可用性,需配合 min.insync.replicas 使用
保序# 高可用要求場景
default.replication.factor=3
- 設置默認副本數為3(需集群至少有3個Broker)
- 每個分區會在不同Broker上保存3個副本
- 最多可容忍2個Broker同時故障而不丟失數據
min.insync.replicas=2
指定?對于每個分區,至少有多少個副本需要與領導者副本(Leader Replica)保持同步,才能認為該分區是可用的?。
- 定義最小同步副本數要求(需 ≤ replication.factor)
- 生產者設置 acks=all 時,需要至少2個副本確認寫入才算成功
- 在數據安全性與寫入延遲之間取得平衡(1<min<replication.factor
四、配置驗證方法
# 分區性能壓測(使用kafka-producer-perf-test)
bin/kafka-producer-perf-test.sh --topic test-topic \
--num-records 1000000 --record-size 1000 \
--throughput -1 --producer-props bootstrap.servers=localhost:9092
- bin/kafka-producer-perf-test.sh Kafka 自帶的性能測試工具腳本路徑,用于模擬生產者發送消息
- –topic test-topic 指定要測試的 Kafka 主題名稱(需要提前創建好)
- –num-records 1000000 設置總共要發送 1,000,000 條測試記錄
- –record-size 1000 每條記錄的大小設置為 1000 字節(約 1KB)
- –throughput -1 設置吞吐量為無限制(-1 表示以最大速度發送),若設為正數則表示每秒發送的記錄數
- –producer-props bootstrap.servers=localhost:9092 指定生產者配置:
- bootstrap.servers :Kafka 集群地址(本地單節點)
- 可追加其他生產者參數如 acks=1 , compression.type=snappy 等
建議通過監控以下指標持續優化:
一、檢測分區 Leader 的 ISR 變化頻率
# 實時查看 ISR 變化(需開啟 JMX 監控)
bin/kafka-run-class.sh kafka.tools.JmxTool --object-name kafka.server:type=ReplicaManager,name=IsrShrinksPerSec
bin/kafka-run-class.sh kafka.tools.JmxTool --object-name kafka.server:type=ReplicaManager,name=IsrExpandsPerSec# 查看歷史 ISR 變更記錄
bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic test-topic --describe | grep "Isr"
IsrShrinksPerSec
- 含義:每秒ISR(In-Sync Replicas)集合收縮的次數
- 表示副本從ISR中被移除的速率,可能由以下原因觸發:
- 副本同步延遲超過 replica.lag.time.max.ms (默認30秒)
- 磁盤故障或網絡問題導致副本離線
IsrExpandsPerSec
- 含義:每秒ISR集合擴展的次數
- 表示副本重新加入ISR的速率,常見恢復場景:
- 副本追趕上Leader的消息進度
- 網絡恢復后副本重新上線
安全建議(生產環境必做)
# 啟用 SSL 和認證的配置示例
export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9999 \
-Dcom.sun.management.jmxremote.ssl=true \
-Dcom.sun.management.jmxremote.registry.ssl=true \
-Dcom.sun.management.jmxremote.authenticate=true \
-Dcom.sun.management.jmxremote.password.file=/etc/kafka/jmx.password"
如何開啟關閉JMX
開啟JMX監控腳本 (enable_jmx.sh)
#!/bin/bash
# 設置JMX端口和認證參數
export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"# 設置JMX遠程訪問IP限制(默認本地)
export JMX_HOSTNAME="-Djava.rmi.server.hostname=localhost"# 啟動Kafka服務(后臺運行)
nohup /path/to/kafka/bin/kafka-server-start.sh /path/to/kafka/config/server.properties > /dev/null 2>&1 &
逐行解釋:
#!/bin/bash
:指定使用bash解釋器執行腳本export KAFKA_JMX_OPTS...
:設置JMX參數-Dcom.sun.management.jmxremote
:啟用JMX遠程監控-Dcom.sun.management.jmxremote.port=9999
:指定JMX端口authenticate=false
:禁用認證(生產環境建議開啟)ssl=false
:禁用SSL加密(生產環境建議開啟)
export JMX_HOSTNAME...
:設置JMX服務綁定IPnohup ... &
:后臺運行Kafka服務并忽略掛起信號
關閉JMX監控腳本 (disable_jmx.sh)
#!/bin/bash
# 查找Kafka進程ID
PID=$(jps -l | grep kafka.Kafka | awk '{print $1}')# 停止Kafka服務
if [ -n "$PID" ]; thenkill -9 $PIDecho "Kafka stopped successfully"
elseecho "Kafka is not running"
fi# 清除JMX環境變量
unset KAFKA_JMX_OPTS
unset JMX_HOSTNAME
逐行解釋:
PID=$(jps -l...)
:通過jps命令查找Kafka進程IDif [ -n "$PID" ]...
:判斷進程是否存在kill -9 $PID
:強制終止Kafka進程unset...
:清除JMX相關環境變量
注意事項:
- 端口號9999可根據實際情況修改,需確保防火墻開放
- 生產環境建議啟用認證和SSL加密(需配置相關證書)
- 腳本中的kafka路徑需替換為實際安裝路徑
- JMX關閉本質是停止Kafka服務,重啟時不帶JMX參數即關閉監控
二、檢測生產/消費 p99 延遲
# 生產者延遲監控(需 JMX)
bin/kafka-run-class.sh kafka.tools.JmxTool --object-name kafka.producer:type=producer-metrics,client-id=*# 消費者延遲監控
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group [消費者組名] --describe | awk '{print $1,$2,$6}'
三、檢測分區消息堆積量
# 查看所有消費者組堆積量
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list | xargs -I {} bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group {} --describe# 查看指定分區堆積量
bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list localhost:9092 --topic test-topic --time -1
bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list localhost:9092 --topic test-topic --time -2
監控建議:
- 建議將上述命令集成到 Prometheus + Grafana 監控體系
- 關鍵指標告警閾值設置:
- ISR 變更頻率 > 5次/分鐘 觸發告警
- p99 延遲 > 500ms 觸發告警
- 消息堆積量持續增長超過 10萬條 觸發告警
- 推薦使用 Kafka Eagle 可視化工具進行實時監控