分散式系統元件
一句話定義
分散式系統元件是大型系統設計反覆使用的基礎積木，例如負載均衡、快取、CDN、資料複製、分片、消息佇列、限流、唯一 ID、監控告警與重試機制；真正的設計工作是按需求與失效模式組合它們。
核心要點
基礎元件地圖
| 元件 | 解決的問題 | 常見取捨 |
|---|---|---|
| Load Balancer | 多台服務承接入口流量 | 健康檢查、黏性 session、單點與配置複雜度 |
| Database Replication | 提高讀吞吐與可用性 | 複製延遲、failover、讀到舊資料 |
| Cache | 降低讀延遲與資料庫壓力 | 失效策略、穿透、雪崩、一致性 |
| CDN | 靜態內容與媒體就近分發 | cache purge、區域成本、內容更新延遲 |
| Stateless Web Tier | Web / app server 可水平擴展 | 狀態搬到外部存儲後的延遲與依賴 |
| Message Queue | 非同步、削峰、解耦 | 重試、順序、重複消費、backpressure |
| Sharding | 單一資料庫容量不足 | 分片 key、熱點、跨 shard join / transaction |
| Rate Limiter | 保護系統免於濫用或尖峰 | 精準度、分散式計數、一致性、使用者體驗 |
| Consistent Hashing | 節點增減時降低資料搬移 | 虛擬節點、熱點、再平衡 |
| Unique ID Generator | 分散式環境產生全域 ID | 時間排序、碰撞、時鐘回撥、可讀性 |
| Metrics / Logs / Alerts | 系統可觀測與故障定位 | 指標設計、告警噪音、取樣與成本 |
元件本身不是答案
同一個元件在不同場景的理由不同：
- 佇列在圖片處理中用來非同步工作，在通知系統中用來削峰與 retry，在爬蟲中用來管理 URL frontier。
- 快取在 news feed 中可能是讀延遲優化，在影片系統中可能是熱內容分發，在支付系統中則必須小心一致性。
- 限流可以保護公開 API、防止暴力攻擊，也可以避免內部 worker 把下游服務打爆。
- 一致性哈希可以用於快取節點，也可以用於爬蟲下載器與鍵值存儲的資料分佈。
因此系統設計要先說清需求與 failure mode，再選元件。
從產品案例看元件組合
2026-05-14-搞定系統設計面試 的案例可以視為元件重組練習：
| 案例 | 主要元件 |
|---|---|
| URL 縮短器 | API、唯一 ID / hash、資料庫、快取、封底估算 |
| 網路爬蟲 | URL frontier、去重、HTML downloader、parser、robots / politeness、佇列、儲存 |
| 通知系統 | fanout、queue、第三方推送服務、template、retry、分析事件 |
| News feed | feed publishing、fanout on write/read、cache、rank / merge、資料存儲 |
| 聊天系統 | 長連線、消息存儲、online presence、push notification、同步狀態 |
| 影片分享 | object storage、CDN、transcoding worker、metadata、封面 / chunk |
| 雲盤 | metadata DB、block storage、sync client、conflict handling、notification |
| 支付系統 | ledger、idempotency、retry、第三方 PSP、對帳、資料一致性 |
| 指標監控 | metrics ingestion、time-series DB、aggregation、alerting、dashboard |
元件的引入時機
把元件引入太早會增加成本；引入太晚會形成事故。判斷順序通常是：
- 用 封底估算 確認瓶頸是否真實。
- 先選最小可行架構。
- 對最先爆的路徑加元件。
- 加元件後同步增加監控、測試與操作手冊。
- 定期回看是否有過度設計或不再必要的複雜度。
與其他概念的關係
- 系統設計 — 本頁是系統設計的元件庫。
- 可擴展性 — 多數元件都是處理流量、資料量或可用性擴展。
- 系統設計面試 — 面試案例常考元件取捨，而不是元件名詞背誦。
- 網頁爬蟲 — 分散式爬蟲是本頁的案例之一；原爬蟲頁偏資料抽取與反偵測，本頁補架構面。
- 技術SEO — robots.txt、sitemap 與 crawler friendliness 是爬蟲 / 搜尋系統的公開協議面。
- Code-Review / GitHub工作流 — 元件選型最後仍要落進 codebase；review 與版本控制是讓架構變更可控的工程治理層。
相關來源
- 2026-05-14-搞定系統設計面試 — 主來源；本頁整合書中多章共同出現的元件與案例。
備註
未來若某個元件累積 2+ 專門來源或成為高頻查詢點，再拆成獨立概念頁。近期優先候選：限流器、一致性哈希、消息佇列、分散式唯一 ID、可觀測性 / 指標監控。