可靠交付 (Reliable Delivery)

為什麼故障是必然的

你的服務正常運行時，它的每一個外部依賴（DB、快取、訊息佇列、下游服務）都有各自獨立的故障機率。把這些機率乘起來，再乘上每天幾百萬個請求，故障在統計上就是必然發生。

P(全鏈路正常) = P(DB ok) × P(cache ok) × P(queue ok) × P(下游 ok) × ...
              每個 0.999，串 5 個 → 0.995；× 百萬請求/天 → 每天數千次失敗

所以可靠性設計的目標不是「零故障」，而是讓系統在故障發生時優雅降級、自動恢復、不放大災情。

六道防線總覽

防線 1：超時 (Timeout)

最基本、也最常被遺忘的防線。 對外發請求若不設超時，等於假設對方一定會在合理時間內回應。對方卡住 → 你的連線懸著不釋放 → 大量發生 → 執行緒池 / 連線池耗盡 → 你自己也停止回應。一個依賴的故障透過資源耗盡把你一起拉下去 —— 這就是級聯故障 (cascading failure) 的標準路徑。

無超時：
  你 ──請求──> 卡住的依賴（不回應）
  thread 1 懸著 … thread 2 懸著 … thread N 懸著
  → thread pool 耗盡 → 你也停止回應 → 上游再被你拖垮（級聯）

有超時：
  你 ──請求──> 依賴（卡住）
  [等 3s] → 主動放棄 → 釋放執行緒 → 走降級邏輯

超時的四種類型

怎麼設超時值（決策框架）

• 參考依賴方 SLA：下游 P99 是 200ms，設 2 倍緩衝 ≈ 400ms~2s 合理。設 100ms → 太多誤殺 (false positive)；設 30s → 超時形同虛設。
• 考慮整體鏈路預算：若你對用戶承諾 200ms，給下游的超時不能超過這數字，還要留自己的處理時間。

防線 2：重試 (Retry)

超時或失敗後第一直覺是「再試一次」。重試是處理暫時性故障 (transient failure) 最直接的手段：網路丟包、瞬間高負載、依賴 GC 暫停 —— 這些通常短暫，稍等再試往往就成功。但用錯反而讓情況更糟。

該重試 vs 不該重試

def call_with_retry(fn, max_retries=3, retryable_status=(503, 502, 429)):
    for attempt in range(max_retries + 1):
        try:
            response = fn()
            if response.status_code in retryable_status and attempt < max_retries:
                continue            # 觸發重試（實務上這裡要 sleep 退避）
            return response
        except (ConnectionError, TimeoutError):
            if attempt == max_retries:
                raise               # 已達上限，讓錯誤往上傳

防線 3：冪等性 (Idempotency)

談退避之前，先解決重試帶來的最核心問題：重試一個操作，會不會重複做了同一件事？

冪等性：同一個操作執行多次，和只執行一次，產生完全相同的結果。

讀取 (GET) 天然冪等；問題出在寫入。

HTTP 方法的冪等性

冪等鍵 (Idempotency Key) — 讓 POST 變冪等

客戶端首次請求附上唯一 ID；重試時帶相同的 ID。伺服器處理前先查有沒有處理過這個鍵：有 → 直接回傳之前的結果；沒有 → 執行並存下結果。

Client                              Server                  Store
  │ POST /payments  Idemp-Key: K1     │                       │
  ├──────────────────────────────────>│ get(K1) → miss        │
  │                                    ├──────────────────────>│
  │                                    │ process_payment()     │
  │                                    │ set(K1, result, TTL)  │
  │<──────────── result ───────────────┤──────────────────────>│
  │ (網路抖動，client 重試)            │                       │
  │ POST /payments  Idemp-Key: K1     │ get(K1) → hit         │
  ├──────────────────────────────────>├──────────────────────>│
  │<──────── 同一個 result（不重複扣款）┤                       │

