功率规划和负载增长

简短摘要

1.需求预测（基本趋势+季节性+活动）。

2.负载模型（Internet的开放模型）。

3.安全余额（头部）和错误的预算。

4.缩放（地平线/垂直/自动）+限制器（rate-limit/backpressure）。

5.财务：$/1000 RPS, $/ms p95, TCO按场景。

术语和指标

Throughput：RPS/QPS/CPS-实际吞吐量。
Latency p95/p99：针对用户路径的目标的SLO。
Aturation： CPU/内存/IO/FD/连接/队列引导。
错误率：5xx/timeout/429，该期间预算错误。
Headroom：高峰时可用功率的比例（建议≥ 30％）。
Burst：短期飙升（秒/分钟），Spike：N ×急剧上升。

基本模型和公式

Little's Law（适用于排队系统）

L = λ W

L是系统中的平均请求数，λ是平均输入强度（RPS），W是系统上的平均时间。用于评估队列深度。

下载因子（ρ）

ρ = λ / μ

μ-服务速度（RPS在100% CPU）。ρ→1，潜伏期非线性增长-保持工作点ρ ≤ 0。6–0.75.

安全因素/库存

Capacity_required = Peak_load (1 + Headroom) Degradation_factor

其中Degradation_factor考虑到N故障，缓存退化，单个RoR/区域丢失（例如1。2).

需求预测

1.历史：白天/周概况，季节性，与事件的相关性（比赛/流/付款）。

2.Events： 脚本系数（通常一天× 1，比赛× 2。3、结局× 3。5).

3.波动来源：营销活动，发行版，机器人异常。
4.预测单位：路线（登录，lobby，catalog，payments），CPS TLS，QPS DB，磁盘的IOPS，egress Gbit/s。
5.信任：保持两个场景-保守和激进。

负载模拟

开放模型（类似Poisson的到来）：对于公共API/weba来说,这是合理的。
闭合模型（VU+思考时间）：适用于内部序列；结合起来。
路线混合：每个尾部的重量份额；不仅包括"热"，还包括"昂贵"（注册，存款）。
不要忘记：转发、队列、合作伙伴限制（PSP、第三方API）。

安全储备设计

Headroom目标：≥高峰30％（用于互联网）；对于支付核心和关键路径-40-50％。
N+1/N+2：在不违反SLO的情况下维持1-2个实例/区域的拒绝。
多区域：每个区域≥占总峰值的60％（以度过邻居的损失）。
Degrade模式：禁用次要功能,减少付费,包括缓存/回应。

逐层排序

网络/边缘

前部的CPS/RPS，TLS-handshake p95，resumption≥70％，egress Gbit/s。
Anycast/Geo-routing，CDN/WAF限制（事先同意）。
库存：link/applink ≥ peak × 1。3、SYN backlog与H3 UDP/443库存。

平衡器/代理

实例上的RPS，开放连接，队列，CPU/IRQ。
Keepalive和connection pooling-减少与后端的连接。

库存： ρ ≤ 0。7, limiter по CPS/RPS per route.

应用程序

高原中每个内核的目标性能（RPS/core）。
池（thread/DB/HTTP）-不设限制。
库存：到CPU 60-70％和latency-trigger（p95）的自动轨距。

缓存

Hit-ratio，hotset体积，eviction，复制品。
库存：内存≥ 1。2 ×热门，网络头部≥ 30%。

数据库

QPS/TPM, p95请求,锁定,缓冲区,WAL/replag。
IOPS和后坐力驱动器是p95的关键。
库存：CPU工作点50-65％，复制版脱落<目标；sharding和read-replicas计划。

驱动器/存储

IOPS (4k/64k), throughput, fsync cost.

库存：IOPS ≥高峰× 1.5,目标窗口中的latency p95；日志/数据下的各个池。

GPU/ML（如果有在线地狱）

Samples/s, latency, VRAM headroom, batching.

库存：负载"锯"下的击球参数，warm-pool GPU。

自动缩放

HPA/KEDA：CPU+定制指标（p95 latency，RPS，队列）。
Warm pools：在活动之前预热实例。
步长：带有cooldown的台阶，以免被"锯"。
反应时间：接吻T_scale ≤ 1-2分钟前层；对于DB-提前。

