大規模系統容量估算指南：工程師必須銘記的底層數字、數學模型與 SLA/SLO 設計

在設計一個分散式系統或進行架構評審（Architecture Review）時，工程師最常被問到的問題就是：

• 「這套系統需要幾台伺服器？」
• 「我們的 Redis 快取需要買多大記憶體？」
• 「資料庫一年會產生多少 TB 資料，需要預先分庫分表嗎？」

如果給不出量化的數據依據，任何架構方案都只是空中樓閣。

容量估算（Capacity Estimation / Back-of-the-Envelope Estimation） 是系統架構師的核心必備技能。它不要求精確到個位數，而是旨在用 2 分鐘的心算，快速判定系統所處的「數量級（Order of Magnitude）」，從而做出正確的技術選型。

本文將為你梳理底層關鍵硬體常數與最常用的容量估算數學模型。

---

1. 每個工程師都必須銘記的硬體延遲數字（Latency Numbers）#

由 Google 傳奇工程師 Jeff Dean 總結的經典延遲常數：

• 核心啟發：記憶體比 SSD 快 1000 倍，SSD 比跨國網路快 1000 倍。架構設計的第一準則就是盡可能在記憶體中解決運算，並透過 CDN 將數據推到離用戶最近的邊緣！

---

2. 核心估算數學模型與速算公式#

2.1 每日秒數速算法#

一天有 24 * 3600 = 86,400 秒。

• 速算近似值：1 天 ≈ 100,000 秒 (10^5 秒)。
• 威力：如果系統每天有 1,000 萬次請求（10M/day），平均 QPS = 10,000,000 / 100,000 = 100 QPS！

2.2 流量與 QPS 估算#

假設某社交平台有 1 億（100M）DAU，平均每人每天發布 2 則貼文，瀏覽 50 則貼文：

1. 寫入 QPS（Write QPS）：

   • 每日寫入總量 = 100M * 2 = 200M 則/天
   • 平均寫入 QPS = 200,000,000 / 86,400 ≈ 2,300 QPS
   • 峰值寫入 QPS（乘上 2~3 倍峰值係數） = 2,300 * 2.5 ≈ 5,750 QPS

2. 讀取 QPS（Read QPS）：

   • 每日讀取總量 = 100M * 50 = 50 億 (5 Billion)/天
   • 平均讀取 QPS = 5,000,000,000 / 86,400 ≈ 58,000 QPS
   • 峰值讀取 QPS = 58,000 * 2.5 ≈ 145,000 QPS

---

3. 儲存容量（Storage）與記憶體快取估算#

3.1 5 年累積儲存量計算#

• 假設每則貼文包含：文字與中繼資料 500 Bytes，20% 的貼文包含一張 200KB 的壓縮圖片。
• 單則貼文平均體積 = 500 B + (0.2 * 200 KB) = 500 B + 40 KB ≈ 40.5 KB。
• 每日新增儲存 = 200M 則 * 40.5 KB = 8.1 TB / 天。
• 5 年總儲存量 = 8.1 TB/天 * 365天 * 5年 ≈ 14.8 PB。
• 結論：純文字與元數據存入分庫分表的 MySQL / Cassandra，圖片二進位檔案直接存入 AWS S3 等物件儲存。

3.2 20/80 法則與 Redis 快取記憶體估算#

• 根據帕累托法則（80/20 Rule），20% 的熱門貼文貢獻了 80% 的每日讀取流量。
• 每日讀取熱點貼文數量 = 200M * 20% = 4,000 萬則。
• 記憶體快取僅快取純文字與元數據（每則 1KB）：
  • 所需 Redis 記憶體 = 40,000,000 * 1 KB = 40 GB
• 預留 25% 緩衝空間 = 40 GB * 1.25 = 50 GB RAM（單台 64GB 記憶體伺服器或 3 節點 Redis 叢集即可完美搞定！）。

---

4. 可用性等級（SLA / SLO）與停機時間對照表#

在架構設計中，高可用性通常以「幾個 9」來衡量：

要達到 99.99%（4個9）：

• 系統必須全面消除單點故障（No SPOF）；
• 必須實施跨可用區（Multi-AZ）多活部署；
• 故障轉移（Failover）必須在 10 秒內全自動完成，禁止依賴人工操作。

---

5. 總結#

容量估算不是為了追求絕對精準，而是為了：

1. 確定系統量級：決定是否需要分庫分表、引入 Redis 還是直接走單體架構；
2. 評估硬體成本：估算每年雲端頻寬、S3 儲存與機器實例的真實預算；
3. 指導容量極限測試：為壓測（Stress Testing）與容量報警閥值提供理論基準線。