kafka消费失败须区分临时故障与永久错误：临时故障抛retriableexception触发重试，永久错误发dlq；需关闭自动提交、增大max.poll.interval.ms，并用retry topic分级延迟重试，配合幂等与手动提交offset。
Java 中 Kafka 消费失败不能靠“随便抛异常”来重试，必须区分临时故障和永久错误，并配合正确的配置与设计才能真正落地可靠的重试机制。
明确失败类型，决定是否重试
不是所有异常都该触发重试。Kafka 会把 RetriableException 子类识别为可恢复的临时问题，比如网络抖动、下游超时、副本同步延迟；而 JSON 解析失败、主键冲突、空字段校验不通过等属于永久性错误，重试毫无意义，应直接进死信队列（DLQ）。
- 对临时故障：包装成标准子类，如
new TimeoutException("downstream timeout")或new NetworkException("redis connect failed") - 对永久错误：记录日志 + 发送至 DLQ Topic，避免阻塞消费进度
- 不要在 catch 块中吞掉 RetriableException —— 吞掉就等于告诉 Kafka “这条处理成功了”
配置消费者支持重试语义
只抛异常还不够，以下 consumer 配置是重试生效的前提：
-
enable.auto.commit=false：必须关闭自动提交，否则异常前 offset 已提交，消息就丢了 -
max.poll.interval.ms要设足够大：单条消息重试可能拉长处理时间，太小会导致消费者被踢出 Group - 使用 Spring Kafka 时，推荐配置
RetryingErrorHandler（单条）或RetryingBatchErrorHandler（批量），指定最大重试次数和退避策略，例如 5 次、每次间隔 1 秒
用自建重试 Topic 实现可控延迟重试
Kafka 原生重试无延迟、无次数限制，容易引发雪崩。更稳妥的做法是业务端主动投递到专门的 retry topic：
- 消息体中携带原始 key、retryCount、失败时间、错误原因等上下文
- 按重试次数分层：retry-topic-1m、retry-topic-5m、retry-topic-30m，由定时任务或调度服务触发再投递
- retryCount 达到阈值（如 3 次）后，不再重试，转入 dead-letter-topic
- 避免用 Redis zset 等外部存储做重试调度——增加系统依赖和故障点；优先用 Kafka + 定时任务或轻量调度器
必须配套幂等与可靠提交
无论重试怎么设计，重复消费都是 Kafka 的默认行为。所以：
- 业务写入必须有幂等键，例如以
message_id或order_id为唯一索引，防止重复下单、重复扣款 - offset 提交必须在业务逻辑成功后执行：
commitSync()用于强一致性场景，commitAsync()需配回调兜底 - 死信消息不能当垃圾桶：DLQ 要带分类字段（如 error_type: format_error / business_conflict），方便告警分派与人工介入
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
