Google 的基础架构旨在通过高度的扩缩能力实现弹性运营，让大多数层可以适应大规模增加的流量需求。实现这一理念的核心设计模式是自适应层，一种基于流量模式动态重新分配负载的基础架构组件。然而，这种适应需要时间。由于 Cloud Tasks 可以调度非常大量的流量，因此在流量攀升速度快于基础架构的适应能力的情况下，它会对生产造成风险。
概览
本文档提供了有关在高流量队列中保持高 Cloud Tasks 性能的最佳做法的指南。高 TPS 队列是每秒 (TPS) 创建或分派 500 个任务或更多任务的队列。高 TPS 队列组是总共创建或分派了至少 2000 个任务的一系列连续的队列，例如 [queue0001、queue0002、queue0099]。如需查看队列或队列组的历史 TPS，您可以使用 Cloud Monitoring 指标、“CreateTask”操作次数的 api/request_count 以及任务尝试次数的CreateTask。queue/task_attempt_count高流量队列和队列组容易出现两种不同类型的故障：
当任务创建和分派到单个队列或队列组的速度快于队列基础架构能够适应的速度时，就会发生队列过载。同样，当调度任务的速率导致下游目标基础架构中的流量达到峰值时，就会发生目标过载。在这两种情况下，我们建议遵循 500/50/5 模式，即当规模超过 500 TPS 时，每 5 分钟增加的流量不超过 50％。本文档分析了可能引入扩缩风险的不同场景，并提供了如何应用此模式的示例。
队列过载
流量突然增加时，队列或队列组可能会过载。因此，这些队列会发生如下情况：
- 任务创建延迟增加
- 任务创建错误率增加
- 调度率降低
为了防范这种状况，我们建议在会导致队列或队列组的创建或调度速率突然上升的任何情况下都建立控制。 我们建议每秒最多操作冷队列或队列组 500 次，然后每 5 分钟增加 50% 的流量。从理论上讲，使用这种渐增方案，90 分钟后可增加到每秒 74 万次操作。 这种状况可能在多种情况下发生。
例如：
- 启动大量使用 Cloud Tasks 的新功能
- 在队列之间移动流量
- 在更多或更少的队列中重新平衡流量
- 运行注入大量任务的批处理作业
在这些状况和其他情况下，请遵循 500/50/5 模式。
初始队列升速
500/50/5 模式适用于已处于稳定状态的队列。冷队列的初始升温是一个独立的过程，旨在安全地达到初始稳态。
当队列是新队列或处于空闲状态时，它不会立即以配置的 maxDispatchesPerSecond 速率调度任务。为保护您的系统免遭突如其来的流量高峰的侵扰，Cloud Tasks 会逐步提高调度速率。
如果您持续创建任务，系统最终会将调度速率提升到您配置的速率。不过，如果您的流量波动较大，任务爆发之间间隔超过一周的非活动时间，您可能会特别注意到这种加速行为。这是预期行为，可确保稳定性。
使用 App Engine 流量拆分
如果任务是由 App Engine 应用创建的，您可以利用 App Engine 流量拆分（标准/柔性）来顺利应对流量增加的情况。通过在多个版本（标准/柔性）之间拆分流量，需要进行速率管理的请求的处理速度可以逐渐加快，从而确保队列运行状况良好。例如，考虑将流量调整到新扩展的队列组的情况：让 [queue0000，queue0199] 成为一系列高 TPS 队列，在峰值时总共接收 100000 TPS 创建。
将