Phase 06 — Distributed Systems（Day 51–60）

What：CAP 定理指出，一個分散式系統在網路分割（Partition，節點之間的連線斷掉、但兩邊各自仍在運作）發生時，最多只能同時滿足 Consistency（一致性）與 Availability（可用性）其中一個，無法兩者兼得。Partition Tolerance（分割容忍度）在橫跨多台機器、透過網路溝通的系統裡不是可以放棄的選項——只要系統存在，網路分割就有可能發生，系統必須對「分割發生時要怎麼辦」有明確的答案，這正是 CAP 定理逼你回答的問題。

1. 選 Consistency（CP）：A 判斷自己現在無法確認 B 是否能同步收到這筆寫入（因為連線斷了），為了不造成「A 寫成功了、但 B 沒有」的不一致，A 拒絕這筆寫入請求，回傳錯誤或「暫時不可用」——這是犧牲 Availability，換取「不會出現不一致的資料」。
2. 選 Availability（AP）：A 接受這筆寫入請求並立刻回應成功，即使 B 目前收不到這筆更新（因為網路斷了）。這時 A 與 B 的資料暫時不一致，要等網路恢復、資料重新同步（Day 52 要學的 Eventual Consistency）才會收斂回一致——這是犧牲 Consistency，換取「系統在分割期間仍持續可用」。

沒有發生 Partition 的時候（網路正常），A、B 之間可以正常同步，Consistency 跟 Availability 可以同時滿足，不用犧牲——這是 CAP 最常被誤解的地方：CAP 講的是「Partition 發生當下」的取捨，不是系統永遠、隨時都要犧牲一個要素。

Failure Modes：常見誤解有兩個。其一，以為 CAP 是「三選二」，可以自由挑任兩項——這是不精確的說法：只要系統橫跨多台機器且透過網路溝通，Partition 永遠有可能發生，Partition Tolerance 無法真的被「放棄」；真正的選擇只發生在 Partition 期間，是 C 還是 A 的抉擇，不是三選二。其二，把 CAP 的 Consistency 跟 ACID Transaction 的 Consistency 混為一談——CAP 的 C 指的是 Linearizability（線性一致：所有節點看到相同、依序的最新寫入結果），跟 ACID 的 Consistency（資料完整性約束不被破壞，例如外鍵、唯一鍵不能違反）是完全不同的概念，這是初學者最容易搞混、也最常在面試被追問的地方。

Backend Applications：選 PostgreSQL 主從架構搭配同步複寫（Synchronous Replication）時，本質上是往 CP 方向靠——Primary 要等 Replica 確認收到才回應 client；反之 DynamoDB、Cassandra 這類系統預設走 AP，允許「最終一致」，換取更高的寫入吞吐與可用性。Backend 工程師在選資料庫或設計複寫策略前，第一個要回答的問題正是「這個資料，Partition 發生時我要選哪一邊」，這個答案會直接決定後續的架構選型。

陌生題示範：情境——你在設計一個線上購物網站，其中「庫存扣減」與「商品瀏覽數計數器」兩個功能都要橫跨多個資料中心複寫。網路分割發生時，你會分別對這兩個功能選 CP 還是 AP？請說明理由。

推導：庫存扣減——選 CP。如果選 AP，分割期間兩個資料中心各自接受扣減庫存的寫入，恢復連線後可能出現「賣超」（兩邊各自把庫存扣到 0，但實際只有一份庫存），造成無法挽回的業務損失（賣出不存在的商品、還要處理退款與客訴）；即使分割期間變得不可用（暫停接單），後果也遠比賣超小。瀏覽數計數器——選 AP。使用者體驗上「瀏覽數字暫時不精確」完全可以接受（少算幾筆、多算幾筆不影響業務決策），但如果因為網路分割就讓整個網站的商品頁面打不開（不可用），反而是更嚴重的問題；AP 讓系統在分割期間持續可寫（各自累加），恢復連線後再合併（Eventual Consistency）。這個對照說明 CAP 的選擇不是全站統一的，而是要依「這筆資料錯了、能不能事後補救」逐一分析決定的。

What：Consistency 模型定義了「多個節點各自保有的資料副本，在什麼條件下，讀取會看到什麼樣的結果」的一組具體保證強度：

• Strong Consistency：任何一次讀取都保證看到最近一次成功寫入的結果，如同系統只有一份資料一樣，不管讀哪個節點。
• Eventual Consistency：不保證讀取立刻看到最新寫入，但保證「如果沒有新的寫入進來，經過一段時間後，所有節點最終會收斂到相同的值」。
• Read-after-write Consistency（也稱 Read-your-writes）：保證「同一個使用者，自己剛寫入的資料，自己接下來的讀取一定看得到」，即使其他使用者可能還看不到。
• Monotonic Read Consistency：保證「同一個使用者連續讀取，不會看到時間往回跳」——一旦讀到某個版本的資料，之後的讀取不會讀到比它更舊的版本，即使是被路由到不同節點回應。

• Strong：留言送出後，不管誰、不管讀哪個 replica，馬上都看得到——代價是寫入要等所有（或多數）replica 同步完成才能回應成功。
• Eventual：留言送出後，A 立刻在 replica-1 看得到，但如果另一個使用者 B 剛好讀到還沒同步到的 replica-2，暫時看不到；過一小段時間（複寫延遲後）B 也會看到。
• Read-after-write：系統至少保證「A 自己」接下來不管讀哪個 replica，都看得到自己剛發表的留言（例如把 A 的後續讀取導向他剛寫入的那個 replica，或在 A 的 session 裡記錄他寫入時的版本號、讀取時比對版本），但不保證 B 立刻看到。
• Monotonic Read：假設 A 剛好讀到了同步較快的 replica，看到自己的留言，下一秒因為負載平衡切到另一個複寫較慢的 replica——如果沒有 Monotonic Read 保證，A 可能忽然「看不到」剛剛看到的留言（資料倒退）；有這個保證，系統會確保 A 之後讀到的版本不會比他已經讀過的版本舊。

