KafkaProducer.send()不阻塞但日志易丢，因消息仅入缓冲区即返回；需flush()关闭、acks=all、retries最大、linger.ms>0，并监控TimeoutException；Consumer需合理配置poll参数、禁用自动提交、序列化器严格匹配、避免Rebalance。
为什么 KafkaProducer.send() 不阻塞，但日志却丢了
默认 send() 是异步的，消息进缓冲区就返回，不代表已发到 Broker。丢日志往往发生在 JVM 快速退出、网络抖动或 linger.ms=0 时缓冲区未刷出。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 务必调用
producer.flush()再关闭（尤其在日志采集 Agent 的 shutdown hook 里） - 设置
acks=all+retries=Integer.MAX_VALUE，避免网络瞬断导致消息被静默丢弃 - 别依赖回调里的
exception == null就认为成功——TimeoutException可能出现在回调外，需结合max.block.ms和日志监控判断 - 示例关键配置：
props.put("bootstrap.servers", "k1:9092,k2:9092");<br>props.put("acks", "all");<br>props.put("retries", "2147483647");<br>props.put("linger.ms", "5"); // 别设 0，小批量攒批能显著降吞吐压力
Consumer 如何批量拉取又不卡住实时性
KafkaConsumer.poll() 的行为受 max.poll.records、fetch.max.wait.ms 和 fetch.min.bytes 共同控制。设太大，单次处理超时触发 rebalance；设太小，频繁轮询浪费 CPU 且延迟上升。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 日志类场景优先调大
fetch.max.wait.ms（如 100–500ms），配合fetch.min.bytes=1，让 Consumer 主动等数据凑够再拉，而非空转 -
max.poll.records建议设为 500–1000，和单条日志平均大小、处理耗时匹配——若处理 1 条要 2ms，1000 条就是 2s，已逼近默认max.poll.interval.ms=300000的安全线 - 禁用自动提交（
enable.auto.commit=false），在整批处理完后手动commitSync()，否则部分失败会导致 offset 提前提交，丢失重试机会
序列化器选错导致 Consumer 解不出日志内容
日志通常是字符串或 JSON，但新手常直接用 StringDeserializer 却配了 ByteArraySerializer 发送，或反过来。更隐蔽的是：Log4j 写入 Kafka 时用了 PatternLayout，但 Consumer 拿到的是带时间戳+线程名的完整文本，不是纯 JSON 对象。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 生产端和消费端的
key.serializer/value.serializer与key.deserializer/value.deserializer必须严格一一对应 - 日志建议统一走
StringSerializer+StringDeserializer，避免二进制解析歧义；结构化日志（如 Logback 的JsonLayout）再考虑ByteArraySerializer配合 Jackson 手动反序列化 - 调试时先用
kafka-console-consumer.sh看原始输出：kafka-console-consumer.sh --bootstrap-server k1:9092 --topic log-topic --from-beginning --max-messages 5
，确认格式是否符合预期
Consumer Group Rebalance 频繁发生，日志重复或跳过
日志 Consumer 最怕两件事：每秒处理不完导致 Poll 超时，或 GC 停顿太久被 Coordinator 判为失联。只要 poll() 间隔超过 max.poll.interval.ms，就会触发 Rebalance，旧实例未 commit 的 offset 被新实例接管，造成重复或跳过。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 把单次
poll()拉取量（max.poll.records）和单条处理耗时做乘法，确保结果远小于max.poll.interval.ms（例如留 3 倍余量） - 开启 GC 日志，监控
pause time是否接近 5s——JVM Full GC 可能直接干掉一次心跳 - 不要在
poll()循环里做文件写入、HTTP 请求等阻塞操作；日志落地建议异步队列 + 单独线程刷盘 - Group ID 命名带上环境和角色，比如
log-collector-prod-nginx，避免测试 Consumer 意外加入生产 Group
真正难的不是写对那几行 send/poll，而是把缓冲区水位、网络往返、GC 暂停、磁盘 IO 这些隐性延迟全串起来看。一个参数调错，可能三小时后才在凌晨告警里浮现。
