从日活到机器数：容量估算的草稿纸算法
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 0 · 度量与估算 · 第 2/49 篇 · 🚧 占位待学
上一篇：《流量的语言：QPS、RT 与并发数的三角关系》
下一篇：《亿级消息解剖：吞吐、堆积与存储三笔账》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 0 · 单元 0.2
一、本文要解决的问题
产品说「明年日活翻十倍」，你要加多少机器、多少内存、多少带宽？架构评审第一问永远是数字，画不出账本的架构图只是艺术品。这篇要把「拍脑袋」变成「草稿纸推演」。
二、知识点清单
- DAU → 请求量的推导链：人均请求数、请求模型（打开 App 干什么、调多少接口）
- 二八法则与峰值系数：为什么峰值 QPS 通常按日均值 × 3 ~ 5 估（大促另算）
- 存储估算：一条数据多大 × 日增多少条 × 存多久 × 副本数与索引放大
- 带宽估算：请求/响应体大小 × QPS，上下行分开算
- 机器数公式：总峰值 QPS ÷（单机安全 QPS × 水位系数 0.5 ~ 0.7），向上取整加冗余
三、动手实验（学习时必须真跑）
- 拿一个熟悉的 App（微博 / 淘宝 / 王者荣耀）做完整推演：公开 DAU 数据 + 合理假设，算出日请求量、峰值 QPS
- 继续推：核心链路需要多少台 4C8G 应用服务器、Redis 集群多大内存、MySQL 多少容量
- 把自己的估算与网上流传的真实架构数据（如微博技术分享）对比，检验偏差
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。