标准答案
- 常见原因包括永久格式错误、缺失资源、超出业务约束、版本不兼容和下游持续拒绝。
- 按错误类型设置有限次重试和延迟，超过阈值送入死信或隔离队列，避免一个分区被单条消息长期阻塞。
- 记录原始消息、失败原因、重试次数、版本和关联业务 ID，修复后支持安全重放。
- 对下游故障要配合熔断、限流和批量重试，不能把毒性消息处理器变成新的流量放大器。
题目解析
毒性消息会在每次重试中重复失败，阻塞分区或持续消耗下游资源。常见根因是永久格式错误、缺少数据、版本不兼容或业务约束不满足，不能用无限重试等待它自行变好。
应按错误类型设置有限重试和延迟，将持续失败消息连同原始内容、版本、重试次数和业务 ID 转入死信或隔离队列。隔离后仍要保持查询、审计和恢复能力。
修复后重放要限制范围、记录代码和 Schema 版本，并防止失败消息再次无限循环。下游暂时故障则应配合熔断和批量退避，而不是把所有失败都标为毒性。
常见误区
- 误区：无限重试并把错误日志打满。改正：设置次数和时间上限，按错误分类进入延迟重试或死信。
- 误区：直接删除无法处理的消息。改正：保留原始载荷和失败证据，使用隔离队列承载人工或修复后的重放。
- 误区：重放时仍使用导致失败的旧代码或旧 Schema。改正：记录版本并先在小批量环境验证兼容性。