Pub/Sub触发Cloud Functions动态创建Cloud Tasks队列及分配任务避延迟方案咨询

Cloud Tasks单队列官方最高调度上限为Max dispatches per second=500、Max concurrent dispatches=1000，和你当前配置一致，无法通过单队列参数调整突破该限制，必须通过多队列拆分承担流量。

• 热队列：提前预创建的固定队列，长期保持可用状态，配置为单队列上限参数，用于承接常态、峰值流量
• 冷队列：流量突增超过热队列承载上限时才动态创建的临时队列，配置和热队列完全一致，任务清空后可自动销毁释放资源

• 预创建热队列数量：按你当前峰值每秒10000个任务计算，需要至少20个热队列（20 * 500QPS = 10000QPS），提前全部创建完成，避免动态创建队列的耗时导致任务调度延迟
• 冷队列触发规则：实时监控所有热队列的待处理任务积压数，当所有热队列的待处理任务数超过单队列并发阈值的80%（即单队列待处理>800）时，触发冷队列创建，每次创建2个，直到所有可用队列的平均待处理积压低于50%
• 冷队列销毁规则：当冷队列的待处理任务数为0，且持续10分钟无新任务进入，自动删除该冷队列
• 配额控制：队列总数量不要超过项目Cloud Tasks默认配额的80%（默认单项目配额为100个队列，即最多保留80个队列），避免配额不足导致任务创建失败

• 常态流量分配：Cloud Function收到Pub/Sub消息后，按消息ID做哈希取模，均匀分配到所有热队列中，避免单队列负载过高
• 突增流量分配：当热队列全部处于高负载状态时，新任务优先按哈希分配到已创建的冷队列中
• 高优先级任务特殊分配：如果存在延迟敏感的高优先级任务，直接分配给当前待处理任务最少的可用队列，不按哈希规则分配，保障调度及时性

• 所有队列统一配置和你现有参数对齐：Max dispatches per second=500、Max concurrent dispatches=1000、Max attempts=5
• Cloud Function侧缓存队列列表：将热队列、可用冷队列列表存在Cloud Function的内存缓存中，冷队列创建/销毁时异步更新缓存，不要每次分配任务都调用API拉取队列列表，减少额外耗时
• 阈值可调整：你可以根据实际压测结果调整热队列扩容触发的积压阈值，匹配你的业务可接受延迟要求即可

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