維運與可靠性練習題 (Practice - Ops and Reliability)

Contention 是多個 process 同時搶同一個資源，沒協調好就 race condition（超賣、重複扣款）。
根因是讀取與寫入不是原子的——在「讀當前狀態」和「依狀態做更新」之間有一個時間窗（記憶體微秒、網路毫秒），那個窗裡一切都可能變。

Transaction 只保證自身內部全部成功或全部失敗，擋不住別的 transaction 同時讀到一樣的資料。
Terry 和 Bohr 可各自開 transaction、都讀到 available_seats >= 1、各自 UPDATE，兩個都成功 → 1 個座位賣 2 張票。需要額外的協調機制。

• Pessimistic（悲觀鎖）：假設衝突一定發生，事先取 lock（SELECT ... FOR UPDATE）。適合高 contention。
• OCC（樂觀並發）：假設衝突罕見，衝突後才偵測（compare-and-swap，用版本號）。適合低 contention——無衝突時零 locking overhead，只有真衝突才重試。

不行。READ COMMITTED（PostgreSQL 預設）/ REPEATABLE READ（MySQL 預設）都允許門票 race。
必須用 SERIALIZABLE：DB 自動偵測衝突、中止其中一個。代價是比明確 lock 貴得多——要追蹤所有讀寫偵測衝突，abort 又浪費要重做的工作。確切知道要協調哪些資源時，FOR UPDATE 更精準有效率。

用「每次更新都會變的自然欄位」即可，不必獨立版本欄位：演唱會用 available_seats、競標用當前最高出價、轉帳用帳戶餘額。
但要選永遠單調遞增的欄位（如 review_count）以避免 ABA 問題——值 A→B→又回 A 時，compare-and-swap 看到「還是 A」會以為沒變、漏掉中間狀態。

面試先講 Saga（韌性），面試官要求嚴格一致才提 2PC。

• Saga：拆成獨立步驟、每步立刻 commit，失敗時用補償交易撤銷。代價是執行過程暫時不一致（eventual consistency），但避開 2PC 的脆弱性。
• 2PC：coordinator 管 prepare/commit 兩階段，強一致但昂貴又脆弱——持鎖跨網路、coordinator 崩潰需從持久化 log 恢復、任一 DB 變慢整筆卡住。

用座位預留機制（Distributed Lock 的延伸應用）：選座立刻進「已預留」中間狀態，配 10 分鐘 timeout。
這把 contention 窗口從整個購票流程（5 分鐘）縮到只剩預留那一步（毫秒）。同理 Uber 設司機 pending_request、電商把商品 hold 進購物車。

需求集中單一點，sharding 沒用（沒法把一場演唱會拆成多 DB）、load balancing 沒用（server 最終都打同一 row）、read replica 沒用（瓶頸在寫入）。
第一策略：質疑能不能改變問題本身（10 件一樣的拆 10 場拍賣；追蹤數不需即時一致）。真需強一致 → queue-based serialization：把該資源的所有請求丟進專用 queue，單一 worker 循序處理，徹底消除 contention（取捨是延遲）。

Deadlock 根因是兩個 transaction 以不同順序取得 lock（A 先鎖 Terry 再鎖 Bohr；B 反過來 → 互等）。
標準解法：有序加鎖（ordered locking）——永遠按一致的確定性 key（user ID / primary key）排序取得 lock，不管業務流程。所有 transaction 同序 → 沒有循環等待。後備網是 transaction timeout + DB 內建自動 deadlock 偵測。

會雪崩：請求堆積在佇列 → 延遲上升 → 執行緒池耗盡 → 記憶體膨脹 → GC 瘋狂 → DB 連線池塞滿 → 整個系統停止回應。
關鍵災難點：不只是超出容量的那部分失敗，而是「所有」請求都失敗——10% 的超量流量可以打掛 100% 的服務。設計良好的系統，10 倍流量下應還能服務 30%。

面試預設 Token Bucket：閒置時累積令牌、突發時一次放行，最貼近真實流量。

• Rate limiting 管速率（每秒幾個請求）。
• Concurrency limiting 管同時在處理中的請求數量。

每個請求 500ms、系統 100 條執行緒 → 安全並發上限 100。rate limit 設「每秒 200」但每請求要 1 秒，同時就有 200 個在跑遠超執行緒池 → 雪崩。Concurrency limiting 更直接對應系統資源，常與 rate limiting 一起用。