限制器和后压

Rate-limit по IP/ASN/device/route;合作伙伴配额。
与TTL排队，拒绝比taymauts早"礼貌"（429/via gray-wol）。
相似性：支付钥匙；带有budget+jitter的复制品。
请求合集/SWR：在激增期间不要唤醒起源。

快速计算示例

给出：API的35k RPS峰值预测，p95 250毫秒，实例的平均服务时间8毫秒，CPU的60％ RPS/core，实例的8个内核 1000 RPS/实例。
步骤1（无余地）：35例。

步骤2 （headroom 30%）： 35 × 1。3 = 46.

步骤3（一个AZ失败，+20％）： 46 × 1。2 ≈ 55.

步骤4（四舍五入+热备用10％）：61例。
检查：ρ ≈ 35k/（ 61 k）≈ 0。57-在绿区。

金融模型（FinOps）

每层$/1000 RPS （edge、proxy、app、DB）。
$/ms p95（减少尾巴的成本）。
脚本TCO：按需与reserved vs spot（有中断风险）。
容量计划：季度帐户/集群限制，云配额，PSP/CDN限制。

故障准备和DR

Multi-AZ/region：每个肩膀≈ 60%的负载。
失败计划：withdraw Anycast，GSLB切换，TTL ≤ 60-120 s。
关键依赖性：PSP/银行限制，二级提供商。
定期练习：游戏日，PoP/BG/缓存关闭。

早期饱和的可观察性和信号

p95/p99的增长和队列在稳定的输入。
高速缓存的命中率下降，起源的增长。
Retransmits/ECN CE的增加，TLS的恢复下降。
身高429/timeout和retry-rate。
对于DB，冲突增加，checkpoint时间，WAL fsync。

操作实践

每月Capacity评论：事实vs计划。
在活动下更改Windows：内核和限制的冻结。
Prewarm（CDN/DNS/TLS/池）在峰值前10-30分钟。
极限测试：在Git中捕获极限/池的configi。

iGaming/fintech的细节

比赛/比赛：spike+plateau配置文件，机器人灰色路线，单独的注册/存款限制。
付款/PSP：提供商/方法配额，后退路由，egress-IP池，SLA时间到钱包。

内容提供商： 分发工作室,热缓存,shard池.

Antifrod/AML：规则/得分限制，高峰时降级为轻规则。

实施支票

• 高峰预测（基数/季节/活动）,两种情况。
• SLO/有缺陷的预算和目标头部 ≥ 30％。
• 按图层分组（edge/proxy/app/cache/DB/IO/网络）。
• 限制：rate-limit,队列,idempotency, retry-budget。

[] HPA/KEDA + warm pools;在活动前展开的计划。

• Multi-AZ/region，failover-playbooks，TTL和GSLB。
• 云配额/PSP/CDN保持一致并记录下来。
• 可观察性：可见性减震板，早期饱和信号。
• DR演习和定期的机会审查。

典型错误

没有尾巴/尖峰的平均RPS计划。
ρ≈0.9"纸上"-潜伏期在微小的噪音下爆炸。
忽略外部服务限制（PSP/CDN/DB群集）。
没有阶梯模式，反向压力是级联的。
没有预热的汽车规模-在峰值之后"跟上"。
所有层的单个头部-瓶颈迁移。

迷你花花公子

高峰事件发生前（T-30分钟）

1.增加minReplicas/target HPA，启用战争池。
2.加热CDN/DNS/TLS/连接器,加热缓存。
3.通过安排提高池限制和PSP配额。
4.打开灰色路线/机器人过滤器，缩小重型终端。

区域部分损失

1.GSLB →邻近地区，TTL 60-120 s。
2.启用degrade模式（缓存/简化发行）。
3.重新分配PSP/egress-IP限制。
4.状态通信，p95控制/错误。

回避激增

1.减少retry-budget,启用backoff+jitter。
2.在GET上启用request-collapsing/SWR。
3.暂时收紧"嘈杂"ASN的限额。

结果

功率规划是需求预测+工程模型+安全余量+操作杠杆。正式化SLO和头部，考虑外部限制，自动缩放和降级，测量"毫秒成本"，并进行定期的机会审查。然后，负载增长不会变成风险，而是变成可管理的业务指标。