如何对Google Pub/Sub设置按小时/天粒度的消息吞吐量限流

Pub/Sub 原生不提供主题/订阅维度的小时级、日级固定吞吐量限制能力，其原生流控仅支持单客户端的短周期拉取/推送速率阈值、消息大小限制，无法直接对齐第三方API的长周期配额规则。

• 分布式消费端限流（精度最高）
  直接在pipeline #2的消费逻辑中接入分布式配额管控，不需要调整现有Pub/Sub链路结构：
  • 用Redis等支持原子计数、自动过期的集中存储，分别维护小时、日两个维度的剩余配额计数器，初始值和第三方API给到的配额完全对齐
  • 小时维度计数器设置为每整点自动重置，日维度计数器按业务要求的自然日/滚动24小时窗口自动重置
  • 所有pipeline #2实例在拉取新消息、调用第三方API前，先原子扣减对应计数器的剩余额度，扣减成功才处理消息；扣减失败则立即停止拉取新消息，等配额重置后再恢复消费
  • 不要提前批量拉取大量消息缓存在进程内，避免消息超出ack等待时长被重复投递。
• 前置匀速转发层（架构隔离性最好）
  在pipeline #1和pipeline #2之间加一层缓冲，从架构上挡住上游突增流量：
  • 新建一个仅供pipeline #2消费的独立Pub/Sub主题
  • 部署逻辑极简的转发服务，消费pipeline #1输出的原始主题消息，按照预留冗余的安全速率（比第三方API限流阈值低5%~10%）匀速转发到新的专属主题
  • 转发层不需要跟随积压动态扩缩容，固定少量实例即可。上游突增的流量会全部堆积在原始主题中，pipeline #2永远只会收到配额范围内的消息，从根源上避免超量调用API。
• 消费侧扩缩容硬限制（改造成本最低）
  适合限流精度要求不高的场景：
  • 关闭pipeline #2基于队列积压长度的自动扩缩容规则，提前压测单实例的小时/日处理能力，反推服务最大实例数、单实例最大并发数的硬上限，让整个pipeline #2的峰值处理能力略低于第三方API的限流阈值
  • 该方案精度较差，受消息处理耗时波动、实例性能波动影响可能偶发触发限流，需要搭配API调用的指数退避重试逻辑兜底。

通用兜底建议：无论采用哪种方案，都建议在调用第三方API时加入限流异常处理逻辑，收到429响应时不要立即重试，按响应要求的等待时间做退避，必要时将消息重新送回队列延后处理，避免连续触发限流导致API配额被临时封禁。

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