資料複寫基礎概念：高可用與一致性的權衡

為什麼需要複寫？它與分片有何不同？在系統設計版圖中的座標為何？

在分散式系統中，我們幾乎不可能只將資料儲存在單一伺服器上。單點意味著單點故障（SPOF）、地理延遲限制以及吞吐量的瓶頸。為了解決這些問題，我們需要將相同的資料複製並儲存在多個透過網路連接的節點上，這就是資料複寫（Data Replication）。

複寫的三大核心動機

• 高可用性 (High Availability, HA)：當部分節點宕機、斷網或發生硬體故障時，系統仍能繼續運作，提供不間斷的服務。
• 降低延遲 (Low Latency)：將資料儲存在地理位置上更接近用戶的節點（如 CDN 或多區域資料庫），縮短資料傳輸的物理距離。
• 提升吞吐量 (Scalability/Read Throughput)：透過讀寫分離，讓多個副本（Replica）共同分擔讀取請求，極大地提升系統的併發讀取能力。

決定「誰能接受寫入、誰負責傳播更新」的架構藍圖。

分散式資料庫如何組織節點間的寫入與讀取關係？這取決於系統採用的複寫拓撲（Replication Topologies）。主流拓撲可分為以下三種：

1. 單主複製 (Single-Leader / Master-Slave)

這是最經典且應用最廣泛的模式（如 MySQL, PostgreSQL, Redis）。
• 運作機制：系統中只有一個節點被指定為 Leader (Master)，所有寫入請求必須發送給 Leader。Leader 將更新寫入本地後，將變更日誌（Replication Log / Change Stream）發送給所有的 Follower (Slave/Replica) 節點。讀取請求則可以路由到 Leader 或任何 Follower。
• 失效轉移 (Failover)：若 Leader 宕機，系統會透過心跳檢測（Heartbeat）發現，並啟動選舉機制，將其中一個 Follower 提升（Promote）為新 Leader。

2. 多主複製 (Multi-Leader / Multi-Master)

當系統跨越複數個地理區域（Datacenter）時，單一 Leader 會面臨跨洋寫入的巨大延遲。此時可採用多主複製。
• 運作機制：在每個資料中心都設有一個 Leader。本地的寫入請求直接發送給該資料中心的 Leader，各資料中心的 Leader 之間再異步地將變更同步給彼此。
• 衝突解決 (Conflict Resolution)：多主複製最大的挑戰是寫入衝突（兩個資料中心同時修改同一筆資料）。常見的解決策略包括：
1. 最後寫入者勝 (Last-Write-Wins, LWW)：基於實體時間戳（Timestamp），但實體時鐘存在漂移風險。
2. 無衝突複製資料類型 (CRDT)：利用數學結構（如 Grow-only Counter）在併發寫入時自動合併，避免衝突。
3. 自訂衝突解決器：在應用層編寫合併邏輯。

3. 無主複製 (Leaderless / Dynamo-style)

由 Amazon Dynamo 帶起風潮的去中心化架構（如 Cassandra, Riak）。
• 運作機制：系統中沒有 Leader 的概念。Client 直接將寫入併發發送給多個節點（通常是 N 個副本）。讀取時，Client 也會併發向多個節點發送讀取請求，並透過版本號（Version Vector）來識別並解決可能存在的數據不一致。
• Quorum 讀寫機制：為了保證讀取到最新寫入的數據，寫入成功的節點數 W 與讀取請求的節點數 R 必須滿足以下公式：

當此條件成立時，寫入節點集合與讀取節點集合必定存在交集，因此讀取操作一定能拿到至少一個最新寫入的副本。

拓撲對比：單主複製結構最簡單，一致性最容易維護；無主複製則將複雜度移至 Client，以換取極高的寫入可用性。

在「數據持久性 (Durability)」與「寫入延遲 (Latency)」之間的終極折衷。

當 Leader 收到寫入請求時，它必須決定何時向 Client 返回成功。這涉及到同步與異步的權衡：

同步複寫 (Synchronous Replication)

Leader 收到寫入請求後，將更新發送給 Follower，並阻塞等待 Follower 完成寫入並回傳確認（ACK），最後才向 Client 返回成功。

• 優點：強持久性。保證 Follower 上的數據與 Leader 完全一致。即使 Leader 瞬間宕機，數據也絕不丟失。
• 缺點：寫入延遲極高（取決於最慢的 Follower 網路 RTT）；可用性極差，任一 Follower 故障或網路抖動，都會導致整個系統的寫入操作被阻塞。

異步複寫 (Asynchronous Replication)

Leader 寫入本地後，立刻向 Client 返回成功，並在背景（Background）異步地將更新發送給 Follower。

• 優點：極低的寫入延遲，高寫入可用性。即使所有 Follower 都斷線，Leader 仍能繼續接受寫入。
• 缺點：存在數據丟失風險。若 Leader 在變更尚未同步到 Follower 前宕機，這部分未同步的寫入將永久丟失。此外，這會帶來 Replication Lag，導致讀寫不一致。