def create_payment(request):
    key = request.headers.get("Idempotency-Key")
    if key and (cached := idempotency_store.get(key)):
        return cached                          # 直接回傳，不重複執行
    result = process_payment(request.data)
    if key:
        idempotency_store.set(key, result, ttl=86400)   # TTL 24h
    return result

冪等性 × 訊息佇列（高頻考點）

非同步架構裡，訊息佇列的常見保證是 at-least-once（至少一次送達） —— 同一則訊息可能被消費多次。因此 Consumer 必須是冪等的，能安全處理重複訊息而不產生副作用。實作標準解法：去重表 (deduplication table)。

Consumer 收到訊息
  └─ 在同一個 DB 事務裡：
       1) 查去重表 WHERE message_id = ?
       2) 已存在 → 跳過處理，直接 commit offset
       3) 不存在 → 處理訊息 + INSERT 去重表（同事務）

防線 4：退避加抖動 (Backoff with Jitter)

不加退避的重試會讓問題指數級惡化。

驚群效應 (Thundering Herd)

外部 API 過載 → 回 503
100 個客戶端瞬間全失敗
  └─ 1ms 後 100 個一起重試 → API 又收 100 個 → 又全失敗
       └─ 又一起重試 …（循環把岌岌可危的服務徹底壓垮，根本沒機會恢復）

指數退避 (Exponential Backoff)

每次重試後等待時間加倍，給系統喘息：

第1次重試：等 1s    第2次：2s    第3次：4s    第4次：8s    第5次：16s（設上限如 30s）
delay = min(base_delay * 2**attempt, max_delay)

但仍不夠 —— 所有客戶端退避曲線相同，會在第 2s、4s、8s 同步重試，形成一波波「脈衝」打在過載服務上。

加上抖動 (Jitter) — 把脈衝打散

在退避時間上加隨機性，讓不同客戶端的重試時間錯開，把同步脈衝攤平成平滑流量。

無 jitter（同步脈衝）：     │█       █       █       （全部擠在 2s/4s/8s）
Full Jitter（打散）：        ░ ░░  ░ ░ ░░  ░ ░ ░░ ░    （隨機散在 0~cap）

# Full Jitter（AWS 推薦）
cap   = min(base_delay * 2**attempt, max_delay)
delay = random.uniform(0, cap)        # 在 0 ~ cap 之間隨機

防線 5：故障切換 (Failover)

超時、重試、退避處理的是暫時故障。若一個節點 / 伺服器 / 整個資料中心永久掛掉呢？需要 failover —— 把流量從掛掉的節點切到健康的節點。

LB 層健康檢查（無狀態服務的 failover）

LB 定期對每台後端發健康檢查：
  TCP 檢查：能建 TCP 連線就算健康
  HTTP 檢查：GET /health 回 200 算健康（可加 DB 連線正常、記憶體不超標等深度邏輯）

連續失敗 N 次 → 從輪換池移除，停止送新請求 → 恢復後再加回
整個過程對 client 透明（client 只打一個 LB 位址，不知背後拓撲變化）

upstream backend {
    server server1.example.com:8080;
    server server2.example.com:8080;
    # 連續失敗 3 次標記不健康，30 秒後再重試
    server server4.example.com:8080 max_fails=3 fail_timeout=30s;
}

資料庫故障切換（有狀態，複雜得多）

最常見架構：一個 Primary 接受所有寫入 + 一或多個 Replica 透過複製保持同步。Primary 掛掉時：

1. 偵測故障   監控 / 複製協定發現 Primary 無法回應
2. 選舉新主   從 Replica 中選資料最新者，提升為新 Primary
3. 更新連線   App（或連線代理 ProxySQL / RDS Proxy）切換到新 Primary
4. 原主恢復   重新加入但以 Replica 身份（先追上期間的資料差距）

         ⚠ 從偵測到選出新主 = 不可避免的 downtime window
            RDS Multi-AZ / Cloud SQL 壓到幾秒~幾十秒

主動-主動 vs 主動-被動

詳細複製機制與一致性取捨見 05-Database-Advanced/03-Replication。

防線 6：降級回應 (Fallback) 與熔斷器

