在Linux環境下使用Kafka時，可能會遇到各種故障。以下是一些常見的故障及其排查和解決方案：
常見故障及解決方案
-
消息堆積
- 現象：生產者狂發消息，消費者處理速度慢，導致消息積壓。
- 原因：消費者代碼性能差（如同步阻塞、未批量處理）。分區數不足，無法并行消費。消費者組內成員分配不均。
- 解決方案：
- 優化消費者代碼：改用異步非阻塞處理（如使用線程池）。批量拉取消息（max.poll.records調大）。
- 增加分區數：
./kafka-topics.sh --alter --topic 訂單日志 --partitions 6 --bootstrap-server localhost:9092。
- 調整分配策略：使用RoundRobinAssignor替代默認的RangeAssignor，均衡負載。
-
數據丟失
- 現象：生產者發送成功，但消費者讀不到消息。
- 原因：生產者未開啟ACK確認（acks=0或1）。Leader副本宕機，且未同步到Follower。
- 解決方案：
- 生產者配置：
acks=all # 確保所有ISR副本確認后才返回成功。retries=3 # 自動重試。
- Broker配置：
min.insync.replicas=2 # 至少2個副本確認才允許寫入。
-
消費者重復消費
- 現象：消費者重啟或崩潰后，重復處理已讀消息。
- 原因：消費者提交Offset失?。ㄈ绫罎⑶拔刺峤唬?。自動提交Offset間隔太長（auto.commit.interval.ms默認5秒）。
- 解決方案：
- 手動提交Offset：
consumer.commitSync(); // 處理完消息后同步提交。
- 縮短自動提交間隔：
auto.commit.interval.ms=1000 // 1秒提交一次。
-
Leader切換導致短暫不可用
- 現象：Broker宕機后，分區Leader切換期間，生產者發送消息超時。
- 解決方案：
- 增加重試機制：
retries=5，retry.backoff.ms=1000 // 在嘗試重試對給定主題分區的失敗請求之前等待的時間。
- 客戶端緩存消息：生產者啟用本地緩存（如Kafka的
buffer.memory），避免消息丟失。
-
磁盤寫滿，Broker罷工
- 現象：Broker日志磁盤占用100%，無法寫入新消息。
- 解決方案：
- 緊急清理過期日志：
./kafka-delete-records.sh --bootstrap-server localhost:9092 --offset-json-file cleanup.jso。
- 預防配置：
log.retention.hours=72 # 縮短保留時間。log.retention.bytes=1073741824 # 每個分區最多保留1GB。
-
ZooKeeper連接閃斷，集群抖動
- 現象：頻繁報錯“ZooKeeper session expired”，Controller頻繁切換。
- 解決方案：
- 優化ZooKeeper配置：
zookeeper.session.timeout.ms=18000 # 增加會話超時時間。
- 監控ZooKeeper配置：避免ZooKeeper集群壓力過大（如分離Kafka和ZooKeeper的物理資源）。
-
消費者組重平衡太頻繁
- 現象：消費者組頻繁重新分配分區，導致消費暫停。
- 原因：消費者心跳超時（處理消息時間過長，未及時發送心跳）。網絡波動導致Group Coordinator認為消費者下線。
- 解決方案：
- 緊急清理過期日志：
session.timeout.ms=30000 # 心跳超時時間調大。max.poll.interval.ms=300000 # 拉取消息間隔上限調大。
- 優化消息處理邏輯：避免單條消息處理耗時過長。
-
跨機房同步延遲高
- 現象：異地多機房部署時，副本同步延遲高，ISR列表不穩定。
- 解決方案：
- 優先同機房同步：
broker.rack=us-east-1a # 標記Broker所在機房。
- 調整副本拉取參數：
replica.socket.timeout.ms=120000 # 增加副本同步超時時間。
監控和故障恢復
- 監控工具：使用JMX、Prometheus、Grafana、Kafka Manager、Kafka Monitor、Confluent Control Center等工具監控Kafka集群的健康狀況和性能表現。
- 故障恢復：確保Kafka集群對故障具有高可用性，采用多個Broker分散故障風險，使用副本機制保障數據可靠性，設置適當的復制因子和ISR大小。
日志文件缺失
- 問題現象：Kafka異常退出，原因是找不到對應的數據文件。
- 解決方法：更改Kafka的日志存儲目錄到安全的路徑，并修改配置文件，重啟Kafka。
其他常見故障及解決方案
- Kafka無法啟動，提示端口被占用：使用
lsof -i:port命令查看占用端口的進程，然后使用kill pid命令結束該進程。
- Kafka日志文件過大：定期清理日志文件，或者修改Kafka的配置，限制日志文件的大小和保留時間。
- Kafka消費者無法消費消息：檢查消費者組是否正確配置，確保消費者的訂閱主題和分區設置正確。
- Kafka生產者發送消息失敗：檢查生產者的配置，確保目標主題存在且分區可用。
- Kafka集群中的節點宕機：檢查宕機的節點的網絡連接和資源使用情況，確保其他節點正常運行。
- Kafka性能瓶頸：優化Kafka的配置參數，如增加分區數量、調整副本因子等，以提高吞吐量和延遲。
- Kafka集群中的數據不一致：檢查副本同步狀態，確保所有副本都處于同步狀態。如果發現數據不一致，可以嘗試重新同步副本。
通過以上步驟和工具，可以有效地進行Kafka故障排查和問題解決。
