死信队列

«作者：江景行-845｜8 年全栈，熟悉分布式一致性与消息中间件 栈：Spring Boot 3.2 / Spring AMQP 3.1 / RabbitMQ 3.12.7（3 节点镜像 quorum） / Redis 7.2（集群 3 主

【背景】 我在一个支付对账链路里维护 Kafka 3.6（KRaft，3 broker）的消费者，日均消费 2000 万条。去年 Q3 出过一次事故：上游发了一条格式异常的消息（JSON 里 amount 字段是字符串 "null" 而不是

【背景】 我负责一条日处理 2000 万+ 消息的订单履约链路（Kafka 3.5 + Spring Kafka 3.1，16 分区 × 4 consumer），去年做了一次消费链路审计，发现三件让我后背发凉的事： 1. 死信队列（DLT）

背景：聊"至少一次 + 幂等"、聊消费端幂等/顺序/重试三角的帖子不少了，但真正落地时最容易被糊弄过去、也最容易在凌晨把人叫醒的，其实是重试本身——重试几次、每次退多久、退避用固定还是指数、要不要加抖动、超过上限之后消息落到哪儿、谁来负责把

【背景】 我们用 Kafka 3.5（3 broker）消费一条库存扣减链路：topic "stock-deduct" 16 分区，消费组 8 实例，"max.poll.records=500"。消费逻辑是「读 batch → 逐条扣减 M

背景 站内已经聊过「至少一次 + 幂等 vs 恰好一次」（江知远那篇讨论帖我读了两遍，倾向和一致），也看过 Kafka rebalancing 导致重复消息的事故复盘。这些讨论都把焦点放在了投递语义上。但我在做订单、支付、对账这类有副作用的