粗估與延遲數字
設計之前先算數量級:每秒幾個請求、要存多少資料、需要幾台機器。記住記憶體、SSD(Solid-State Drive,固態硬碟)、跨機房之間的延遲差了幾個數量級,就能很快看出哪個設計行不通。
例子
×1.0
×3
1/8
尖峰 QPS
6.9k
每年新增儲存
1.8 PB
尖峰頻寬(每秒)
3.3 GB
應用伺服器
7
大膽四捨五入:一位有效數字就夠。目標是數量級——需要一台還是一千台、是 GB 還是 PB——不是精確數字。
這個例子的假設:每日活躍使用者 10.0M 人、每人 20 次請求、讀取佔 95%、每筆資料 500 KB、保留 5 年、每台伺服器 1.0k QPS。
亮起來的是這一步執行的程式碼
type Input = { dau: number; actionsPerUser: number; readShare: number; objectBytes: number; retentionYears: number; peakFactor: number; serverQps: number; cacheShare: number;}; function estimate(i: Input) { const requestsPerDay = i.dau * i.actionsPerUser; const averageQps = requestsPerDay / 86_400; const peakQps = averageQps * i.peakFactor; const readQps = peakQps * i.readShare; const writeQps = peakQps - readQps; const writesPerDay = requestsPerDay * (1 - i.readShare); const storagePerYear = writesPerDay * i.objectBytes * 365; const storageTotal = storagePerYear * i.retentionYears; const peakEgress = readQps * i.objectBytes; const servers = Math.max(1, Math.ceil(peakQps / i.serverQps)); const cacheBytes = requestsPerDay * i.readShare * i.objectBytes * i.cacheShare; return { requestsPerDay, averageQps, peakQps, readQps, writeQps, writesPerDay, storagePerYear, storageTotal, peakEgress, servers, cacheBytes };}每個工程師都該知道的延遲數字
數字為約略值,來自 Jeff Dean 整理、Colin Scott 更新的版本(約 2020 年);長條是對數刻度,每一格是前一格的 10 倍。最右欄假裝 1 ns 是 1 秒。
| 操作 | 時間 | 對數刻度 | 如果 1 ns 是 1 秒 |
|---|---|---|---|
| L1 快取讀取 | 1 ns | 1.0 秒 | |
| 分支預測失誤 | 3 ns | 3.0 秒 | |
| L2 快取讀取 | 4 ns | 4.0 秒 | |
| mutex 加鎖/解鎖 | 17 ns | 17 秒 | |
| 主記憶體讀取 | 100 ns | 1.7 分鐘 | |
| 壓縮 1 KB | 2 µs | 33 分鐘 | |
| 從記憶體循序讀 1 MB | 3 µs | 50 分鐘 | |
| SSD 隨機讀取 | 16 µs | 4.4 小時 | |
| 從 SSD 循序讀 1 MB | 49 µs | 14 小時 | |
| 同一機房內來回一趟 | 500 µs | 5.8 天 | |
| 從硬碟循序讀 1 MB | 825 µs | 9.5 天 | |
| 硬碟尋軌 | 2 ms | 23 天 | |
| 美國加州到荷蘭來回一趟 | 150 ms | 4.8 年 |
模型假設與範圍
- 這是可重現的教學模型;延遲、容量、故障率與工作負載是設定或樣本,不能直接當作正式系統的效能承諾。
- 輸入採日平均、尖峰倍率與平均大小;GB/GiB 等單位依頁面定義。未包含流量長尾、壓縮、索引與營運預留的完整成本。
什麼時候用
- 系統設計面試的第一步:先問清楚使用者數和讀寫比例,算出 QPS 和儲存量,後面要不要快取、分片、CDN(Content Delivery Network,內容傳遞網路)才有根據。
- 評估一個新功能要多少機器、多少錢,或判斷某個設計在一百倍流量下會不會撐不住。
- 看到延遲數字就能判斷:一次請求裡做一百次跨機房呼叫(每次約 0.5 ms)就已經 50 ms,做不到 10 ms 的目標。
和其他主題的關係
時間與空間複雜度(Big O)
| 操作 | 平均 | 最差 |
|---|---|---|
| 一次估算 幾次乘除;難的是假設,不是計算 | O(1) | O(1) |
空間:O(1)
和其他做法比
| 尖峰 QPS | 讀:寫 | 每年儲存 | 尖峰頻寬 | 伺服器 | 快取 | |
|---|---|---|---|---|---|---|
| 照片分享 App | 6.9k | 6.6k : 347 | 1.8 PB | 3.3 GB/s | 7 | 19.0 TB |
| 聊天 App | 46.3k | 23.1k : 23.1k | 73.0 TB | 4.6 MB/s | 24 | 40.0 GB |
| 短網址服務 | 579 | 573 : 5.8 | 18.3 GB | 286 KB/s | 1 | 990 MB |
三個例子用上方相同的計算。差異一眼就看得出來:照片 App 的瓶頸是儲存和頻寬(每年 PB 級,該用物件儲存加 CDN);聊天 App 的請求最多但每筆很小,難在寫入量;短網址幾乎全是讀,一個快取就擋掉大部分流量。
真實世界裡的它
- Google 的 Jeff Dean 在演講中整理的延遲數字,後來成了工程師的共同參考。
- 容量規劃:雲端帳單、硬碟採購和機房電力都從這種估算開始。
取捨與陷阱
- 只算平均不算尖峰:晚上的尖峰常是平均的 2 到 5 倍,照平均配置的系統每天都會在尖峰時出事。
- 忘了副本:資料通常存 3 份,再加上備份和索引,實際空間是原始資料的好幾倍。
- 假裝精確:估算的價值在數量級,算到小數點後幾位只是浪費時間,也會讓人誤以為很準。