Failure Modes：沒有 Read-after-write 保證的系統，常見的 bug 情境是「使用者剛更新了自己的個人資料，重新整理頁面卻看到舊資料」——通常是讀取請求被負載平衡導到另一個還沒同步到最新寫入的節點；沒有 Monotonic Read 保證的系統，可能出現「使用者剛看到自己的訂單狀態變成『已出貨』，重新整理後又變回『處理中』」這種資料倒退的詭異體驗，會嚴重打擊使用者對系統的信任。

Backend Applications：常見做法是「寫入後的短時間內，把該使用者的讀取請求導向剛才處理寫入的那個節點（sticky read）」，或在 session／cookie 裡記錄使用者上次寫入時拿到的版本號／時間戳，讀取時只接受不低於該版本號的節點回應——這是在不用付出全域 Strong Consistency 代價的前提下，解決「使用者自己」的體感問題，是很多正式系統（例如銀行 App「交易剛完成馬上查詢餘額」）實際採用的折衷方案。

陌生題示範：情境——一個線上訂單系統，使用者下單後立刻被導向「訂單詳情頁」。工程師發現：極少數情況下，訂單詳情頁顯示「找不到此訂單」，重新整理一次後又正常顯示。請診斷這是哪一種 consistency 問題，並提出至少一種修復方案。

推導：這是缺乏 Read-after-write consistency 的典型症狀——下單的寫入請求打到某個節點（例如 replica-1）並成功，但下單成功後導向的訂單詳情頁讀取請求，被負載平衡打到另一個尚未同步到這筆新訂單的節點（例如 replica-2），造成「剛寫入、馬上讀不到」。修復方案：(1) 在下單成功的回應裡帶上寫入時的版本號／時間戳，訂單詳情頁的讀取請求附帶這個版本號，若目標節點的資料版本落後於此，改讀 Primary 或等待同步；(2) 短時間內（例如 5 秒）把同一個使用者的讀取請求固定導向剛處理寫入的節點（sticky session）；(3) 若資料庫支援，直接對這類「寫入後立刻讀」的關鍵路徑改用同步複寫或直接讀 Primary，犧牲一點延遲換取正確性。

What：Replication 是把同一份資料複製到多台機器（節點）上的機制。最常見的架構是 Primary/Replica（或稱 Leader/Follower）：所有寫入都先打到 Primary 節點，Primary 處理完後，把這筆變更（透過 write-ahead log 或類似機制）傳播給一到多個 Replica 節點，Replica 節點套用相同的變更，維持與 Primary 相同的資料狀態。

同步複寫（Synchronous Replication）：Primary 要等到至少一個（或多數）Replica 確認已經套用完這筆變更，才回應 client「寫入成功」——保證被確認的 Replica 資料不落後，代價是寫入延遲變高（要等網路來回加上 Replica 處理時間）。非同步複寫（Asynchronous Replication）：Primary 寫完自己的資料就立刻回應 client 成功，不等 Replica 確認——寫入延遲低，但 Replica 可能落後，若 Primary 在傳播完成前掛掉，這筆已經回應成功的寫入可能在所有 Replica 上都遺失（因為 Replica 從來沒收到）。

Failure Modes：Primary 掛掉、Replica 被升級（promote）成新 Primary 時，如果原本是非同步複寫，新 Primary 手上的資料可能落後於舊 Primary 掛掉前處理過的最後幾筆寫入——這幾筆「已經回應 client 成功，但還沒傳到任何 Replica」的寫入，在故障轉移（failover）後就永久遺失了，這是分散式系統裡「已提交的寫入卻消失」的典型成因；如果多個 Replica 之間的 Lag 差異很大，讀取被路由到 Lag 較大的 Replica 時，會看到明顯過期的資料，這正是 Day 52 Eventual Consistency 在 Replication 架構下的具體物理成因。

Backend Applications：PostgreSQL 的 Streaming Replication 就是這個模型的實作——Primary 把 WAL 串流給 Replica；許多系統對「金額」相關的寫入採用 Semi-synchronous Replication（至少等一個 Replica 確認，但不用全部確認）作為延遲與安全性的折衷；設計 read replica 架構時，Backend 工程師要清楚知道「讀取分散到 replica」這個優化，本質上是拿一致性（可能讀到過期資料）去換取讀取吞吐，不是沒有代價的免費午餐。

陌生題示範：情境——一個系統採用非同步複寫，一個 Primary + 兩個 Replica（Replica-A 通常落後 50ms，Replica-B 因為跨區域網路，通常落後 800ms）。Primary 突然故障，監控系統自動把 Replica-A 升級為新 Primary。請分析：(1) 哪些寫入可能遺失？(2) 為什麼選 Replica-A 而不是 Replica-B 升級比較合理？

推導：(1) Primary 故障前，任何「已經回應 client 成功、但還沒被 Replica-A 收到並套用」的寫入都可能遺失——具體範圍是 Primary 故障前最後 50ms（Replica-A 的典型 lag）內處理的寫入，這些寫入在 client 眼中已經成功，但新 Primary（Replica-A）上根本沒有這筆資料，之後也不會再出現（因為舊 Primary 已經掛了）。(2) 選 Lag 較小的 Replica-A 升級，是因為它比 Replica-B 更接近舊 Primary 的最新狀態——升級成新 Primary 後遺失的寫入範圍（50ms 內）遠小於選 Replica-B 會遺失的範圍（800ms 內）；這也說明 failover 機制設計時，「選哪個 Replica 接手」本身就是一個要主動比較 Lag 大小的決策，不能隨機選。

What：Sharding（分片）是把一份資料集切成多個子集（shard），分散存放到不同節點上的技術，跟 Replication「同一份資料存多份拷貝」的目的不同——Sharding 是「同一份資料集只存一份，但拆開放」，目的是突破單一節點的儲存容量與寫入吞吐上限（Replication 只能提高讀取吞吐與容錯，寫入仍全部要經過同一個 Primary；Sharding 才能真正把寫入負載也分散到多台機器）。

Hash Sharding：對每筆資料的某個 key（例如 user_id）算 hash，用hash(key) % N（N 為 shard 數量）決定這筆資料放哪個 shard。優點是資料分佈通常很均勻（好的 hash function 讓每個 shard 拿到差不多筆數的資料），不會有「某些 shard 特別肥大」的問題；缺點是同一個 shard 上的資料彼此沒有明顯關聯，做 range query（例如「查 user_id 100 到 200 之間的所有資料」）沒辦法只查一個 shard，得查遍所有 shard 再合併結果。

Range Sharding：依照 key 的值域切段，例如 user_id 1–1000000 放 shard-1、1000001–2000000 放 shard-2。優點是 range query 效率高（查一段連續範圍通常落在同一個或少數幾個 shard）；缺點是資料分佈容易不均勻——如果 key 是遞增的（例如用自增 ID 或時間戳當 sharding key），最新資料永遠往同一個（最後一個）shard 塞，造成「熱點 shard」（hotspot），這個 shard 的寫入負載遠高於其他 shard，違背了 Sharding 分散負載的初衷。

Failure Modes：Range Sharding 若直接用遞增 ID 或時間戳當 key，最典型的失敗案例是寫入熱點——例如一個以 created_at 排序分片的 log 系統，所有「現在」產生的新資料全部落在同一個（最新時間範圍的）shard，其他 shard 完全閒置，等於整個系統的有效寫入吞吐被壓縮回單一 shard 的上限，Sharding 帶來的擴展性完全沒發揮；Hash Sharding 若 hash function 選得不好（或 shard 數量與資料特性沒對齊），也可能出現某幾個 hash bucket 特別擠的資料傾斜（data skew），雖然機率遠低於 Range Sharding 的熱點問題。

Backend Applications：設計一個高流量的「使用者事件記錄」系統時，若用 event_id（遞增）做 Range Sharding，幾乎必然遇到熱點；改用 hash(user_id) % N 分片，同一個使用者的所有事件會落在同一個 shard（方便查詢「這個使用者的所有事件」），且不同使用者均勻分散到不同 shard，避免熱點——這正是 Day 55 要學的 Consistent Hashing 解決「shard 數量改變時，Hash Sharding 要怎麼盡量少搬資料」這個延伸問題的前置理解。

陌生題示範：情境——一個訂單系統原本用 order_id（自增整數，隨時間單調遞增）做 Range Sharding，4 個 shard 各自負責一段連續的 order_id 範圍。上線後發現：99% 的寫入流量都打在同一個 shard（負責目前最大 order_id 範圍的那個），其他 3 個 shard 幾乎沒有寫入流量。請診斷原因，並提出至少一種修復方案（不能只說「改用別的資料庫」）。

推導：原因——order_id 隨時間單調遞增，Range Sharding 依 id 值域切段，代表「現在」產生的所有新訂單，order_id 都落在目前最大的那個區段，也就是同一個 shard；隨著時間推進，新訂單永遠打在「當前最新區段」對應的那個 shard，形成典型的 Range Sharding 熱點。修復方案：(1) 改用 Hash Sharding，對 order_id（或改用 user_id）算 hash 決定 shard，讓新訂單均勻打散到所有 shard，代價是「查某個 order_id 區間的所有訂單」這類 range query 需要查遍所有 shard 再合併；(2) 若必須保留 range query 能力，改成複合 sharding key（例如先用 hash(order_id) 決定大分區，分區內部再依 order_id 排序），在均勻分佈與 range query 效率間取折衷；選哪個方案要回頭確認這個系統的查詢模式究竟更依賴「均勻寫入」還是「range 查詢」。

What：Consistent Hashing 是 Hash Sharding 的進階版本，解決「當 shard／節點數量改變（加入或移除節點）時，Hash Sharding 用hash(key) % N 要重新計算幾乎所有資料要搬去哪裡」的問題。做法是把 hash 值域想像成一個環（Hash Ring，例如 0 到 2^32-1 首尾相接），每個節點在環上被分配一個或多個位置（用節點自身的 ID 算 hash 決定其位置），每筆資料算出自己的 hash 值後，沿著環「順時針找到第一個節點」，就是這筆資料所屬的節點。

Node Join：新增一個節點，算出它在環上的位置（例如 25）。這只會影響「原本歸屬給位置 40 節點（因為它是原本落在 10 到 40 之間的資料，順時針第一個碰到的節點）」的那一段資料裡，離 25 較近的那一小段——這一小段的資料改成順時針先碰到新節點 25，歸屬轉移給它；40 之後、70 之前的資料，以及 70 之後、10 之前（繞過環首尾相接處）的資料完全不受影響。只有「原本歸屬給節點 40 的資料中，落在 10 到 25 之間」的那一小段需要搬遷。

Node Leave（節點故障或主動下線）：與 Join 相反，該節點原本負責的一整段資料，全部轉移給環上順時針方向緊接著的下一個節點，其他節點的資料完全不受影響。

Virtual Node（虛擬節點）：直接把每個實體節點在環上只放一個位置，會有兩個問題：其一，環上位置是用 hash(節點 ID) 決定，運氣不好時，幾個實體節點的位置可能剛好聚在環的一小段，造成負載不均（有的節點負責的環弧段長，有的短）；其二，節點數量少時（例如只有 3 個），環被切成的弧段數量也少，資料分佈的均勻度天生就受限。解法是讓每個實體節點在環上對應「多個」虛擬位置（例如每個實體節點對應 100–200 個虛擬節點，分散在環的不同位置，實際存取時虛擬節點再對應回它所屬的實體節點）——虛擬節點數量夠多時，統計上每個實體節點分到的環弧段總長度會趨於平均，即使實體節點數量少，也能靠增加虛擬節點數彌補分佈不均的問題。

Failure Modes：如果不用 Virtual Node，且實體節點數量少（例如剛上線只有 2–3 台機器），Consistent Hashing 的負載不均問題可能比預期嚴重——某個節點在環上恰好負責一大段弧，承受遠高於平均的流量，這時「理論上均勻分散」的假設會失效；Node Leave 是故障（不是主動下線）時，該節點原本負責的資料段，如果沒有搭配 Replication（同一段資料在多個節點各有拷貝），這段資料會直接不可用，Consistent Hashing 本身只解決「資料放哪裡」的問題，不解決「資料只有一份會不會遺失」的問題，需要跟 Day 53 的 Replication 搭配使用。

Backend Applications：分散式快取系統（例如一個自建的 Memcached/Redis Cluster 分片層）是 Consistent Hashing 最典型的應用場景——快取節點加減（擴容、機器故障重啟）是常態，如果用hash(key) % N 的簡單分片，一次擴容會讓幾乎所有快取 key 瞬間對應到錯誤的節點，等於瞬間全部快取失效（cache stampede，大量請求同時打到後端資料庫）；Consistent Hashing 讓這次擴容只有一小部分 key 的快取「失效」（找不到自己原本的資料，要重新從資料庫載入），大幅降低擴容當下對後端的衝擊。

陌生題示範：情境——一個 4 節點的 Consistent Hashing 叢集（無 Virtual Node），環上位置分別是 0、25、50、75（值域 0–99），目前發現這個叢集「新增一個節點到環上位置 60」後，某個節點的負載忽然暴增到接近全部流量的一半。請診斷可能原因，並提出至少一種修復方案。

推導：先確認「新增節點到 60」本身不該造成暴增（新增節點只會把 60 之前、原本歸屬給 75 節點的一小段資料轉移給新節點 60，理論上應該讓 75 節點負載下降，其他節點不受影響）；如果反而某節點暴增到接近一半流量，代表問題不是這次新增操作造成的，而是原本沒有 Virtual Node 的先天負載不均問題被放大顯現——4 個節點在環上位置分別是 0、25、50、75，看似均勻（每 25 一個），但如果資料 key 的 hash 分佈本身有偏態（不是均勻分佈），或者其中一段弧恰好對應到熱門 key 集中的區域，沒有 Virtual Node 分散風險，這段弧的負載就會集中在對應的單一節點上。修復方案：幫每個實體節點配置多個（例如 100–200 個）Virtual Node，分散在環的不同位置，讓「同一個實體節點負責的多段弧」加總起來趨近統計均勻，降低「單一弧段恰好對到熱點」時對整體負載的影響。

What：Cache 是放在應用程式與主要資料儲存（通常是資料庫）之間、存取速度快很多但容量小很多的暫存層，目的是讓「重複被讀取的資料」不用每次都打到較慢的資料庫。依照「cache miss 時誰負責去源頭載入資料」以及「寫入操作先打 cache 還是先打資料庫、由誰負責同步兩邊」，可以分成四種策略：Cache Aside、Read Through、Write Through、Write Behind。

• Cache Aside（Lazy Loading，最常見）：讀取時，應用程式先查 cache；命中就直接回傳；沒命中（miss）則應用程式自己去查資料庫，拿到結果後手動寫回 cache，再回傳給呼叫端。寫入時，應用程式直接寫資料庫，然後把 cache 裡對應的舊 entry 刪除（不是更新成新值——為什麼是刪除而不是更新，Day 57 會詳細推導）。應用程式同時負責「讀 miss 時填 cache」與「寫入後讓 cache 失效」兩件事，cache 層本身很單純（只是一個 key-value 儲存），不知道資料庫的存在。
• Read Through：跟 Cache Aside 的差異在於「誰負責 miss 時去源頭載入」——這裡改成 cache 層本身知道怎麼去源頭（資料庫）載入資料，應用程式只跟 cache 打交道，miss 時 cache 層自己去查資料庫、填好自己，再回應給應用程式；應用程式的程式碼裡完全不出現「查資料庫」這個分支。
• Write Through：寫入請求先送到 cache 層，cache 層收到後同步寫入資料庫，等資料庫確認寫入成功，才回應應用程式「寫入成功」；cache 裡的值在寫入當下就已經是最新值，跟資料庫永遠同步（因為每次寫入都是「cache 跟 db 一起寫、一起確認」）。
• Write Behind（Write Back）：寫入請求只先寫進 cache，cache 層立刻回應「寫入成功」（不等資料庫），資料庫的實際寫入是之後才非同步、通常是批次（batch）進行的。應用程式得到很低的寫入延遲，代價是資料庫暫時落後於 cache 的最新狀態，而且如果 cache 在「非同步寫回資料庫」完成之前當機或資料遺失，這些還沒被真正寫進資料庫的變更會永久遺失。

Failure Modes：Cache Aside 若 cache 層整個掛掉重啟（所有 entry 一次清空），大量請求同時 miss、同時湧向資料庫（thundering herd／cache stampede），可能瞬間打垮原本被 cache 保護著的資料庫；Write Behind 若 cache 在批次寫回資料庫之前當機，這批還沒落地的變更就此消失，且應用程式完全不會知道（因為當初回應的是「寫入成功」）；Read Through／Write Through 因為 cache 層本身要負責跟資料庫溝通，若 cache 層的資料庫連線設定或逾時設得不好，會把資料庫的問題直接放大成 cache 層的問題。

Backend Applications：Redis 搭配應用程式手動控制讀寫，是 Cache Aside 最典型的實作方式；CDN 的運作模式接近 Read Through（CDN 節點本身知道怎麼去源站抓取沒快取過的內容）；資料庫本身的 Buffer Pool（Phase 04 教過）在某些實作裡也採用類似 Write Behind 的概念（先寫進記憶體中的 dirty page，稍後才真正 flush 到磁碟），是同一套「先寫快取層、稍後才寫真正持久層」思路在不同層級的應用。

陌生題示範：情境——一個電商網站的商品詳情頁，流量極高，幾乎全部是讀取（瀏覽商品），寫入極少（只有客服後台偶爾調整庫存數字或商品描述）。請問該選哪種 cache 策略，為什麼？

推導：選 Cache Aside 最合適。這個場景讀多寫少，miss 時才載入、命中時直接從 cache 回應，配合適當的 TTL（Day 57 展開）即可大幅降低資料庫負載；寫入極少，代表「寫入後讓 cache 失效」的額外邏輯執行頻率很低，不需要為了極少數的寫入引入 Write Through 那種「每次寫入都多付出一次同步等待」的開銷，也不需要 Read Through 把「怎麼查資料庫」這個複雜度搬進 cache 層——應用程式的讀取邏輯本來就簡單（miss 就查一次資料庫），沒有理由為此增加 cache 層的複雜度。

What：Cache 本質上是資料庫資料的一份拷貝。當資料庫裡的資料被更新後，如果 cache 裡對應的舊拷貝沒有被清除或更新，就會變成stale data（過期資料）——讀者讀到的是還沒反映最新寫入的資訊。Invalidation（失效化）是「讓 cache 知道自己手上的資料已經過期，該被清除或重新載入」這整套機制的統稱。

• TTL（Time To Live）：每筆 cache entry 設定一段存活時間，時間到了自動視為失效——下次讀取會變成 cache miss，重新從資料庫載入最新值。這是最簡單、幾乎每個 cache 系統都會用的機制，代價是「在 TTL 到期之前，這段時間內看到的都可能是過期資料」，TTL 越長，可能過期的時間窗越大。
• Invalidation on write（寫入時主動失效）：資料被寫入資料庫的同時，主動刪除（或更新）cache 裡對應的 entry，不用等 TTL 到期才修正。這比純 TTL 更即時，但要求寫入路徑本身要知道「這次寫入會影響哪些 cache key」，寫入邏輯與 cache 邏輯必須綁在一起維護。

Stale Data Race 的具體推導（今天的核心）：即使用了 invalidation on write，仍然存在一個經典的 race 情境——這裡的「race」沿用 phase-05-concurrency.md Day 44 教過的 Race Condition 定義（多個操作同時存取同一份共享狀態，結果依賴誰先誰後完成），情境從「兩個 thread 同時存取同一塊記憶體」換成「一次 cache 讀取的『寫回 cache』動作，與一次 cache 失效同時發生」：

```text 時間軸（key = "product:123"，DB 值從 v1 更新成 v2）：

t0 Client A 讀取 product:123 → cache miss（cache 目前是空的）t1 Client A 開始查資料庫，讀到 v1（此時資料庫還是舊值）t2 Client B 更新資料庫 product:123（v1 → v2）t3 Client B 依 invalidation on write，刪除 cache 裡 product:123 這個 entry（此時 cache 本來就是空的，這一步沒有實際效果）t4 Client A（t1 查資料庫比較慢，現在才拿到結果）把自己讀到的舊值 v1 寫進 cache

結果：資料庫已經是 v2，但 cache 裡長期停留在 v1——而且不會被自動修正，因為 Client B 的 invalidation（t3）發生在 Client A 把 v1 寫進 cache（t4）之前，之後不會再有任何寫入操作觸發下一次 invalidation，這筆過期資料會一直留在 cache 裡，直到 TTL 到期（如果有設定的話）。```

解法（至少需要一種，以下列出常見的三種）：

1. 短 TTL 作為保底：即使發生上述 race，最壞情況也只會讓過期資料停留到 TTL 到期為止，把「無限期停留」的風險上限收斂成一個可控的時間窗。這是最簡單、幾乎必然要有的保底機制，但不解決 race 本身。
2. 版本號／時間戳比對：Client 從資料庫讀到資料時，一併記下這筆資料的版本號或最後更新時間；準備把資料寫進 cache 之前，先確認「目前 cache 裡（或資料庫裡）的版本是否已經被更晚的寫入超越」，如果已經超越就放棄這次寫入 cache（因為自己手上的是舊資料），避免用舊值覆蓋掉別人已經寫入的新狀態。
3. 調整寫入順序，優先「先寫 DB 再 invalidate cache」：把 Client B 的動作順序固定成「先完成資料庫寫入，再刪除 cache」（而不是反過來），可以大幅縮小上述 race 發生的時間窗（詳見下方陌生題示範的推導），雖然不能百分之百消除，但配合方案 1 的短 TTL，已足以把風險壓到大多數業務場景可接受的範圍。

Failure Modes：最常見的失效模式是「寫入路徑忘記觸發某個 cache key 的 invalidation」——這筆資料在資料庫早已更新，但因為程式碼裡漏寫了對應的 cache 清除邏輯，cache 裡的舊值會一直存在，直到 TTL 到期才被動修正（如果 TTL 設得很長甚至沒設，這筆資料可能永遠不會自動修正）；TTL 設太長，會讓「使用者反映『我剛剛才改的資料，怎麼還是顯示舊的』」這類客訴變得頻繁。

Backend Applications：Redis 常見的做法是「更新資料庫後刪除 cache key（DEL），而不是直接把 cache 更新成新值（SET）」，理由正是上面推導的 race——如果兩個並發寫入的完成順序顛倒，直接SET 新值可能被另一個較舊的寫入覆蓋回更舊的值，而 DEL 則是讓下一次讀取重新從資料庫載入最新值，即使順序顛倒，最終讀到的也會是當下資料庫的真實狀態；CDN 的 cache purge（清除）機制，本質上就是 invalidation 在跨地理節點場景下的具體應用。

陌生題示範：情境——工程師在設計 Cache Aside 的寫入路徑時，糾結「先刪 cache、再寫資料庫」還是「先寫資料庫、再刪 cache」哪個更安全？

推導：「先刪 cache、再寫資料庫」反而更容易造成長期 stale——考慮以下時序：Client B 先刪除 cache（此時 cache 變空），這時如果有另一個讀取請求 Client A 剛好進來，發現 miss，去查資料庫，這時 Client B 的資料庫更新可能還沒完成，Client A 讀到的仍然是舊值 v1，並把 v1 寫回 cache；接著 Client B 才完成資料庫更新（v1 → v2）。結果 cache 裡是 v1（過期），而且這次不會再被任何後續動作修正，直到 TTL 到期或下一次寫入才會被刷新。反之「先寫資料庫、再刪 cache」，本題上方推導的 race 雖然仍有可能發生，但視窗明顯更小（Client A 必須剛好在 Client B 完成資料庫寫入之後、但 Client A 自己拿著更早讀到的舊值去寫回 cache 這兩個動作之間插入），且發生機率遠低於前者。因此大多數 Cache Aside 的實務建議都是「先寫資料庫、再刪 cache」，並用短 TTL 兜底剩餘的風險。

What：Producer 是產生訊息並送進 Queue 的一方（例如訂單服務在訂單建立後產生一則「訂單已建立」事件）；Queue 是暫存訊息的緩衝區，負責把 Producer 產生訊息的速度跟 Consumer 消化訊息的速度解耦開來；Consumer 是從 Queue 取出訊息並實際處理的一方（例如負責發送 email 通知的 worker）。

Failure Modes：如果 Queue 本身沒有做持久化（純記憶體暫存），Queue 所在的進程或機器當機，會讓所有還沒被 Consumer 取走的訊息瞬間全部遺失（呼應 Day 59 的 Lost Message）；如果 Consumer 處理速度長期跟不上 Producer 產生訊息的速度，Queue 裡的訊息會無限累積（backlog），最終佔滿儲存空間，或造成訊息從產生到真正被處理之間的延遲不斷拉長，變得不可接受。

Backend Applications：Kafka、RabbitMQ、AWS SQS、NATS 都是這個模式的具體實現；Phase 08（Day 76–80）會把這裡的抽象概念，對應到 NATS 這個真實系統的具體 API 操作。

陌生題示範：情境——一個通知系統，如果訂單服務不透過 Queue，而是直接同步呼叫發信服務的 API 來發送「訂單已建立」通知，會遇到什麼具體問題？

推導：(1) 訂單建立這個請求的回應時間，會被發信服務的處理時間直接拖累——即使發信本身只需要 200ms，也等於每次下單都多付出這 200ms 延遲，使用者體感變差；(2) 發信服務如果暫時過載或當機，訂單建立的請求會因為這次同步呼叫失敗而跟著失敗（或需要訂單服務自己實作 retry 邏輯），把兩個本該獨立的功能（建立訂單、發送通知）綁死在同一次請求的成敗上，即使訂單本身其實已經成功建立；(3) 如果某天需要一次發送給大量使用者（例如促銷活動通知），同步呼叫模式無法平滑地把「產生通知」與「實際發送」的速度分開處理，容易讓發信服務瞬間過載。引入 Queue 後，訂單服務只需要把「訂單已建立」這個事件丟進 Queue 就能立刻回應，發信這件事交給獨立的 Consumer 按照自己的速度慢慢消化，兩邊互不拖累。

What：Retry 是 Consumer 處理訊息失敗時，不直接放棄，而是讓這則訊息重新變成「可以被再次嘗試處理」的狀態（重新排入 Queue，通常延遲一段時間後才重試）；DLQ（Dead Letter Queue，死信佇列）是「重試多次仍然失敗」的訊息最終被移去的地方，讓這類訊息不再繼續佔用正常佇列的資源、也不會無限重試下去。

Failure Modes：沒有 DLQ、也沒有重試次數上限時，一則格式錯誤、永遠處理失敗的訊息可能被無限重試，不只浪費運算資源，還會讓 Consumer 的錯誤日誌被同一個問題洗版，掩蓋掉其他真正需要關注的錯誤；有 DLQ 但沒有對應的監控告警，DLQ 裡堆積的失敗訊息不會被任何人發現，功能上等同於訊息真的遺失了。

Backend Applications：AWS SQS 原生支援設定 DLQ 與最大重試次數；這裡的機制與 Day 59 的 Timeout/Retry 情境直接相關——Consumer 判斷「這次處理算失敗、要觸發 retry」的依據，往往正是收不到下游服務在期限內回應（Timeout）。

陌生題示範：情境——一個訊息因為對應的收件人 email 帳號已經被使用者刪除（收件地址永久失效），導致發信一定會失敗。如果這個 Consumer 的重試設定是「無限重試、間隔固定 1 秒」，會發生什麼問題？

推導：這則訊息會被以每秒一次的頻率無限重試下去，因為失敗原因是永久性的（收件地址不存在），重試永遠不會成功；這不只浪費 Consumer 資源在一個注定失敗的任務上，如果 Queue 沒有把失敗訊息與其他正常訊息分開處理，還可能拖慢正常訊息的處理吞吐量；修復方式是設定合理的最大重試次數（例如 3–5 次）搭配遞增的重試間隔，超過上限後移入 DLQ，交由人工確認「這則訊息是不是真的不該再重試」（例如發現收件地址已失效，就把這則訊息標記為永久放棄，而不是持續佔用資源）。

What：Ordering（順序性）討論「多筆訊息是否按照送出的順序被處理」；Delivery Semantics（傳遞語意）討論「一筆訊息保證會被處理幾次」，常見有三種：At-most-once（最多處理一次，可能一次都沒處理到，但絕不會重複處理）、At-least-once（至少處理一次，保證會被處理到，但可能重複處理）、Exactly-once（保證恰好處理一次，不多不少）。

Failure Modes：最常見的錯誤，是誤以為系統原生提供真正的 Exactly-once 語意，因而完全沒有在 Consumer 端加上任何去重機制——一旦網路重試造成訊息重複送達（At-least-once 的正常現象，不是 bug），就會真的發生重複處理的後果（例如重複發送同一封通知信、重複執行同一筆扣款）。

Backend Applications：Kafka 與 NATS JetStream 都是「At-least-once+ 需要 Consumer 自行實作 Idempotency 才能達到業務上等同 Exactly-once 效果」的實際案例，這也是為什麼下一個小節的 Idempotency 在 Messaging 情境下如此重要——它是把 At-least-once 「補完」成業務上可接受行為的必要環節，不是可有可無的錦上添花。

陌生題示範：情境——一個系統的 Consumer 假設自己用的訊息系統提供 Exactly-once 保證，因此完全沒有實作任何去重邏輯。上線後某次網路短暫不穩定，工程師發現同一位使用者收到了兩封一模一樣的訂單確認信。請診斷原因。

推導：這個訊息系統實際提供的是 At-least-once（幾乎所有主流訊息系統的預設都是如此，純粹的協定層級 Exactly-once 在有網路的分散式系統裡幾乎不存在），網路短暫不穩定導致 Consumer 處理完訊息、正要送出 ack 時網路中斷，Queue 沒收到 ack，判定這次投遞失敗，依 Retry 機制把同一則訊息重新交給 Consumer（可能是同一個或另一個實例）再處理一次——但實際上第一次的發信動作早已經成功執行，於是使用者收到了兩封信。修復方式：Consumer 端必須自行實作 Idempotency（見下方），而不是依賴系統本身提供不存在的 Exactly-once 保證。

這是 Idempotency 第二次出現：phase-01-backend-cs-fundamentals.mdDay 5 定義過 Idempotency 在「HTTP method 語意層級」的範圍——「在一次 client 手動重試、request 本身沒有遺失或重複送達的前提下，同一個操作重複做結果要一樣」，並在該處明確標註這個定義不解決「網路本身讓同一則訊息送達兩次、系統要怎麼知道這是重複」的問題，留給 Distributed Systems（本 Phase）處理。今天要重新引入 Idempotency，並不是重新定義，而是在 Day 5 的定義之上疊加兩個新變數。

What：這裡談的 Idempotency，是「當重試不再是使用者手動點兩下、而是系統自動觸發，且訊息因為網路本身的行為（At-least-once delivery）可能真的被送達不只一次時，系統要如何確保『同一筆操作即使被處理兩次，最終效果與只處理一次相同』」。

Why（比 Day 5 多出的兩個新變數）：Day 5 的定義建立在兩個前提上——重試是呼叫端手動觸發的、請求本身沒有遺失或重複送達；但在 Messaging 情境下，這兩個前提都不成立：(a) 重試變成系統自動觸發——Consumer 沒送出 ack，Queue 自動重新投遞，呼叫端（甚至 Producer）完全不知道上一次是否真的處理成功過，不像 Day 5 情境下呼叫端至少知道「我剛剛手動按了兩次」；(b) Partition／網路分區下，「這個操作到底做過沒」這件事本身可能在不同節點看到不同答案（呼應 Day 51 CAP）——如果用來判斷「是否已處理過」的去重紀錄本身是分散式儲存的，網路分割可能讓不同節點對同一筆訊息的處理狀態有不一致的認知。這兩個新變數，讓「只看 HTTP method 語意」（Day 5 的層級）完全不夠用——問題不再是「這個操作語意上是否安全重試」，而是「這個操作到底有沒有真的被執行過，系統自己要怎麼確認」，這需要額外的機制才能回答，而不是重試次數控制或選對 method 就能解決。

Failure Modes：完全依賴「訊息看起來只會送一次」的假設、沒有實作任何去重機制，一旦網路造成 At-least-once 語意下的重複投遞（這是正常現象，不是罕見 bug），就會真的發生重複扣款、重複發信；去重紀錄的「記錄已處理」與「真正執行副作用」這兩個動作如果沒有安排好先後順序或原子性，可能出現「記錄了已處理、但實際執行失敗」（之後合法的重試會被誤判成重複而跳過，造成漏做）或「執行成功了、但記錄還沒寫入前系統就當機」（下一次重試又會真的重複執行一次）這兩種邊界情況，需要依業務對「寧可漏做也不要重複做」還是「寧可重複也不要漏做」的容忍度，決定先執行還是先記錄。

Backend Applications：支付系統處理第三方（如 Stripe）webhook 時，幾乎都要求利用上游提供的 event id 自行維護一份去重表，避免同一筆 webhook 事件因為網路重試被重複處理成兩筆扣款紀錄；Phase 07 Day 66–68（T-032，Notification System Design）會把這裡的機制，落實成一個具體元件的設計決策——Worker 收到訊息時，用什麼資料結構判斷「這則通知是否已經發送過」。

陌生題示範：情境——一個發送 email 通知的 worker，從 Queue 收到訊息後處理並成功發出郵件，但在真正把 ack 回報給 Queue 之前，這個 worker 的執行環境忽然當機重啟。Queue 因為沒收到 ack，判定這次投遞失敗，把同一則訊息重新投遞給另一個 worker 實例。請問會發生什麼事，並提出解法。

推導：會造成重複發信——第一個 worker 其實已經真的成功發送了這封 email，只是恰好當機在「發信完成」與「回報 ack」之間；從 Queue 的角度看，「沒收到 ack」就等於「這次投遞失敗」，於是重新投遞；第二個 worker 收到同一則訊息，沒有其他資訊可以判斷「這件事其實已經做過了」，於是再次執行「發信」這個動作，導致使用者收到兩封內容一樣的通知信。解法：在真正執行「發信」這個有副作用的動作之前，先用訊息帶的唯一 id 查一次去重存儲，確認沒有處理過的紀錄才送信；發信成功後立刻把這個 id 記錄為已處理。剩下的邊界情況（記錄與發信這兩步之間如果又當機）取決於業務對「寧可漏發也不要重複發」或「寧可重複也不要漏發」哪個更能接受，例如可以先把 id 標記為「處理中」、發信成功後才改標記為「已完成」，讓下一次重試至少知道「上次有嘗試過，需要人工確認是否真的成功」，而不是單純的二元「有紀錄／沒紀錄」。

What：分散式系統中，請求要跨越網路傳遞，天生會遇到以下六種具體的故障樣態：Timeout（在期限內沒收到回應，不知道對方到底有沒有處理成功）、Retry（對 Timeout 的因應機制，重新送一次請求）、Duplicate（Retry 造成同一個邏輯操作被處理不只一次）、Lost Message（訊息真的遺失，永遠沒有被處理，也沒有任何一方知道要補救）、Out-of-order Message（多筆訊息實際送達或處理的順序，跟送出時的順序不同）、Partial Failure（系統一部分組件故障，其他部分仍在正常運作，不是全有全無的二元狀態）。

• Timeout：呼叫端設定一個等待上限，超過這個時間仍未收到回應，就判定「這次請求失敗」。但這個判定本身帶著根本的不確定性：對方可能其實已經處理完成，只是「回應」本身在回程路上遺失或延遲了——「請求真的沒被處理」跟「請求成功但確認訊息遺失」，從呼叫端的視角看起來一模一樣，這正是 Timeout 最難處理的地方。
• Retry：因應 Timeout 帶來的不確定性，如果判斷這個操作可以安全重試（回顧 Day 58 的 Idempotency），呼叫端會重新送一次請求。但因為 Timeout 本身無法分辨「真的失敗」與「其實成功只是回應遺失」，Retry 有可能對「其實已經成功」的操作又送一次。
• Duplicate：Retry 造成的直接後果——同一個邏輯操作被處理超過一次。這件事本身是否會造成問題，完全取決於這個操作是否有 Day 58 Idempotency 機制保護；有保護就只是多做一次無害的重複判斷，沒有保護就會真的造成重複扣款、重複發信等後果。
• Lost Message：跟 Timeout 不同，Lost Message 是訊息真的從未到達或從未被處理，而且往往「沒有任何一方知道該重試」——例如 Producer 自己都不知道這次送出其實失敗了，或者 Queue 本身沒有持久化，進程重啟前佇列裡的訊息就全部消失。這是六種情境裡最難被偵測到的一種，因為「沒有任何錯誤訊號」跟「順利完成但沒人追蹤結果」，從外部完全無法分辨，通常需要額外的機制（例如 Day 58 的 At-least-once + ack 保證、持久化 Queue）才能杜絕。
• Out-of-order Message：多筆訊息經過不同的網路路徑、被不同 Consumer 實例平行處理，實際到達或處理完成的順序，可能跟 Producer 送出時的順序不同（見 Day 58 DoD 情境）。如果這些訊息彼此之間有依賴關係（例如「訂單建立」必須在「訂單狀態更新」之前生效），順序顛倒會造成邏輯錯誤，甚至讓系統狀態進入不該存在的組合。
• Partial Failure：系統由多個組件構成，故障通常不是全有全無，而是「一部分組件掛了，其他部分還能正常運作」。這時呼叫端面對的不是簡單的「成功/失敗」二元結果，而是「結果不確定，某些副作用可能已經發生、某些還沒」這種更複雜的中間狀態——例如一次跨多個服務的操作，前兩個步驟成功、第三步驟因為那個服務剛好故障而失敗，前兩步的副作用已經真實發生，不會因為第三步失敗就自動撤銷。

Failure Modes（這裡指「沒處理好這些故障，會連帶造成什麼更嚴重的後果」）：不處理 Timeout 帶來的不確定性、盲目認定「超時 =失敗」並對非冪等操作直接重試，會造成 Duplicate；沒有持久化與 ack 機制、放任 Lost Message 發生，訊息靜默消失、沒有任何人知道要補救；不處理 Out-of-order，狀態機可能被推進到不合法的組合（例如「更新一筆還不存在的訂單」）；把整個系統當成單一原子單位對待、忽略 Partial Failure 的存在，會誤判「以為全部失敗、其實部分已經生效」而重複處理，或「以為全部成功、其實部分沒做」而遺漏必要的後續步驟。

Backend Applications：對應的具體緩解方式——Timeout 的數值設定要有依據（例如根據下游服務歷史 P99 延遲設定，而不是拍腦袋決定一個數字）；Retry 要搭配 exponential backoff，避免大量請求同時重試造成雪崩式流量衝擊下游（呼應 Day 58 的 Retry/DLQ）；Duplicate 靠 Day 58 的 Idempotency 機制解決；Lost Message 靠 persistent Queue（訊息落地持久化）搭配 ack 機制杜絕（呼應 Day 58 At-least-once 的實作方式）；Out-of-order 靠訊息帶序號或時間戳，Consumer 端重新排序或拒絕處理「版本已經落後」的訊息（呼應 Day 52 Monotonic Read 的思路——同一個機制，換了一個場景重新出現）；Partial Failure 靠每個組件各自獨立的健康檢查與 circuit breaker，讓呼叫端能明確偵測到「是這一部分壞了」，而不是整個系統一起被拖進逾時或當機的狀態。

陌生題示範：情境——一個訂單系統，Consumer 依序從 Queue 收到「訂單建立」與「訂單取消」兩則事件，但因為 Consumer 用了多個 worker 平行處理不同訊息，負責「訂單取消」的 worker 比負責「訂單建立」的 worker 更早執行完成，導致系統一度出現「取消一筆還不存在的訂單」的錯誤。請診斷這是六種情境中的哪一種，並提出至少一種修復方案。

推導：這是 Out-of-order Message 的典型案例——雖然 Producer 按照正確順序送出（先建立、後取消），但因為用多個 worker 平行處理，兩則訊息實際被處理完成的順序被打亂。修復方案：(1) 對同一張訂單相關的所有訊息，用訂單 id 做 partition key，確保同一張訂單的事件永遠由同一個 worker 依序處理（犧牲部分平行度換取順序保證，跟 Day 58 DoD 的解法一致，因為本質上是同一類問題）；(2) 在真正執行「取消訂單」這個動作之前，先檢查「這筆訂單目前是否已經存在、且狀態允許被取消」，不滿足就把這則事件重新排隊延後處理，而不是直接執行導致狀態機出現不合法組合。