回 429 Too Many Requests，並用 header（Retry-After、X-RateLimit-*）告知何時可重試。
這讓客戶端能配合退避（backoff），而不是盲目重試加重伺服器壓力。

多台伺服器各自計數——客戶端把請求分散打到不同機器就能繞過限制。
解法：用集中式計數器（通常 Redis），INCR + EXPIRE 或 Lua script 原子操作保證無 race condition。延遲代價通常 < 1ms。滑動視窗常用 Redis Sorted Set（ZREMRANGEBYSCORE → ZCARD → ZADD → EXPIRE）。

用 Queue-based Load Leveling + Auto-scaling：

• 上傳後任務進 SQS / Kafka，佇列吸收尖峰，後端只看到自己能承受的平滑流量。
• 依佇列深度觸發 auto-scaling（>100 加一台、<10 持續 10 分鐘縮一台）。

轉碼是非同步任務，用戶拿到「已收到，處理中」完全合理（不像付款後等 30 秒不合理）。

• Load shedding：系統主動丟棄部分請求（讓 30% 快速失敗，好過 100% 慢死）。承壓那一側自己做決定。
• Backpressure：不丟棄任何東西，讓下游發訊號告訴上游「慢一點」，整條鏈路協同減速。

Backpressure 更溫和，但需要上游配合（支援背壓訊號，如 TCP receive window、gRPC/HTTP-2 flow control），不是所有情況都能用。

依「故障影響的相關性」劃分：把「如果它掛掉，你希望不影響哪些功能」的依賴隔離成獨立 bulkhead（支付掛掉不該影響商品瀏覽）。

• 太細 → 管理成本高、資源浪費（一池閒著另一池排隊）。
• 太粗 → 隔離沒意義（局部過載仍蔓延成全面崩潰）。

從 3~5 個 bulkhead 起步，再依實際故障模式調整。

每個依賴都有獨立故障機率，相乘再乘上每天數百萬請求，統計上故障必然發生（5 個 0.999 串起來 → 0.995，× 百萬請求 → 每天數千次失敗）。
目標不是「零故障」，而是讓系統在故障時優雅降級、自動恢復、不放大災情。

對方卡住不回應 → 你的連線懸著不釋放 → 大量發生 → 執行緒池 / 連線池耗盡 → 你自己也停止回應 → 上游再被你拖垮。
一個依賴的故障透過資源耗盡把你一起拉下去，這就是級聯故障的標準路徑。設了超時就能主動放棄、釋放執行緒、走降級邏輯。

• 該重試（暫時性故障）：網路超時 / ECONNRESET、5xx（503/502）、DB 連線池暫時耗盡。
• 不該重試：4xx 客戶端錯誤（請求本身有問題）、業務邏輯錯誤（「庫存不足」是正確回應）、非冪等操作（未做冪等保護前，重試會建兩筆）。

上限通常 3~5 次，且必須搭配退避——不加退避的重試等於在過載服務上繼續倒垃圾。

GET / PUT / DELETE 天然冪等（讀取不改狀態；PUT 完整替換重複無影響；DELETE 第二次系統狀態不變）。POST 不冪等（建兩次 = 兩筆訂單）。
POST 用冪等鍵（Idempotency Key）：客戶端首次帶唯一 ID、重試帶相同 ID；伺服器處理前查有沒處理過——有則回之前結果、沒有則執行並存下。Stripe 是範本。

解決驚群效應（thundering herd）：100 個客戶端同時失敗 → 1ms 後一起重試 → 又全失敗 → 循環把岌岌可危的服務徹底壓垮。
指數退避（每次等待加倍）給系統喘息，但所有客戶端曲線相同仍會同步脈衝；加**抖動（隨機性）**把脈衝攤平成平滑流量。Full Jitter（uniform(0, min(base*2^n, max))）實務最常推薦。

Consumer 必須冪等，標準解法是去重表（deduplication table）：在同一個 DB 事務裡先查去重表 WHERE message_id = ?，已存在則跳過直接 commit offset；不存在則處理訊息 + INSERT 去重表（同事務）。
業界主流是 at-least-once 送達 + 冪等 Consumer = 等效 exactly-once，比真正的 exactly-once（需分散式交易）複雜度低得多。

