照着这份笔记补『容量估算』短板从 QPS 公式到存储带宽手算【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes系统设计面试里有一道几乎绕不过去的隐形门槛面试官问完需求后第一句话往往是Lets 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 年的经典对照操作延迟L1 缓存访问0.5 nsL2 缓存访问7 ns内存访问100 nsSSD 随机读150 µsHDD 随机寻道10 ms数据中心内往返500 µs跨区域数据中心150 ms这组数字直接决定了架构取舍内存快、磁盘慢所以尽量避免磁盘寻道跨网传输前先压缩。配合可用性数字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_id64 字节 文本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.md10 亿用户、人均每天收 40 封、每封元数据 50 KB得出730 PB/年20% 邮件带 500 KB 附件再叠加1460 PB/年。S3 对象存储24. S3-like Object Storage/README.md100 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.md2500 万月活全部参赛每条记录 24 字符 ID 16 位整数分数约 26 字节内存占用 ≈650 MB——一个 Redis 单机就装得下甚至翻倍考虑跳表开销也毫无压力。这个估算直接决定了用 Redis 有序集合而非关系数据库的选型。带宽与成本把 QPS 换成字节QPS 算的是请求次数带宽算的是字节流量两者之间只差一个乘数带宽 QPS × 单次请求字节数。笔记中最典型的带宽算例是 YouTube 的 CDN 成本14. Youtube/Readme.md5 万日活 × 人均 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 的完整梯度把它们排在一起对比量级感会迅速成型场景关键假设估算结果出处酒店预订5000 酒店、100 万间房、70% 入住、住 3 天约 24 万预订/天 ≈3 TPS22. Hotel Reservation System/README.md支付系统电商后端100 万笔/天 ≈10 TPS26. Payment System/README.md短链服务1 亿条生成/天、读:写 10:1、留 10 年3650 亿条 ≈365 TB7 位 Base62 支持 3.5 万亿 URL08. URL Shortener/Readme.md附近地点搜索1 亿 DAU、人均 5 次搜索/天≈5000 QPS16. Proximity Service/Readme.md广告点击聚合10 亿次点击/天、单条 0.1 KB均值1 万 QPS、峰值5 万 QPS100 GB/天、3 TB/月21. Ad Click Event Aggregation/README.md分布式邮件10 亿用户、人均发 10 封/天10 万封/秒23. Distributed Email Service/README.md搜索自动补全1000 万 DAU峰值4.8 万 QPS、新数据 0.4 GB/天13. Search Autocomplete/Readme.mdGoogle Maps10 亿 DAU、GPS 批量上报20 万 QPS、峰值 100 万 QPS地图瓦片约70 PB18. Google Maps/README.md这张表最有价值的地方在于估算结果直接长成架构决策。酒店预订 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 Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考