Google Cloud Pub/Sub订阅者未将未确认消息转发至死信主题问题求助

Pub/Sub死信配置不生效排查解决方案 #

1. 确认投递次数计数逻辑是否符合预期 #

执行以下命令查看滞留在订阅中消息的实际投递次数：

gcloud pubsub subscriptions pull <你的订阅ID> --auto-ack=false --limit=1

查看返回结果中的deliveryAttempt字段值，确认是否已经达到你设置的5次阈值。
注意：只有消息被显式NACK、或超过订阅设置的确认截止时间未做任何确认操作，才会被计数为一次有效投递尝试。如果你的客户端逻辑是长期持有消息不发送ack/nack，投递次数不会累加。

2. 手动核对死信主题权限 #

即使控制台显示配置验证通过，也请手动确认死信主题的权限配置：

• 服务账号格式为 service-<你的GCP项目编号>@gcp-sa-pubsub.iam.gserviceaccount.com
• 该账号必须被授予roles/pubsub.publisher权限
  控制台权限验证存在缓存延迟的可能性，手动核对可排除该类异常。

3. 适配订阅类型的特殊规则 #

• 推送订阅：只有推送端点返回非2xx状态码时，才会触发投递失败计数。如果你的端点返回了2xx状态码但实际未处理成功，消息不会被计入投递失败，不会触发死信转发。
• 精确一次投递订阅：需要确认死信策略是在开启精确一次投递之后配置的，配置顺序错误会导致死信规则不生效，可删除现有订阅重新按顺序配置。
• 有序投递订阅：确认同排序键下没有长期未确认的消息堵塞队列，导致目标消息的投递次数无法达到阈值。

4. 核对配置实际生效状态 #

执行以下命令查看订阅的实际生效配置：

gcloud pubsub subscriptions describe <你的订阅ID> --format="value(deadLetterPolicy)"

确认返回的maxDeliveryAttempts值确实为5，且deadLetterTopic字段指向正确的死信主题资源ID，排除配置同步延迟导致的设置未生效问题。

如果以上排查均无异常，可先删除订阅的现有死信配置，重新绑定死信主题后等待2-3分钟再做测试，GCP的配置全局分发存在秒级延迟，刚配置完成立即测试可能不会触发死信逻辑。

内容的提问来源于stack exchange，提问作者MQ.