「設 3 秒讀取超時（正常 1 秒內完成，3 秒提供緩衝又不讓卡住的依賴佔資源）。對 5xx 做指數退避重試（最多 3 次，加 jitter 防驚群）。每個支付請求帶冪等鍵確保重試不重複扣款。若失敗率 30 秒內超過 50%，熔斷器打開直接回『支付暫時不可用』，而不是讓用戶等到超時。」——涵蓋超時、重試、退避加抖動、冪等性、熔斷器。

• Closed：正常轉發、監控失敗率；失敗率超閾值 → 轉 Open。
• Open：直接走降級不打下游（fail fast）；等冷卻時間 → 轉 Half-Open。
• Half-Open：放一個探針請求；成功 → 回 Closed，失敗 → 回 Open。

注意：探針成功後不要一次放開全流量，應逐步放量（ramp-up），防止突然的全流量把剛恢復的服務又打垮。

Failover：找一個健康的同類替代（切到健康節點 / 新 Primary）。Fallback：同類也沒了，用較簡陋但能用的替代撐過去（serve stale、預設值、部分降級）。
複製取捨：同步複製——Primary 等 Replica 確認才回，failover 不丟資料但寫入延遲更高（支付類）；非同步複製——延遲低但 failover 可能遺失 replication lag 期間未複製的寫入（社群動態類）。

• Metrics（指標）：系統現在狀態如何？趨勢？ → 數值 + 時序，做告警/趨勢。
• Logs（日誌）：某個特定事件到底發生了什麼？ → 文字事件，做 debug 確診。
• Traces（追蹤）：一個請求走了哪些路徑、每步多久？ → DAG（跨服務鏈路），找瓶頸。

三者互補：Metrics 說「有問題」、Traces 說「問題在哪個服務哪一步」、Logs 說「那一步具體錯了什麼」。

• Counter：只單調遞增，增長速率才有意義（請求總數）。
• Gauge：可上下浮動，某時間點即時狀態（記憶體、佇列深度）。
• Histogram：把數值分桶統計分佈，是算百分位數的基礎。

P99 用平均值會被大量快請求拉低、掩蓋尾端慢請求。Histogram 把延遲丟進桶裡取第 99 百分位，才反映「最差體驗」的真實數字。

• SLI（Indicator）：衡量品質的具體指標（成功請求比例、P99 延遲）。
• SLO（Objective）：對 SLI 設的內部目標值（成功率 ≥ 99.9%）。
• SLA（Agreement）：對外部客戶的合約，通常較寬鬆（承諾 99.5%）。

SLA 比 SLO 寬鬆是刻意的：內部 SLO 99.9% 先觸發預警，讓你在違反對外 SLA 99.5% 之前就有時間修。

應對症狀告警（用戶有沒有感受到問題），不對原因。

• 錯誤（對原因）：cpu_usage > 0.8 就告警——CPU 高不一定代表用戶有感 → 告警太多 → alert fatigue → 工程師無視 → 真事故被淹沒。
• 正確（對症狀）：5xx 錯誤率 > 1%（用戶正在受影響）、P99 延遲 > 1 秒。

純文字 "User 123 created order 456" 難以程式解析、過濾、聚合；JSON 結構化日誌每個欄位都能查詢。
trace_id 是讓 Logs 與 Traces 互通的橋樑：在 Trace 上找到慢請求 → 拿它的 trace_id → 直接撈出該請求在所有服務的 Log。沒這欄位三支柱就斷掉。另外 ERROR/WARN 應永遠 100% 保留、INFO 可取樣 10~20%。

Metrics 告警 → Traces 定位 → Logs 確診：

1. Metrics 告警：「P99 從 200ms 升到 2 秒」——知道有問題，但不知為什麼。
2. Traces 定位：「這些慢請求都卡在 Order Service 的 DB Query」——縮小到哪個服務哪步。
3. Logs 確診：「大量 'slow query: 1.8s' warning」——具體錯了什麼（SQL 沒用到索引）。

Metrics 的每個 label 值組合都是一條獨立時序。把 user_id、request_id 這種高基數值放進 label，會讓時序數量爆炸、TSDB 記憶體炸掉。
原則：高基數資訊放 Logs/Traces（它們本來就逐事件記錄），Metrics 的 label 只放低基數維度（method、endpoint、status_code、region）。