Back of the Envelope Estimation

Back of the Envelope Estimation #

概述 #

在系統設計面試中，我們經常需要快速估算系統的容量與效能需求。這種「信封背面估算」(Back-of-the-envelope Estimation) 能幫助我們在短時間內評估系統的可行性。

基礎知識 #

1. 2 的冪次 (Power of Two) #

由於電腦採用二進位設計，我們習慣用 2 的冪次來表達數據規模：

次方	約略值	全名	縮寫
10	1,000	1 Kilobyte	1 KB
20	1,000,000	1 Megabyte	1 MB
30	1,000,000,000	1 Gigabyte	1 GB
40	1,000,000,000,000	1 Terabyte	1 TB
50	1,000,000,000,000,000	1 Petabyte	1 PB

提示：1 byte = 8 bits，1 個 ASCII 字元占用 1 byte

2. 常見操作的時間延遲 #

了解各項操作的執行時間，有助於判斷系統瓶頸：

操作	所需時間
L1 快取參照	0.5 ns
分支預測錯誤	5 ns
L2 快取參照	7 ns
Mutex lock/unlock	100 ns
主記憶體參照	100 ns
壓縮 1 KB 資料 (Zippy)	10 µs
透過網路傳送 2 KB 資料	20 µs
從記憶體讀取 1 MB 資料	250 µs
資料中心間往返延遲	500 µs
硬碟隨機讀取	10 ms
從硬碟讀取 1 MB 資料	30 ms
資料封包跨洲際往返	150 ms

關鍵要點：

記憶體存取速度遠快於硬碟（約 100,000 倍）
盡量避免硬碟隨機讀取
壓縮演算法執行快速，傳輸前壓縮資料可節省時間
跨資料中心通訊成本高昂

3. 可用性 (Availability) #

可用性衡量系統正常運作的時間比例，通常以「幾個 9」來表示：

可用性 (%)	每天停機時間	每月停機時間	每年停機時間
99%	14.40 分鐘	7.31 小時	3.65 天
99.9%	1.44 分鐘	43.83 分鐘	8.77 小時
99.99%	8.64 秒	4.38 分鐘	52.60 分鐘
99.999%	864 毫秒	26.30 秒	5.26 分鐘
99.9999%	86.40 毫秒	2.63 秒	31.56 秒

實戰範例：估算 Twitter 的 QPS 與儲存需求 #

前提假設 #

每月活躍使用者：3 億
每日活躍使用者比例：50%
使用者平均每日發文：2 則
含多媒體的推文比例：10%
資料保存期限：5 年

QPS 估算 (Queries Per Second) #

計算每日活躍使用者 (DAU)：

DAU = 300M × 50% = 150M

推文 QPS：

推文 QPS = 150M × 2 推文 / 86,400 秒 ≈ 3,500

峰值 QPS（通常取平均值的 2 倍）：

峰值 QPS ≈ 7,000

儲存需求估算 #

單則推文大小：

推文 ID：64 bytes
推文內容：140 bytes
多媒體（圖片/影片）：平均 1 MB

每日儲存需求：

每日儲存 = 150M × 2 × 10% × 1 MB = 30 TB

五年儲存需求：

五年儲存 = 30 TB × 365 × 5 ≈ 55 PB

估算技巧與最佳實踐 #

核心原則 #

善用約略值
計算不需過於精準，使用 10^3 近似 2^10 可加快計算速度
明確記錄假設
將假設條件寫下來，避免遺忘，也方便與面試官確認
標註單位
數字後務必加上單位（KB、MB、秒、QPS 等），避免混淆
由上而下思考
先從大方向估算，再逐步細化
熟記常見指標
- QPS / TPS
- 峰值流量（通常是平均值的 2-10 倍）
- 儲存容量
- 頻寬需求
- 快取命中率

常見估算場景 #

使用者活躍度：DAU、MAU、在線時長
流量估算：QPS、TPS、峰值流量
儲存估算：資料大小、成長率、保存期限
頻寬估算：上傳/下載速率、CDN 流量
伺服器數量：基於 QPS 和單機處理能力

小結 #

Back-of-the-envelope estimation 是系統設計面試的基本功，透過合理的假設與快速計算，我們能在幾分鐘內評估系統的規模與挑戰。記住：精確度不是重點，合理性與思考過程才是關鍵。