GCP Pub/Sub未投递消息数无变化，关联Cloud Function最大实例限制为10故障排查

1. Pub/Sub推送触发的退避重试机制 #

• 当Pub/Sub推送请求因为Cloud Function达到最大实例数返回429错误时，Pub/Sub会自动启动指数退避策略，对推送失败的消息延长重试等待时间，这段等待期内的消息会被计入num_undelivered_messages指标，不会被重新投递，也不会因为其他消息的ack被扣除。
• 你场景中1:01的1000条消息峰值触发了大量429错误，大部分消息被设置了较长的退避等待窗口（最长可达数分钟），这是1:01-1:10期间未确认消息数没有下降的核心原因。

2. 两类计数的统计逻辑差异 #

• 观测到的ack_message_count是Cloud Function侧上报的已完成处理的消息ack总数，统计的是已经处理完成的存量消息；
• num_undelivered_messages是Pub/Sub订阅侧的全量未完成处理消息统计，包含三类：已投递待ack的消息、等待推送的消息、处于退避等待期的推送失败消息。所以在大量消息处于退避等待期时，就算持续有存量消息ack完成，整体未确认数也不会出现明显下降。

3. 限流后的推送速率恢复延迟 #

• 当Cloud Function持续触发实例数限流时，Pub/Sub会自动降低对该函数的推送速率，避免过多429错误；需要等到退避窗口陆续到期、推送速率逐步恢复后，大量积压的消息才会被批量投递处理，对应观测到的1:10之后未确认数快速下跌的现象。

• 适当调大Cloud Function的最大实例数上限，减少峰值场景下的429错误触发概率；
• 在Pub/Sub订阅配置中手动调整重试策略，缩短最大退避等待时间，避免消息积压时间过长；
• 如果允许消息处理有一定延迟，也可以保持现有配置，该现象属于Pub/Sub和Cloud Function联动的正常限流保护行为。

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