关于GCP Pub/Sub启用死信队列后Sent与Ack指标异常的问询

核心原因：稳态下的指标平衡与拉取能力限制 #

你的现象是Pub/Sub在死信队列配置、订阅拉取QPS限制下形成的稳态结果，具体拆解如下：

1. 指标定义澄清

   • 发布QPS（12K）：主题每秒接收的新消息总数，每条新消息仅计数1次，符合预期。
   • Sent QPS（10K）：Pub/Sub每秒向订阅者交付的消息投递次数（包含初始投递和所有重试），每次投递单独计数。
   • Ack QPS（2K）：并非订阅者主动发送的确认（你未添加ACK逻辑，主动Ack为0），而是每秒进入死信队列的消息数——每条消息达到5次投递上限后，Pub/Sub会自动将其移至死信队列，同时标记原订阅中的该消息为“已处理”，计入Ack指标，每条消息仅计数1次。

2. 稳态数值推导
   订阅者被硬编码为每秒拉取12K条消息，Pub/Sub的投递能力被这个上限限制。每条消息需经过5次投递才会进入死信队列，系统最终达到稳态：

   • 每秒有2K条消息完成5次投递循环，进入死信队列（对应Ack=2K），这些消息的5次投递贡献了 2K × 5 = 10K 的Sent计数。
   • Sent（10K）+ Ack（2K）= 12K，恰好等于发布QPS，说明每秒新发布的12K条消息中，2K条完成全投递周期进入死信队列，剩余10K条处于第1-4次投递循环中，持续占用订阅者的拉取能力。

3. Sent未达12K的原因
   你之前假设Sent应等于发布QPS×5（60K），但忽略了订阅者的拉取QPS限制。订阅者每秒最多只能拉取12K条消息，Pub/Sub无法突破这个上限实现高频率投递，只能在拉取能力范围内动态调整进入死信队列的消息数，最终形成Sent=10K、Ack=2K的平衡状态，确保消息不丢失且流转稳定。

另外，确认超时设为10秒、重试策略为“立即重试”，加速了消息的循环投递，让系统更快进入稳态，避免消息堆积。

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