企业官网建设流程全解析

照着这份笔记补『容量估算』短板：从 QPS 公式到存储带宽手算

【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insider's Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes

系统设计面试里有一道几乎绕不过去的"隐形门槛"：面试官问完需求后，第一句话往往是"Let's do some back-of-the-envelope estimation"。不少候选人能画出漂亮的架构图，却在"DAU 5000 万、人均每天发 2 条推文，QPS 到底多少"这种问题上卡壳——不是不会算，而是没有量级感，算出来的数字自己都不敢信。

容量估算（Back-of-the-Envelope Estimation）恰恰是这份笔记仓库的立身之本。作为基于《System Design Interview》系列书籍整理的开源笔记（仓库主页），它用 28 个章节覆盖了从单机扩展到股票交易所的完整设计链路，而几乎每一个章节都从容量估算起步：先算清楚规模，再决定技术选型。本文就把散落在各章节里的估算公式、真实场景题和复现方法抽出来，帮你把这块短板补上。

一、容量估算三件套：QPS、存储、带宽的手算公式

先锚定量级：2 的幂与延迟数字

估算的第一步不是背公式，而是建立"数字的坐标轴"。笔记第一章先给出了一张幂次表：1 字节 = 8 比特，1 KB = 1024 字节，1 TB = 2^40 字节 ≈ 10^12 字节，1 PB = 2^50 字节。有了这张表，"300M 用户 × 2 条推文"这类乘法才能落到具体的存储单位上，而不会把 MB 和 GB 混在一起算成四倍差距。


真正决定"估算准不准"的第二组锚点，是延迟数字（Latency Numbers Every Programmer Should Know）。笔记第 2 章给出了 2020 年的经典对照：

这组数字直接决定了架构取舍：内存快、磁盘慢，所以"尽量避免磁盘寻道""跨网传输前先压缩"。配合可用性数字（99% 每年约 3.65 天停机、99.999% 每年约 5.3 分钟），你就能在"要不要上缓存、要不要做多副本"上做出有数据支撑的判断，而不是凭感觉。

QPS：一切从「DAU × 行为频次」开始

QPS 是所有估算中最常用、也最容易被算错的一项。核心公式只有一行：

QPS = 日活用户数 × 人均每日操作次数 ÷ 86400（秒）

笔记里的 Twitter 案例是标准示范：第 2 章假设 3 亿月活、50% 日活，则 DAU = 1.5 亿；人均每天 2 条推文，代入公式得到 1.5 亿 × 2 ÷ 86400 ≈3500 QPS；再按惯例乘以 2 的峰值系数，得到峰值约7000 QPS。

注意两个容易被忽略的细节：一是"一天按 86400 秒还是 10 万秒"，笔记中酒店预订系统直接把一天取整为 10^5 秒来简化计算，这在量级估算中完全可接受；二是峰值系数——多数场景按平均值的 2 倍估算，但广告点击聚合这类突发场景笔记给出了 5 倍的峰值系数（见后文）。

QPS 还会向下游传导。酒店预订章节（22. Hotel Reservation System/README.md）展示了一个漂亮的"漏斗反推"：100 万间房、70% 入住率、平均住 3 天，算出每日约 24 万次预订，约合3 TPS——预订本身压力极低；但假设到达预订页需要 3 步、每步 10% 转化率，那么每 3 笔预订背后是 30 次预订页访问、300 次房型页访问，页面浏览 QPS 比写操作高两个数量级。这就是为什么读多写少的系统要把缓存和读副本放在第一位。

存储：单条数据 × 条数 × 留存周期

存储估算的公式同样简单：单条数据大小 × 数据条数 × 留存天数。关键难点在于拆解"单条数据"。

还是 Twitter 案例：一条推文拆成 tweet_id（64 字节）+ 文本（140 字节）+ 媒体（1 MB），其中 10% 的推文含媒体。于是每日媒体存储 = 1.5 亿 × 2 × 10% × 1 MB =30 TB/天，5 年留存即 30 TB × 365 × 5 ≈55 PB。一个 55 PB 的数字，直接告诉你"要不要用对象存储、要不要分层冷热数据"。

同样的拆解法贯穿全仓库：

• 分布式邮件（23. Distributed Email Service/README.md）：10 亿用户、人均每天收 40 封、每封元数据 50 KB，得出730 PB/年；20% 邮件带 500 KB 附件，再叠加1460 PB/年。
• S3 对象存储（24. S3-like Object Storage/README.md）：100 PB 数据按 20% 小对象（中位 0.5 MB）/60% 中对象（32 MB）/20% 大对象（200 MB）拆分，配合 40% 利用率反推出约6.8 亿个对象；元数据按 1 KB 计算，只需0.68 TB存元数据——于是"元数据和数据分库存储"的架构就有了数字依据。
• 游戏排行榜（25. Real-time Gaming Leaderboard/README.md）：2500 万月活全部参赛，每条记录 24 字符 ID + 16 位整数分数约 26 字节，内存占用 ≈650 MB——一个 Redis 单机就装得下，甚至翻倍考虑跳表开销也毫无压力。这个估算直接决定了"用 Redis 有序集合而非关系数据库"的选型。

带宽与成本：把 QPS 换成字节

QPS 算的是"请求次数"，带宽算的是"字节流量"，两者之间只差一个乘数：带宽 = QPS × 单次请求字节数。笔记中最典型的带宽算例是 YouTube 的 CDN 成本（14. Youtube/Readme.md）：

5 万日活 × 人均 5 个视频 × 0.3 GB × 0.02 美元/GB =15 万美元/天（按 Amazon CloudFront 计价）

