功率規劃和負載增長

簡短摘要

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和頭部，考慮外部限制，自動縮放和降級，測量「毫秒成本」，並進行定期的機會審查。然後，負載增長不會變成風險，而是變成可管理的業務指標。