前言
延續上一篇的基礎架構，當網站從 100 人成長到一億日活躍用戶時，單台資料庫幾乎一定會先撐不住。
這篇同樣透過五維度分析法，評估在海量讀寫請求下，如何用兩個關鍵策略拯救系統：
- 複製（Replication）
- 分片（Sharding）
這篇你可以帶走什麼
- 何時該先做讀寫分離，何時才該進入分片
- Sharding Key 選錯時，系統為何會被 Hotspot 打穿
- 為什麼擴展資料庫後，反而可能把應用層拖垮
維度一、可直接觀察的事實：海量流量下資料庫先壞在哪
在流量暴增時，資料庫瓶頸可以先用封底估算抓出大方向。
以一億日活躍用戶為例，每人每天刷 10 次手機，約會產生：
- 平均讀取流量：10K QPS
- 尖峰讀取流量：50K QPS
- 尖峰寫入流量：約 10K QPS
這已遠超單台傳統關聯式資料庫（極限約 5K QPS）的承載能力。
- Replication 解決讀取瓶頸：透過 Master-Slave（主從）架構，讓 Master 專職寫入，資料非同步複製到多台 Slave，讀取請求由 Slave 分攤，達成讀寫分離。
- Sharding 解決寫入瓶頸：依 Sharding Key 把資料拆到多台獨立資料庫，分攤單點寫入與儲存空間壓力。
重點：Replication 主要解決讀取瓶頸，Sharding 主要解決寫入與容量瓶頸。
維度二、條件檢查：什麼時候該 Replication，什麼時候才 Sharding？
一般情況下的最佳解
在系統擴展初期，建議策略是：
- 讀取緩慢：優先增加 Slave 節點（Replication）
- 寫入緩慢或空間不足：再導入 Sharding
分片鍵上，常見建議是先用 Item_ID（如貼文 ID）讓流量更平均。
邊界條件（Hotspot 效應）
若 Sharding Key 選錯（例如選 User_ID），遇到極端帳號（如超級名人）發文時，海量讀寫會瞬間集中到同一分片節點，形成 Hotspot。
結果通常是該節點先倒，原本的負載分攤設計直接失效。
重點：Sharding 不是切了就好，分片鍵的分佈品質才是生死點。
維度三、反證檢查：解了資料庫瓶頸，卻拖垮應用層
跳脫直覺，這套看起來很合理的擴展方式，仍有兩個高風險盲點：
- Scatter and Gather 成本：當以 Item_ID 分片後，要查某個用戶的歷史貼文，後端必須向所有分片送查詢（Scatter），再把結果收回排序（Gather），應用層 CPU、記憶體與網路成本都會升高。
- Rebalancing 風險：當分片節點從 4 台擴到 5 台，原本 Hash/取模規則會被打亂，可能引發大規模資料搬遷，正式環境風險極高。
維度四、不確定性與假設分析
影片中的封底估算，隱含前提是：流量大致均勻分佈。
真實世界通常不均勻。重大新聞、地震、名人事件等都可能瞬間帶來超過預估 10 倍以上的流量 Spike。
只靠資料庫層擴展，往往來不及對這種瞬間暴增做出反應。
維度五、最終結論與行動建議
破關路線圖（信心度 90%）
- 初期擴展：先做 Replication（讀寫分離），用最低系統改動成本解決大部分讀取壓力
- 非必要不 Sharding：分片是最後手段，先確認你已做完 SQL 優化、Index 與快取策略
- 快取先行：在進入高成本分片前，務必先導入 Redis 等 Cache 機制
本分析涵蓋業界常見的資料庫擴展思維，但在超大型系統中，仍會進一步牽涉跨資料中心一致性設計。
脆弱點提示
如果系統對強一致性（Strong Consistency）有極端要求（例如銀行轉帳、金融交易），依賴非同步複製（Asynchronous Replication）的主從架構就可能出現短暫舊資料讀取，進而引發嚴重商業邏輯風險。
一句話總結
先用 Replication 解決讀取壓力，再把 Sharding 當作最後手段；在動刀分片之前，先把查詢、索引與快取做到位。