如何构建同时读取主题与死信队列、系统恢复后回灌消息的流水线

方案1：手动重投递（适合应急/小批量消息场景） #

• 提前为死信主题创建1个拉取类型的订阅，不要配置PUSH触发，避免故障期间消息被错误消费
• 确认原服务恢复可用后，可通过两种方式重发：
  • 控制台操作：进入死信拉取订阅的「消息」页，选中需要重发的消息，点击原生的「重新发布到主题」按钮，选择原主题即可完成投递
  • 命令行操作：执行以下gcloud命令批量拉取并重发，注意替换占位符内容：

    gcloud pubsub subscriptions pull 你的死信拉取订阅ID \
      --auto-ack --limit=100 --format="value(message.data,message.attributes)" | \
      xargs -I {} gcloud pubsub topics publish 你的原主题ID --message "{}"
    

方案2：自动化重投递（适合生产级常态化场景） #

• 开发一个轻量的重投递专用云函数，触发方式绑定死信主题的PUSH订阅
• 给该云函数配置1个REDELIVER_ENABLE环境变量作为开关：
  • 原服务故障时，将变量值设为false，云函数收到死信消息后直接返回nack，消息会保留在死信订阅中（需确保死信订阅消息保留时长配置符合你的需求，最长支持7天）
  • 原服务恢复后，将变量值设为true，云函数收到死信消息后会原封不动保留所有元数据（消息属性、发布时间等）发布到原主题，完成投递后返回ack即可
• 该方案无需人工介入操作，仅需修改环境变量即可触发批量重投递，适合消息量较大的生产环境

优化建议 #

• 死信队列建议搭配监控告警使用，配置死信主题消息入库的告警规则，服务故障第一时间收到通知
• 原服务必须做好消费幂等判断，Pub/Sub本身为至少一次投递模型，重投递过程中可能出现重复消息，幂等逻辑可以避免业务数据异常
• 若需要超过7天的消息留存，可以额外配置死信订阅的转储规则，将消息同步归档至Cloud Storage，避免消息过期丢失

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