java kafka消费端需禁用自动提交、预检脏数据、异常时暂停消费者、构建专用dlq topic：先显式关闭enable.auto.commit，仅业务成功后提交offset；反序列化时校验格式并捕获异常；依赖失败则pause+健康探测；失败消息封装上下文发至dlq topic并设重试上限。
Java 中处理 Kafka 消费端脏数据和死信消息，核心不是“等出问题再救火”，而是提前设计防御性消费逻辑——既要让异常消息不拖垮线程，又要确保它们可追溯、可隔离、可重试或可丢弃。关键在于打破 Kafka 原生“不提交 offset 就无限重试”的被动循环，把控制权收回到业务代码中。
关闭自动提交 + 精确控制 offset 提交时机
这是所有可靠消费的前提。自动提交（enable.auto.commit=true）会让 offset 在业务逻辑执行前就更新，一旦处理中途崩溃，消息直接丢失；而盲目不提交又导致无限重试和线程卡死。
- 显式配置
enable.auto.commit=false，禁用自动提交 - 只在业务逻辑**完全成功执行后**调用
commitSync()或commitAsync() - 若单条消息失败，不要跳过它继续提交后续 offset；应提交失败位置的前一个 offset（即
record.offset()），保证下次从该位置重试 - 避免批量提交时“全成功才提交”——某条失败就整批回退，易引发积压；建议按单条或小批次粒度提交
识别并拦截脏数据，防止进入业务主流程
脏数据（如 JSON 格式错误、必填字段为空、时间戳非法、编码乱码等）应在反序列化后、业务处理前就被捕获，不浪费资源执行无效逻辑。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 自定义反序列化器（如继承
StringDeserializer或JsonDeserializer），在deserialize()中校验字符串合法性，抛出明确异常（如IllegalArgumentException） - 消费者 poll 后，先做轻量级预检：检查
record.value()是否为 null、长度是否超限、是否包含明显乱码字符（如"锟斤拷"、""） - 对已知格式（如订单 JSON）使用 Jackson 的
ObjectMapper.readTree()预解析，捕获JsonProcessingException并归类为脏数据
主动暂停消费者 + 外部健康探测，避免线程忙等阻塞
当外部依赖（如数据库、HTTP 接口）不可用时，持续重试只会加重系统负担。此时应让消费“停下来”，而不是“卡住”。
- 捕获连接超时、服务不可达等可恢复异常后，立即调用
consumer.pause(consumer.assignment()) - 启动独立守护线程，以固定间隔（如 10 秒）探测依赖服务健康状态（如 GET /health）
- 探测恢复后，调用
consumer.resume()并触发一次poll(Duration.ZERO)清空内部缓冲，再回归正常循环 - 注意：暂停期间仍需保持心跳（
poll()仍要定期调用，哪怕传Duration.ZERO），否则会触发 rebalance
构建轻量级 DLQ 机制，而非依赖 Broker 原生能力
Kafka 本身没有死信队列，但你可以用一个专用 topic 承载无法处理的消息，并附带上下文信息便于排查。
- 定义一个 DLQ topic（如
order_dlq），结构与原 topic 一致，额外增加 headers：错误类型、堆栈摘要、时间戳、原始 topic/partition/offset - 在 catch 块中，将失败 record 封装后发送到 DLQ topic（用同步 producer，确保 DLQ 写入成功再继续）
- 设置最大重试次数（如 3 次），超过则发往 DLQ；也可按错误类型分流（网络类可多试几次，数据类直接进 DLQ）
- DLQ 消息保留周期设长些（如 7 天），配合定时任务或人工介入分析修复后重新投递
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