折衷方案：半同步複寫 (Semi-synchronous)

為了兼顧兩者的優點，現代資料庫（如 MySQL Semi-Sync）常採用半同步架構：Leader 僅等待其中一個 Follower 確認（通常是專門的 Sync Follower）即返回成功，其餘 Follower 則繼續採用異步同步。這保證了至少有兩個節點擁有最新數據，同時避免了被單一最慢節點拖垮的風險。

當物理世界的延遲發生時，應用層會看到哪些奇葩的 Bug？

在採用異步複寫的系統中，由於網路擁塞或節點負載，Follower 的同步進度可能落後 Leader 數秒甚至數分鐘。這種現象稱為 Replication Lag。
雖然系統最終會達到一致（Eventually Consistent），但在這段延遲窗口內，若用戶直接讀取落後的 Follower，就會觸發以下三種典型的一致性異常：

1. 讀寫一致性異常 (Read-After-Write Consistency Anomaly)

• 場景：用戶在社群媒體上發表了一篇貼文（寫入 Leader 成功），然後重新整理頁面。此時，讀取請求被路由到了一個尚未同步該貼文的 Follower 節點。
• 現象：用戶發現自己剛剛發表的貼文消失了！這會讓用戶產生極大的挫折感，誤以為系統出錯。
• 解決方案：
1. 特定路由：對於用戶自己修改的資料（如個人 Profile），強制路由到 Leader 讀取；非本人修改的資料則讀取 Follower。
2. 時間窗口守護：記錄用戶最後一次寫入的時間戳，在寫入後的特定窗口期內（如 5 秒內），該用戶的讀取請求強制路由至 Leader，或路由至同步進度已超越該時間戳的 Follower。

2. 單調讀取異常 (Monotonic Reads Anomaly)

• 場景：用戶 A 發表了兩條評論（1: "Hello", 2: "World"）。用戶 B 重新整理頁面，第一次讀取路由到了進度較快的 Follower 1，看到了這兩條評論。接著用戶 B 再次整理頁面，讀取路由到了進度較慢的 Follower 2。
• 現象：用戶 B 第二次讀取時，發現評論 2 消失了。在用戶看來，系統出現了「時間倒流」的詭異現象。
• 解決方案：
1. 黏性路由 (Sticky Routing)：確保同一個用戶的讀取請求總是路由到同一個副本（例如，對 User ID 進行 Hash 路由）。只有當該副本宕機時，才切換到其他副本。

3. 一致前綴讀取異常 (Consistent Prefix Reads Anomaly)

• 場景：在分片資料庫中，存在因果關係的兩筆寫入被分配到了不同的分片。例如，A 問："你吃飽了嗎？"（分片 1），B 回答："吃飽了。"（分片 2）。
• 現象：由於分片 1 與分片 2 的複寫延遲不同，第三方讀取者可能先看到 B 的回答 "吃飽了。"，過了一陣子才看到 A 的提問。這違反了因果關係（Causality）。
• 解決方案：
1. 因果追蹤：確保任何具有因果關係的寫入都被分配到同一個分片中。
2. 邏輯時鐘/版本向量：在應用層利用邏輯時鐘重建事件的先後順序。

拖動複寫延遲與讀取時刻，看三種異常是否真的發生，以及寫入延遲與遺失窗各付出多少。

前面兩節把取捨講完了，但「半同步到底買到了什麼」很容易被誤會。下面這個模擬器把同一組寫入同時餵給兩側：左邊是半同步（Leader 等最快的一個副本確認才回 Client），右邊是全異步（Leader 寫完本地立刻回）。兩側的副本複寫速度完全相同，唯一的差別是 Client 何時收到「成功」——而這個時間差會連帶推遲讀取的時刻，這正是半同步看起來「比較不會讀到舊值」的真正原因，而不是因為它把副本變快了。

三筆寫入依序是：貼文 #1「Hello」、貼文 #2「World」，以及一則回覆（因果上依賴貼文 #2）。打開「回覆寫到另一個分片」時，回覆會走第二條複寫串流，而該串流較快——這正是一致前綴讀取異常的溫床。

先看兩側的讀者感知連線：預設參數下，全異步側第一次就只讀到 1 筆（自己剛發的貼文不見了），半同步側第一次讀到 3 筆完整——但兩側的第二次讀都掉到 0 筆，單調讀取異常在半同步側照樣成立。半同步真正買到的是「遺失窗恆為 0」那一列，不是異常欄。路由選「輪詢」時第 1 次固定讀 A、第 2 次固定讀 B（不是隨機），這樣兩次讀的差異才歸因於副本進度而不是運氣。

高頻面試題與系統架構師的思維框架。

在系統設計面試中，資料複寫幾乎是所有大型系統設計題（如「設計一個 Messenger」或「設計一個電商購物車」）的必考點。面試官不會只問你定義，而是會拋出具體的架構衝突，考驗你的折衷（Trade-offs）思維。

面試高頻問題與回答框架

架構師的折衷清單 (Trade-off Checklist)