Luke a Pro

Luke Sun

Developer & Marketer

🇺🇦
EN||

分散式系統與高併發:概覽

| , 1 minutes reading.

分散式系統與高併發:概覽

引言:「多大腦」問題

在單機世界中,CPU 掌控一切。但在 分散式系統 中,你有成百上千個「大腦」(伺服器)必須協同工作。

  • 如果網路斷開,伺服器 A 無法與伺服器 B 通訊怎麼辦?
  • 如果 1 萬個使用者在同一毫秒內搶購最後一部 iPhone 怎麼辦?

本章涵蓋了讓網際網路在面對故障時依然能可靠執行的演算法。

典型業務場景

  • 金融交易: 確保在兩個不同資料庫分片之間轉帳時,錢既不會憑空產生也不會丟失 (2PC, Paxos)。
  • 雲原生協作: 確保集群中的所有節點都對「誰是領導者」達成一致 (Raft)。
  • API 保護: 防止單個使用者用 100 萬個請求壓垮你的系統 (限流)。
  • 系統穩定性: 當某個微服務出現故障時自動切斷流量,防止引發全線崩潰 (熔斷)。

核心概念:CAP 定理

你無法同時擁有以下三者:

  1. 一致性 (Consistency): 所有節點在同一時間看到相同的數據。
  2. 可用性 (Availability): 每個請求都能收到響應(即使是舊數據)。
  3. 分區容錯性 (Partition Tolerance): 即使網路出現故障,系統仍能繼續工作。

現實情況: 在雲端,網路故障 (P) 是不可避免的。你必須在 一致性 (Raft/Paxos) 和 可用性 (Gossip/最終一致性) 之間做出選擇。

常見演算法速覽

  • 5.1 Raft: 被 etcd 和 Kubernetes 採用的「易於理解」的一致性演算法。
  • 5.3 2PC (二階段提交): 處理跨資料庫原子事務的經典方法。
  • 5.5 限流演算法: 用於流量控制的令牌桶 (Token Bucket) 和漏桶 (Leaky Bucket) 演算法。
  • 5.6 熔斷器: 微服務架構中的「安全保險絲」。
  • 5.8 向量時鐘 (Vector Clocks): 在沒有全局時鐘的情況下追蹤事件的先後順序。

選型對比速查

需求推薦演算法 / 模式目標
集群選主Raft強一致性與高容錯。
分散式事務2PC / TCC跨多個服務的原子性。
負載均衡加權輪詢 (WRR)均勻分配流量。
防攻擊 / 防突發流量令牌桶平滑流量峰值。
數據同步Gossip 協定高可用性與最終一致性。

一句話心法

「分散式演算法將由易故障機器組成的混亂網路,轉化為一台單一、可靠的虛擬計算機。」