QPS 估算计算器

QPS（每秒查询数）估算的经典公式：平均 QPS = DAU × 人均请求数 ÷ 86400 秒。100 万 DAU、人均 20 次请求，平均 QPS = 231。但流量不是匀速的——早晚高峰、整点推送、突发热点让峰值 QPS 达到平均的 2-5 倍（峰值系数），电商大促甚至 10 倍+。所以容量公式是：峰值 QPS = 平均 QPS × 峰值系数，再按「单机能扛的 QPS」推算机器数，最后乘冗余系数（N+1 或 N+2）。

二八定律的修正项：80% 的流量集中在 20% 的时间里（约 4.8 小时），按这个模型峰值均值比 ≈ 4——与经验系数吻合。更精细的估算要分「读」与「写」：读多写少（内容类 100:1）可以缓存扛读、库扛写；还要注意「扇出系数」——一次用户动作可能触发多个内部 RPC（feed 流一次刷新扇出 5-10 个下游调用），网关 QPS 与下游 QPS 要分开算。本工具支持 DAU 模型、二八模型、自定义峰值三种估算，并输出机器数量建议。

86400 秒的均匀假设是第一层近似，真实流量曲线必须看业务画像：工具类（文档、网盘）峰值集中在工作日上午，系数 2–3；内容类（资讯、视频）早晚双峰，系数 3–4；社交与外卖有极强的饭点与夜宵峰，系数 4–5；电商大促是人工制造的极端峰，系数 10 起步。估算时先对号入座选系数，再按历史监控逐年修正——系数选错，后面所有乘法都是错的。

单机容量必须实测，不能看理论值：压测时逐步加并发，找到「响应时间开始非线性上升、错误率开始冒头」的拐点，取拐点 QPS 的七折作为生产容量——留的三折是给慢查询、GC 抖动与流量毛刺的缓冲。压测要覆盖真实读写比例与数据规模，空表压出来的数字没有意义。容量水位与延迟的换算可配合 API 延迟预算计算器 一起定。

读写与扇出必须分账：读多写少的业务（内容类常见 100:1），读流量可以用缓存与 CDN 承接，命中率 95% 时数据库只承受 5% 的读压；写流量无捷径，直接落在数据库与消息队列上。扇出是隐藏放大器：一次用户请求触发 N 次内部 RPC，网关 500 QPS 可能意味着下游 4000 QPS——两张表分开记，容量评审才不漏项。并发与线程池的换算走 利特尔法则计算器。

冗余系数买的是「计划内 + 计划外」两类事件：计划内是滚动发布（发布期间每批机器下线）、容量压测；计划外是单机宕机、机架断电、可用区故障。N+1 是最低配置（多 1 台），跨可用区部署时按「任意一个区全灭，剩余区仍能扛峰值」计算——这通常等效于每个区按 60–70% 水位运行。冗余与可用性目标的换算见 错误预算计算器。

估算的三个反模式：① 用日请求量直接除以 3600 当峰值（忘了 24 小时与活动小时的差异）；② 只看平均值不看峰值（容量是给峰值准备的）；③ 估完一次管三年（业务每季度都在变）。纪律是：估算表写清假设（DAU、人均、系数），每季度用真实监控回归校准一次，大促前一个月专项复估——容量估算的价值不在精确，在于让偏差可发现、可修正。