SQS架构下Worker达API配额时通知Distributor停发任务的最佳方案

现有架构背景 #

• 链路逻辑：Distributor服务从PostgreSQL检索过期数据投递到SQS队列，Worker消费SQS任务后调用第三方API拉取补充数据，该API存在固定调用配额限制
• 必选基础容错逻辑：单任务需要连续发起3次API请求才能拉取全量数据，任意一次请求失败（网络错误、接口报错、配额超限均包含在内），必须将任务重新插入PostgreSQL并设置更晚的过期时间，等待后续调度重试

各候选方案评估 #

• 方案2：通过SQS队列向Distributor发送停止信号
  不适合作为核心管控手段，两个核心问题的解决成本极高：
  • 信号冗余残留：停止信号如果在队列中滞留过久，会在配额恢复后被Distributor误消费，导致不必要的投递中断；如果给信号设置极短的可见性超时，又会在多实例部署场景下出现信号漏传
  • 多实例消费逻辑复杂：多台Distributor并行运行时，单条停止信号只会被其中一个实例消费，其余实例仍会持续投递任务，要实现全实例通知必须额外开发信号广播、多轮确认的特殊逻辑，链路复杂度陡增，故障排查难度高
• 方案3：Distributor投递前检查SQS队列长度
  生产环境无落地可行性：
  • SQS对外提供的队列长度统计指标ApproximateNumberOfMessages本身是近似值，存在约1分钟的统计延迟，根本无法实时感知队列堆积、配额超限的真实状态
  • 该指标只有在生产者停止投递后才会逐步收敛到准确值，等拿到可信的队列长度数据时，早已有大量任务被无效投递到队列中，进一步打满API配额，完全属于马后炮式的判断
• 方案4：基于数据库实现投递管控
  是适配现有架构的最优方案，完全复用现有技术栈，无额外运维成本，可靠性有明确保障

最优方案落地方式 #

不需要额外引入复杂分布式锁组件、不需要修改现有SQS核心通信逻辑，直接复用现有PostgreSQL即可实现：

1. 在PostgreSQL中新增一张单记录的系统配置表，仅需两个核心字段：
   • api_quota_paused：布尔类型，默认值为false，标记当前是否因API配额超限暂停任务投递
   • quota_reset_ts：时间戳类型，默认值为空，记录API配额恢复的准确时间
2. Worker侧逻辑调整：调用API时如果触发配额超限（通常为429状态码，或响应明确返回剩余配额为0），直接更新上述配置表记录：将api_quota_paused置为true，同时从API响应的Retry-After头中提取配额重置等待时长，计算出准确的quota_reset_ts写入表中。更新前做简单判断：如果库中已存在的quota_reset_ts晚于本次计算出的重置时间，则跳过更新，避免无效写操作
3. Distributor侧逻辑调整：每次轮询拉取待投递的过期任务前，先查询配置表记录：
   • 若api_quota_paused为false，正常拉取任务投递到SQS即可
   • 若api_quota_paused为true，对比当前时间与quota_reset_ts：未到重置时间则直接跳过本次轮询，不执行任务拉取投递；已到重置时间则将api_quota_paused改回false，恢复正常任务投递

落地优化建议 #

• Distributor侧的配置查询可以加5秒过期的本地缓存，不用每次轮询都直查数据库，5秒的延迟完全在可接受范围内，不会造成大量无效投递，还能降低数据库查询压力
• 所有任务重试逻辑统一走方案1要求的「重插PostgreSQL+延后过期时间」流程，不要为配额超限场景单独写特殊重试分支，避免逻辑碎片化
• 不需要为了该管控逻辑额外引入Redis、专用分布式协调组件等新依赖，现有PostgreSQL的单表单行读写性能完全能支撑多实例的调度检查需求

内容的提问来源于stack exchange，提问作者Daniel Kasabov-Nouvion