跳到主要內容

系統設計

把資料結構放大到好幾台機器

主題 · 粗估與延遲數字

粗估與延遲數字

設計之前先算數量級:每秒幾個請求、要存多少資料、需要幾台機器。記住記憶體、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 KB2 µs
33 分鐘
從記憶體循序讀 1 MB3 µs
50 分鐘
SSD 隨機讀取16 µs
4.4 小時
從 SSD 循序讀 1 MB49 µs
14 小時
同一機房內來回一趟500 µs
5.8 天
從硬碟循序讀 1 MB825 µ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讀:寫每年儲存尖峰頻寬伺服器快取
照片分享 App6.9k6.6k : 3471.8 PB3.3 GB/s719.0 TB
聊天 App46.3k23.1k : 23.1k73.0 TB4.6 MB/s2440.0 GB
短網址服務579573 : 5.818.3 GB286 KB/s1990 MB

三個例子用上方相同的計算。差異一眼就看得出來:照片 App 的瓶頸是儲存和頻寬(每年 PB 級,該用物件儲存加 CDN);聊天 App 的請求最多但每筆很小,難在寫入量;短網址幾乎全是讀,一個快取就擋掉大部分流量。

真實世界裡的它

  • Google 的 Jeff Dean 在演講中整理的延遲數字,後來成了工程師的共同參考。
  • 容量規劃:雲端帳單、硬碟採購和機房電力都從這種估算開始。

取捨與陷阱

  • 只算平均不算尖峰:晚上的尖峰常是平均的 2 到 5 倍,照平均配置的系統每天都會在尖峰時出事。
  • 忘了副本:資料通常存 3 份,再加上備份和索引,實際空間是原始資料的好幾倍。
  • 假裝精確:估算的價值在數量級,算到小數點後幾位只是浪費時間,也會讓人誤以為很準。