故障切換是「找健康的同類替代」；降級是「同類也沒了，用較簡陋但能用的替代方案撐過去」。

降級策略

def get_product(product_id):
    try:
        product = db.query(...)                 # 先試 DB 取最新
        cache.set(f"product:{product_id}", product, ttl=300)
        return product
    except DatabaseError:
        if cached := cache.get(f"product:{product_id}"):
            return cached                       # DB 掛 → 回舊資料（serve stale）
        raise                                   # 快取也沒有才回錯誤

熔斷器 (Circuit Breaker) — 觸發降級的機制

降級需要一個機制來觸發。熔斷器監控對下游的呼叫，錯誤率超過閾值時自動停止打請求，立刻走降級 —— 讓失敗「快速失敗 (fail fast)」，不必每個請求都等到超時才釋放執行緒，下游也得到喘息恢復的機會。

        失敗率超過閾值
   ┌──────────────────────┐
   ▼                      │
 Closed ───────────────> Open ────等冷卻時間───> Half-Open
（正常轉發，    （直接走降級，         （放一個探針請求）
  監控失敗率）   不打下游）              │        │
   ▲                      ▲      探針成功│        │探針失敗
   │                      └─────────────┘        │
   └───────────────── 回 Closed ◄── 探針成功 ──────┘（失敗回 Open）

class CircuitBreaker:
    def call(self, fn, fallback):
        if self.state == "open":
            if time.time() - self.last_failure_time > self.reset_timeout:
                self.state = "half-open"        # 冷卻夠了，試探
            else:
                return fallback()               # 直接降級，不打下游
        try:
            result = fn()
            if self.state == "half-open":
                self.reset()                    # 探針成功，恢復正常
            return result
        except Exception:
            self.record_failure()               # 累積失敗，超閾值 → open
            return fallback()

六道防線如何串在一起

這六個概念不是獨立工具，而是一套協作的防線 —— 理解它們的關係比記住定義更重要：

請求發出
  ↓
設了超時 ──── 超時發生 ──── 觸發重試
  ↓                            │
加上退避加抖動（防驚群效應）◄────┘
  ↓
重試是安全的嗎？──── 需要冪等性保證（冪等鍵 / 去重表）
  ↓
失敗率太高？──── 熔斷器觸發（fail fast）
  ↓
走降級路徑（快取舊資料 / 預設值）
  ↓
底層基礎設施故障？──── 故障切換到健康節點 / 新 Primary

面試話術

常見情境一句話模板：

常見 Deep Dive

自我測驗重點

Related Notes

• 09-Messaging-Coord/02-Queue — at-least-once 送達 + 冪等 Consumer 是可靠交付在非同步架構的核心場景
• 09-Messaging-Coord/03-Kafka — Consumer 成功處理後才 commit offset；位置更新冪等 → at-least-once 就夠
• 09-Messaging-Coord/01-Data-Pipeline — 資料管線各環節都需重試 + 冪等 + DLQ 才能可靠交付
• 01-Networking/07-Fault-Handling — 級聯故障、健康檢查、冪等性的網路層觀點，與本篇互補
• 12-Ops-and-Reliability/02-Overload-Protection — 退避/熔斷與 load shedding、backpressure 同屬過載防護家族
• 12-Ops-and-Reliability/01-Dealing-With-Contention — 重複請求與冪等鍵也是處理並發競爭的一環
• 05-Database-Advanced/03-Replication — Primary/Replica 複製是資料庫故障切換的基礎，同步 vs 非同步取捨
• 01-Networking/06-Load-Balancing — LB 健康檢查把不健康節點移出輪換池，是無狀態服務的 failover
• 07-Caching-Storage/01-Caching — 快取舊資料 (serve stale) 是最常見的降級回應策略
• 02-Distributed-Systems/05-Numbers-to-Know — 設超時值要參考 P99 延遲與整體鏈路時間預算
• 03-API-Design/02-REST — HTTP 方法的冪等性語意（GET/PUT/DELETE 冪等、POST 非冪等）的出處