PubSub Push Subscription未确认消息数每小时突增问题及配置优化咨询

从你提供的运行指标判断，unacked 消息每小时突增的问题并非由 PubSub 推送速率不足导致。
你当前的推送平均速率仅5次/秒，待处理推送消息数始终小于1，推送 latency 稳定在50~150ms区间，远低于15s的Ack截止时间，说明PubSub侧的推送能力完全覆盖现有负载，不存在速率瓶颈。

你可以优先从两个方向定位根因：

• 检查上游消息生产规律：拉取PubSub主题的消息生产速率指标，核对每小时unacked突增的时间点，是否匹配上游批量写入消息的峰值，当瞬时生产速率远超当前5次/秒的推送速率时，就会直接出现unacked消息堆积。
• 检查链路层定时操作：确认Google负载均衡、K8s Ingress是否存在每小时固定执行的配置重载、证书更新、健康检查切换类操作，这类操作会导致瞬时推送请求失败，触发PubSub退避重试，退避窗口内消息暂不推送，直接推高unacked计数。

如果后续业务流量上涨需要提升推送速率、获得更高吞吐量，可以调整以下配置：

• 调高最大并发推送数：单Push订阅默认最大并发推送数为1000，你可以根据后端6个Pod的实际处理能力，修改maxConcurrentRequests参数，建议先调到200~500区间做压测验证。
• 优化退避策略：当前最小退避1s、最大退避8s的配置在偶发请求失败时会拉长推送间隔，若你的后端可用性较高，可以将最小退避调整为100ms，最大退避调整为2s，减少重试等待耗时。
• 缩短Ack截止时间：当前15s的Ack deadline远高于实际消息处理耗时，可以调整到1~2s区间，避免推送失败的消息长时间占用unacked配额，加快重试节奏。
• 配置流控阈值：开启订阅的flowControl配置，根据后端处理能力设置maxOutstandingMessages和maxOutstandingBytes阈值，在避免后端被瞬时流量打垮的前提下，最大化推送速率。

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