Google Cloud Tasks事件队列请求超时问题排查求助

项目配置 #

automatic_scaling:
  min_instances: 1
  max_instances: 6
  max_pending_latency: 15s

inbound_services:
- warmup

任务配置 #

• Slack事件队列（events）：处理需3秒内完成的Slack事件，配置参数：--max-dispatches-per-second=500、--max-concurrent-dispatches=60
• 定时通知任务：两个cron任务，执行时间为1 * * * *和30 * * * *，负责发送用户通知，对速度要求低，配置参数：--max-dispatches-per-second=10、--max-concurrent-dispatches=2

当前问题 #

每小时整点和半点时，events队列大量出现错误：Request was aborted after waiting too long to attempt to service your request.，其他时段无此问题；已降低通知队列的配置，但问题仍存在。需要在不增加max_instances的前提下解决该问题。

优化方案 #

1. 调优自动扩缩容策略，提升扩容灵敏度 #

• 缩小max_pending_latency阈值：比如从15s改为5s，让系统在请求等待时间较短时就触发扩容，避免请求堆积超时
• 添加target_utilization参数（比如设置为0.7），当实例CPU/内存使用率达到70%时就开始扩容，提前应对负载增长
• 配置min_idle_instances：比如设置为2，保留一定数量的预热完成的实例，直接应对突发的双重负载（定时任务+events事件）

2. 调整任务优先级，保障高时效队列资源 #

• 将events队列设置为高优先级，让实例优先处理该队列的请求。当定时任务占用实例时，高优先级的events请求会抢占处理资源，减少等待超时的概率
• 给定时任务配置更低的资源权重，比如限制每个定时任务的CPU/内存使用量，降低其对实例资源的占用程度

3. 微调定时任务执行时间，错开流量高峰 #

• 将两个定时任务的执行时间微调，比如改为2 * * * *和32 * * * *，避开整点/半点可能的其他潜在流量高峰，减少与events队列的资源竞争

4. 优化定时任务执行效率 #

• 合并两个定时任务为一个，减少同时启动的任务数量，降低瞬间的资源占用
• 优化定时任务的代码逻辑，缩短单个任务的执行时间，让实例更快释放资源回给events队列

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