这个数字的冲击力在于：带宽成本不是技术指标而是财务指标。它直接推导出笔记里那串成本优化手段——只有热门视频走 CDN、冷门视频从普通服务器分发、罕见访问的视频按需转码、自建 CDN 并与 ISP 合作。同样，Google Drive 章节（15. Google Drive/Readme.md）用"10 GB 免费空间、单文件最大 10 GB、人均每天上传 2 个 500 KB 文件"的假设推算出 500 PB 总量，进而决定引入 4 MB 分块、去重与冷存储分层。

二、用仓库中的真实场景题练习量级感

公式背熟了，还需要大量"真题"来建立直觉。仓库恰好提供了从几十 QPS 到十万级 QPS 的完整梯度，把它们排在一起对比，量级感会迅速成型：

这张表最有价值的地方在于：估算结果直接长成架构决策。酒店预订 3 TPS 意味着单库 + 读副本足够，只有假设场景放大到 booking.com 的 1000 倍、QPS 达到 3 万时，才需要按 hotel_id 分 16 片、每片 1875 QPS（数据库分片示意图）；广告点击 5 万峰值 QPS 意味着单机无法消化，必须上 Kafka 削峰 + 流式聚合，还要应对 30% 的年增长率和迟到/重复事件；排行榜 650 MB 内存意味着单台 Redis 即可支撑 2500 次/秒的写更新，但当用户量涨 10 倍到 5 亿 DAU，内存需求变为 65 GB、QPS 变为 25 万，就必须引入分片——而选 range 分片还是 hash 分片，又取决于"查 Top 10"和"查个人排名"这两个查询的权重。

酒店预订章节的 QPS 漏斗图完整演示了从"预订 TPS"到"页面浏览 QPS"的传导链条，是练习"把业务量翻译成流量"的最佳模板：


值得一提的还有监控系统章节（20. Metrics Monitoring and Alerting System/README.md）的写放大算例：1000 个服务器池 × 100 台机器 × 每台约 100 个指标 ≈1000 万个时序指标，这是典型的"写多读少、尖峰读取"负载，需要 8 核 32 GB 可支撑 25 万次写/秒的时序数据库（如 InfluxDB），并配合降采样（7 天原始精度 → 30 天 1 分钟粒度 → 1 年 1 小时粒度）来控制存储成本。Facebook 的研究数据（85% 的查询面向最近 26 小时）进一步佐证了"热数据优化"的价值。

三、把「数字感」练成肌肉记忆的复现方法

看完公式和案例，剩下的问题是：如何让"数字感"内化成肌肉记忆？笔记在第 2 章的 Tips 和后续每个案例的"估算-选型"对仗中，其实给出了可操作的复现方法。

方法一：三件套动作标准化。每次估算固定走三步——先写下全部假设（"300M MAU、50% DAU、人均 2 条"），再四舍五入简化计算（如 99987 ÷ 9.1 ≈ 100000 ÷ 10 = 10000），最后给每个数字标注单位（写 5 MB 而非 5）。笔记原文强调"精度不重要，过程才重要"，这套动作能把估算从"心算压力"变成"填空流程"。

方法二：对照重算，比较假设差异。这是复现成本最低的一步：不看答案，先按自己的假设重算一遍仓库里每个案例，再对照笔记看差异出在哪里。比如 URL 短链，笔记取"1 亿条/天、10 年"，于是 3650 亿条记录、365 TB 存储，7 位 Base62 编码提供 62^7 ≈ 3.5 万亿空间余量（08. URL Shortener/Readme.md）；如果你把假设改成"留存 5 年"，存储量立刻减半——差异往往不在计算能力，而在对业务量级的假设是否敏感。这种"差异归因"训练，比刷十道题更有效。

方法三：用结果反推选型，建立决策链。容量估算的终点不是数字本身，而是"数字 → 瓶颈 → 选型"的因果链。把仓库案例按这条链重述一遍：排行榜 650 MB → 内存装得下 → Redis 有序集合；S3 元数据仅 0.68 TB → 元数据/数据分库独立扩展；邮件 100 万封/秒 → 关系数据库出局 → 分布式文件系统 + 对象存储；广告 5 万 QPS → 单机不够 → Kafka + 流式聚合 + 窗口计算。能够不看笔记复述出这条链，数字感才算真正落地。

方法四：把估算嵌进面试节奏。仓库第 3 章（03. System Design Framework/Readme.md）给出的 45 分钟时间分配是：理解需求 3–10 分钟、高层设计 10–15 分钟、深入设计 10–25 分钟、收尾 3–5 分钟。容量估算属于高层设计阶段的前半程——这意味着你需要在 10 分钟内完成"澄清规模 + 计算量级 + 画出组件图"三件事。平时用手机秒表按这个节奏对着仓库案例做"15 分钟限时估算"，比慢慢推导更接近真实考场。

最后，给自己建一张量级锚点表，把仓库里反复出现的数字沉淀进去：QPS 个位数（酒店、支付）对应单机 + 单库；QPS 数千（附近地点、Twitter 推文）对应缓存 + 读副本；QPS 数万（广告聚合、自动补全）对应消息队列 + 流式计算；存储到 PB 级（邮件、S3、地图瓦片）对应对象存储 + 冷热分层。当你在面试中听到任何一个需求，第一反应不再是"套公式"，而是"先量级、再结构、后细节"——这就是容量估算从短板变成优势的时刻。

这份笔记仓库的价值正在于此：它不是一份只可远观的架构图集，而是一套"每个数字都能手算、每次选型都有依据"的训练场。沿着 第 2 章起步，把 28 个章节的估算过程全部亲手重算一遍，你收获的将不只是面试通关，而是真正可用于生产环境的容量决策能力。

【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insider's Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes