启用排序键的Pub/Sub推送订阅：成功处理消息为何进入死信队列？

死信队列的触发条件 #

死信队列（DLQ）的触发不只是达到重试限制，以下场景也会直接导致消息进入DLQ：

• Pub/Sub向推送订阅的消费者端点投递消息时，收到无法重试的5xx错误（比如503服务不可用且无法恢复、500内部错误且端点明确无法处理），即使是第一次投递失败，也可能直接进入DLQ，无需等待重试次数耗尽。
• 推送订阅的Ack超时：如果消费者在Ack超时窗口内未返回Ack/Nack，Pub/Sub会重试投递，多次重试失败（达到重试限制）后才会送入DLQ，但你这里日志无超时记录，所以更可能是前者。

排序键对重试机制的影响 #

启用排序键后，同一排序键的消息会按顺序投递，但重试机制的核心逻辑和普通订阅一致：

• 单个消息的重试次数、退避时间不受排序键影响，仍遵循你配置的15次重试、最长10分钟退避规则。
• 同一排序键下某条消息重试失败会阻塞后续同排序键消息的投递，但这不会导致已成功处理的消息被重复送入DLQ。你遇到的“已处理消息进DLQ”更可能是重复投递导致的误判：
  Pub/Sub推送订阅可能因网络波动、端点延迟返回Ack，导致Pub/Sub判定投递失败并发起重试，此时消费者可能已成功处理了消息的早期投递实例，而后续重试的消息若遇到5xx错误，就会被送入DLQ，看起来像是“已处理的消息进了DLQ”，但实际是同一条消息的重复投递实例。

结合你的场景分析 #

你提到Pub/Sub存在少量5xx错误（每秒不足0.01次），这是关键诱因：

• 这些5xx错误是Pub/Sub向消费者端点投递时收到的，部分消息在第一次或几次重试时遇到这类无法恢复的5xx，直接被送入DLQ；而该消息的早期投递实例已经被消费者成功处理并Ack，因此出现“已处理消息进DLQ”的现象。
• 消费者日志无错误或超时记录，是因为成功处理的是消息的早期投递实例，而触发5xx的是后续重试实例——这部分请求可能未到达消费者（如网络层面的5xx），或者消费者返回5xx但日志未捕获到对应请求。

内容的提问来源于stack exchange，提问作者Gavin Haynes