在 Ubuntu 上排查与修复 Kafka 消息丢失
一、先快速定位丢失环节
- 生产者侧：确认是否收到 Broker 的确认、是否触发了重试、是否因消息过大被拒收。
- Broker 侧：检查磁盘空间、是否有 Leader 切换、ISR 收缩、ZooKeeper 会话过期等异常。
- 消费者侧：确认 自动提交是否开启、是否出现 处理未完成就提交、是否发生 再均衡导致短暂漏消费。
二、生产者端防丢配置与验证
- 关键配置（示例）
- acks=all：等待所有 ISR 副本确认，避免 Leader 未同步就应答。
- retries=5 且 retry.backoff.ms=1000：网络抖动或瞬时故障可自动重试。
- 使用带回调的发送方式，记录失败并重试或落库补偿。
- 合理设置消息大小与超时，避免被 Broker 拒收（如增大 max.request.size 与 request.timeout.ms）。
- 快速自检
- 用简单程序发送一批消息，打印每条消息的 topic/partition/offset 与回调异常，核对成功数与落库数是否一致。
- 观察发送回调是否出现超时/重试，必要时抓包或开启 TRACE 日志定位网络问题。
三、Broker 端防丢配置与运维要点
- 持久化与副本
- 设置 replication.factor ≥ 3，并配置 min.insync.replicas；推荐关系：replication.factor = min.insync.replicas + 1，确保即使一台宕机仍有足够副本满足“已提交”条件。
- 仅允许 ISR 成为 Leader（unclean.leader.election.enable=false），避免数据落后太多的副本上位导致数据丢失。
- 稳定性
- 监控并告警 磁盘空间（如 df -h /var/lib/kafka），磁盘接近满会导致写入失败或性能劣化。
- 关注 ZooKeeper 会话过期 与 Controller 频繁切换，必要时优化会话超时与资源隔离（Kafka 与 ZooKeeper 分开部署更稳）。
- 避免 跨机房 高延迟造成 ISR 不稳定，可通过 broker.rack 做机架感知与就近副本优先。
四、消费者端防丢策略
- 位移提交
- 关闭自动提交：enable.auto.commit=false；采用“先处理、后提交”策略。
- 提交方式：处理完一批再 同步提交（commitSync）确保成功；高吞吐可用 异步提交（commitAsync）配合回调与重试，但需接受可能的重复。
- 再均衡保护
- 合理增大 session.timeout.ms 与 max.poll.interval.ms，避免处理耗时较长被误判下线引发 再均衡 导致短暂漏消费。
- 在再均衡回调中妥善保存处理进度，必要时将未确认消息暂存（如写本地表或外部存储）以便重放。
- 位移重置
- 新订阅或位移过期时，将 auto.offset.reset=earliest，避免漏掉历史消息。
五、Ubuntu 现场排查与修复命令清单
- 资源与状态
- 查看磁盘与 Inode：df -h /var/lib/kafka；df -i /var/lib/kafka
- 查看 Broker 日志：/var/log/kafka/server.log（关注 ERROR/ WARN、Leader/ISR 变化、ZooKeeper 会话）
- 查看 Topic 详情：/usr/bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic
- 生产者验证脚本（示例）
- 使用 Kafka 自带脚本发送少量消息并核对返回元数据，确认 acks 与重试是否生效。
- 消费者位移与重置
- 查看消费组位移：/usr/bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group
- 重置为最早位点（谨慎，会重放）：/usr/bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group --reset-offsets --to-earliest --execute --topic
- 配置热更新
- 修改 server.properties 后，滚动重启 Broker；先停一个、确认无异常再继续，避免同时重启导致不可用窗口扩大。
以上步骤覆盖了 生产者、Broker、消费者 三个环节的高可靠配置与 Ubuntu 上的落地操作。若需要，我可以基于你的现有配置与 Topic 现状，给出一份最小改动的参数清单与回放方案。