詞彙表 Glossary

DDIA 全書關鍵術語 + Part 0 補充詞彙的中英對照與簡明解釋。依字母排序。

★面試常考 · 7 條快速連結

CQRSEvent-Driven WorkflowExactly-Once SemanticsIdempotentLinearizabilityQuorumSaga

面試前 1-2 小時複習這 7 條、勝過讀整本詞彙表

第一次來看詞彙表？先看這 8 個就好（後端通用）

完全不需要一次讀完 100+ 條。下面 8 個詞是 DDIA 整本書反覆出現的最底層概念、其他 90% 都是它們的變形：

1. HTTP — 客戶端與伺服器溝通的協定（你打開網頁就用到）
2. RPC — 跨機器呼叫函式（微服務之間的「電話」）
3. Latency — 一次請求多慢（vs Throughput 一秒能做幾次）
4. Fault — 一個元件壞了（vs Failure 整個系統倒）
5. Replication — 同一份資料存好幾份（為了不掛、為了讀快）
6. Sharding — 把大資料切片分散到多台機器
7. Eventual Consistency — 多副本最終會一致、過程中可能讀到舊
8. Idempotent — 操作做一次跟做十次結果一樣（不會重複扣款）

讀完這 8 個再看下方完整詞彙表、會輕鬆 5 倍。進階讀者可跳到下方 ★ 7 條面試常考。

走資料工程方向？再看這 8 個（W47 補、DE 補充詞）

非 DDIA 原書詞彙——為 OLTP→DE 橋接讀者準備、解 #06 reviewer 反映的 DE 詞缺位。多數沒獨立條目（DDIA 2017 年沒寫）、但 ch10/11/12 內文有提：

1. ETL / ELT — 抽取轉換載入（傳統 / 反序）；ELT 是 dbt + Snowflake 主流
2. OLAP — 分析型查詢（vs OLTP 交易型）；對應 Ch3 §3.6
3. 欄式儲存（Columnar） — Parquet / ORC、適合 scan 大量列少量欄；Ch3 §3.6
4. Parquet — 開放欄式檔案格式、DE 事實標準
5. Iceberg / Delta Lake / Hudi — open table format（lakehouse 三巨頭、DDIA 後的演進）
6. fact / dimension table — Kimball 星型模型基底；DA 進 DE 的 day-1 詞
7. Lambda vs Kappa Architecture — 批 + 流並行 vs 純流（Lambda 已收錄、Kappa 即「批是流的子集」）
8. CDC（Change Data Capture） — 見已收錄條目；DE 串資料庫變更的主流方法

進深見 OLTP↔DE 視角橋。

使用提示

• 內文 <G> 元件 hover 看到的「精簡定義」與此頁是同一 SSOT。
• 點擊內文詞彙會跳到本頁對應位置。
• 想搜尋某詞：按 Ctrl+F 或用上方搜尋框；想跳到字母區用上方索引條。
• 標記 ★ 的條目是 senior backend / SRE 面試 80% 會被問到的核心概念。面試前 1-2 小時複習這 7-10 條、勝過讀整本詞彙表。這不是「全部讀完」的替代品、是時間壓力下的優先級。

詞彙來源與版權

本詞彙表為個人學習筆記重新整理——術語選取參考《Designing Data-Intensive Applications》(Kleppmann, O'Reilly 2017)，定義皆為作者改寫後的中英對照（非原書翻譯），加入台灣化用詞與 Taiwan-specific 範例。原書著作權屬 Martin Kleppmann 與 O'Reilly Media。

---

A

ACID

中文：原子性、一致性、隔離性、持久性 傳統資料庫交易的四大保證。注意「Consistency」在 ACID 與分散式系統中是兩種不同的意思——這個詞 DDIA Ch7 開宗明義就吐槽。詳見 Ch7。

Anti-entropy Process

中文：反熵程序 在 leaderless 複製中，背景比對副本差異並修復。Cassandra 的 hinted handoff、Merkle tree 同步。

Atomic Commit

中文：原子提交 要嘛全部提交、要嘛全部回滾。跨節點實作需要兩階段提交（2PC）或共識。

---

B

Backward Compatibility

中文：向後相容 新讀舊——新版程式能讀舊版資料。中文「向後／向前」與英文直覺相反，初學者極易混淆；建議記「backward = 看過去（舊資料）」。詳見 Ch4。

Big-O Notation

中文：大 O 記號 描述演算法時間 / 空間複雜度的上界。O(1) 常數、O(log n) 二分查找、O(n log n) 排序、O(n²) 巢狀循環。注意：Big-O 不告訴你常數因子——小資料量時 O(n) 可能比 O(log n) 快。詳見 Part 0.4。

Bloom Filter

中文：布隆過濾器 機率資料結構，能高效判斷「key 絕對不在集合中」。有 false positive、無 false negative。常見於 LSM-Tree。

B-Tree

中文：B-Tree 傳統關聯式 DB 的索引結構。n 路平衡樹，每節點是一個磁碟頁（4KB / 16KB）。原地更新（in-place），讀快、寫要 WAL 保 crash recovery。詳見 Ch3。

Bulkhead

中文：艙壁隔離 把不同下游用不同連線池 / 執行緒池隔離、一個下游故障不會耗盡共享資源拖垮其他下游。名字來自船艙設計——一個艙進水不會沉整艘船。對應 Cascading Failure 預防四件套之一。詳見 Ch1。

Byzantine Fault

中文：拜占庭故障 節點不只是當機，可能傳送錯誤或惡意訊息。多數系統不處理這種故障（成本太高），只處理 crash-stop。詳見 Ch8。

---

C

Cache

中文：快取 把熱資料放在更快的儲存層（記憶體、CDN），減輕後端壓力與延遲。常用 Redis、Memcached；DDIA Ch1 視為「應用拼湊系統」的典型元件之一。

CAP Theorem

中文：CAP 定理 網路分區（P）發生時，必須在 Consistency 與 Availability 之間選擇。常被誤解為「三選二」——其實 P 是必選，真正的選擇是 CP vs AP。詳見 Ch9。

Cascading Failure

中文：連鎖故障（亦譯級聯失效） 分散式系統中、一個元件故障引發其他元件故障的連鎖反應（DB 慢 → 應用層 timeout → 重試風暴 → 連線池耗盡 → 全站 503）。SRE 值班最常遇到的 incident 形態、遠多於單純硬體當機。預防四件套：Circuit Breaker、Bulkhead、指數退避 + Jitter、Load Shedding（流量超過閾值就拒絕）。詳見 Ch1 §1.2。

Causality

中文：因果性 「A 因果地早於 B」的偏序關係。Vector clock 用來捕捉。

Circuit Breaker

中文：斷路器 失敗率超過閾值時、直接拒絕請求一段時間、給下游恢復空間。對應實作：Hystrix（已 deprecated）、Resilience4j、Sentinel。三狀態：Closed（正常）→ Open（短路）→ Half-Open（試探恢復）。對應 Cascading Failure 預防四件套之一。詳見 Ch1。

CDC (Change Data Capture)

中文：變更資料捕獲 從 DB 的 transaction log 抽取變更事件。讓 DB 變成 Kafka 的上游、解鎖即時 analytics。詳見 Ch11。

CQRS 面試常考 ★

中文：命令查詢職責分離 Command-Query Responsibility Segregation。把「寫入端（command）」與「查詢端（query）」拆成不同模型：寫入走事件源（Event Sourcing）落到 log、查詢從事件派生多份物化視圖。好處是 read model 可以多份、隨時可從 source-of-truth 重建。常與 Event Sourcing 同時使用。詳見 Ch11。

Consensus

中文：共識 N 個節點對某個值達成一致。Paxos、Raft 是典型演算法。FLP 證明純非同步系統無法保證終止。詳見 Ch9。

Consistent Hashing

中文：一致性雜湊 節點與 key 都映射到雜湊環，加減節點只影響相鄰位置。

Consistent Prefix Reads

中文：一致前綴讀 會話保證之一（Session Guarantee）。若一系列寫入 W1 → W2 → W3 按某順序發生，所有觀察者要嘛看到這個前綴（例如只看到 W1，或 W1+W2），要嘛還沒看到——但不會看到亂序的中段（例如看到 W3 卻沒看到 W1）。分區系統最易違反這個保證。詳見 Ch5。

CRDT (Conflict-free Replicated Data Type)

中文：無衝突複製資料類型 可自動 merge 並發更新的資料結構。

---

D

Dataflow Engine

中文：資料流引擎 Spark、Flink、Tez。以 DAG 表達運算管線，中間結果記憶體保留。

Dead Tuple

中文：失效列 PostgreSQL MVCC 留下的「舊版本列」——UPDATE / DELETE 並非真的移除舊版本，需要 VACUUM 定期回收。詳見 Ch7。

Dirty Read / Dirty Write

中文：髒讀 / 髒寫 讀到 / 覆寫未提交的資料。Read Committed 隔離級別防止之。詳見 Ch7。

Durability

中文：持久性 資料寫入後不丟失。靠 WAL + fsync + 複製達成。

---

E

Event Sourcing

中文：事件溯源 把狀態變更（事件）當主資料，當前狀態是衍生的。可重放歷史、可審計。詳見 Ch11。

Event-Driven Workflow 面試常考 ★

中文：事件驅動工作流 跨服務的長流程透過事件串接：每個服務做完自己的步驟、發出事件、下游服務訂閱該事件繼續下一步。相較傳統 RPC 鏈式呼叫、event-driven workflow 有更好的鬆耦合與可觀測性，但需要端到端追蹤 + 補償設計。常見實作框架：Temporal、AWS Step Functions、Camunda、Cadence。是 Saga Orchestration 的工具底層。詳見 Ch11。

Event Time vs Processing Time

中文：事件時間 vs 處理時間 串流處理的兩種時間軸：

• Event time：事件發生的時間（手機 app 點擊瞬間、IoT 感測器讀數時刻）——附在事件本身的 timestamp
• Processing time：事件被處理的時間（到達串流系統的牆鐘時間）

兩者常差幾秒到數小時（手機離線排隊、網路擁塞、batch 補跑）。用 processing time 開窗簡單但結果不一致（重跑會變）；用 event time 開窗結果穩定但要處理遲到事件——靠 watermark 宣告「event time T 之前的事件大致到齊」、再決定何時關閉視窗。詳見 Ch11。

Eventual Consistency

中文：最終一致性 無新寫入時，副本最終會收斂相同值。leaderless / multi-leader 複製的典型保證。「最終」可能很久。

Exactly-Once Semantics 面試常考 ★

中文：恰好一次語意 實務上為 effectively-once：透過冪等 + transactional output 達成「最終效果只發生一次」。

---

F

Failover

中文：故障轉移 主節點掛了選新 leader 的過程。腦裂（split brain）是這裡最危險的情境。詳見 Ch5。

Fan-out

中文：扇出 一個請求觸發多個下游請求。fan-out on write（Twitter 推文寫入時擴散到所有 follower 收件匣）vs fan-out on read（讀時才聚合）。詳見 Ch1。

Fault

中文：故障 單個元件偏離規格（硬碟壞、網路斷）。容錯系統能容忍 fault 不變成 failure。注意 fault ≠ failure：failure 是整個系統罷工。詳見 Ch1。

Fencing Token

中文：防護令牌 分散式鎖搭配的單調遞增號，防止「過期持有者」污染資料。儲存層拒絕比已知最大號還小的請求。詳見 Ch8。

FLP Impossibility

中文：FLP 不可能性 證明：純非同步 + 可能崩潰節點的系統中，不存在「保證終止」的確定性共識演算法。1985 Fischer-Lynch-Paterson。

Forward Compatibility

中文：向前相容 舊讀新——舊版程式能讀新版資料（遇到陌生新欄位需跳過、不能崩潰）。forward = 看未來（新資料）。在滾動部署（rolling deploy）中與 backward compatibility 同樣必要。詳見 Ch4。

fsync

中文：強制同步 強制把 OS page cache 寫回磁碟的系統呼叫。沒呼叫 fsync 的寫入，停電時可能丟失——WAL 的關鍵步驟。詳見 Part 0.5。

---

G

GC (Garbage Collection)

中文：垃圾回收 程式語言（Java / Go / Python 等）自動釋放不再使用的記憶體。GC 進行時可能讓程式行程短暫暫停（stop-the-world），分散式系統中這個暫停會被誤判為「節點失聯」。

---

H

Hash Table

中文：雜湊表 O(1) 平均存取的 KV 結構。記憶體內 KV store（Redis、Memcached）核心；磁碟上的 hash index（Bitcask）。缺點：無順序，不支援範圍查詢。詳見 Part 0.4。

Heuristic Decision

中文：啟發式決定 在 2PC coordinator 失聯時，participants 自行決定提交或回滾——破壞原子性，是 2PC 設計上的危險逃生口。

Hinted Handoff

中文：暗示移交 Dynamo 風格 leaderless 複製的補救機制：當目標副本節點暫時不可達，協調節點把寫入暫存（含「該寄給誰」的 hint）、等該節點恢復再轉交。換取可用性——即使 W 個節點湊不齊也能接受寫入（搭配 Sloppy Quorum 用）。代價：最終一致性期間讀到舊資料的機率升高。Cassandra、Riak 預設都啟用。詳見 Ch5。

Hot Spot

中文：熱點 負載集中在單一分區的問題。常見原因：明星用戶、時間序列資料、單一熱門 key。詳見 Ch6。

HTTP

中文：超文本傳輸協定 應用層協定，建立在 TCP 上（HTTP/3 改用 QUIC over UDP）。無狀態、request-response 模型，是 REST API 的基礎。詳見 Part 0.6。

---

I

Idempotent 面試常考 ★

中文：冪等 同一操作執行多次效果等同一次。分散式系統重試的基本要求——配 exactly-once 語意的根基。

Isolation Level

中文：隔離級別 Read Uncommitted / Read Committed / Repeatable Read / Snapshot Isolation / Serializable。各家 DB 對同名級別實作不同——別假設 PG 的 RR 跟 MySQL 的 RR 一樣。詳見 Ch7。

---

J

JOIN

中文：聯接 SQL 把兩張表依關聯欄位合併的操作。實作演算法：nested loop、hash join、sort-merge join——選哪個由 query planner 看資料量決定。詳見 Ch2 與 Part 0.3。

---

L

Lambda Architecture

中文：Lambda 架構 批次層 + 速度層並行處理同一資料流。詳見 Ch12。

Latency

中文：延遲 單一請求從發出到收到回應的時間。要看 P50/P99 分布，不是平均值——平均值會被尾端拉偏但也會被快速請求拉平，兩邊都騙人。詳見 Part 0.2。

Linearizability 面試常考 ★

中文：線性一致 最強一致性保證：系統表現得像只有單一副本，每個操作看起來在某瞬時點原子發生。亦譯「線性化」。實作見 Ch9 §9.1 ABD 兩階段演算法（W47 補 cross-link、修詞彙表→實作章節的 navigation 斷層）。

「強一致性」是 underspecified 用語

工業界口語常把 linearizability 稱作「強一致性（strong consistency）」，但這個詞在文獻中沒有嚴格定義——不同論文可能指 linearizability、serializability、sequential consistency 中的任一個。DDIA p.324 註腳 4 直接說它是「不精確的用法」。寫設計文件時建議直接用 linearizability / serializability / strict serializability 等有精確定義的詞。

注意：linearizability ≠ serializability（前者是儲存層級的單一物件操作排序，後者是交易層級的執行排序）。Strict Serializability = serializability + linearizability，是 Spanner / CockroachDB 等系統的真正保證。詳見 Ch9。

Lock / Mutex

中文：鎖 / 互斥鎖 確保臨界區（critical section）一次只有一個執行緒進入的機制。代價：競爭時等待、設計不當會 deadlock。詳見 Part 0.7。

Lost Update

中文：更新遺失 並發「讀-改-寫」造成。原子操作或顯式鎖可解。詳見 Ch7。

LSM-Tree

中文：日誌結構合併樹 Log-Structured Merge Tree。寫入只追加、背景 compaction。順序寫帶來高寫入吞吐，但寫放大不一定比 B-Tree 低——leveled compaction 下實測常達 10–30×（DDIA p.83-84、RocksDB tuning guide）。RocksDB、Cassandra、LevelDB 採用。詳見 Ch3。

常見誤解

網路上流傳「LSM 寫放大比 B-Tree 低」是過度簡化。實際：B-Tree 寫放大 ~3×、LSM leveled compaction 較高（10-30×、SA / RA 較低）、size-tiered compaction 較低（2-5×、SA / RA 較高）。LSM 真正的優勢是順序寫入（B-Tree 是隨機寫），這在 HDD 與 SSD 上都有顯著吞吐優勢，但寫放大本身要看 compaction 策略——選 leveled 還是 size-tiered 取決於你要犧牲哪個（讀 vs 寫 vs 空間）。

---

M

MapReduce

中文：MapReduce Google 提出的批次處理典範。Map + Shuffle + Reduce 三階段。詳見 Ch10。

Materialized View

中文：物化視圖 把查詢結果預先計算並存起來的「現成答案」；資料源變動時自動更新。Kafka Streams / ksqlDB 大量使用。詳見 Ch11。

Message Queue / Broker

中文：訊息隊列 / 代理 非同步傳遞訊息的中介系統（Kafka、RabbitMQ、SQS）。讓 producer 與 consumer 解耦、削峰填谷、實現 event-driven 架構。詳見 Ch11。

Monotonic Clock

中文：單調時鐘 System.nanoTime()。只能用來測 duration，不能跨機器比較。保證單調遞增，不會回跳。詳見 Ch8。

Monotonic Reads

中文：單調讀 會話保證之一。使用者多次讀取不會時光倒流——先讀到較新值後，不會再讀到較舊值。常見違反情境：使用者連續刷新頁面、後面那次被路由到一個更舊的 follower。實作：每位使用者 sticky 固定到同一副本，或要求讀取至少滿足某個時間戳。詳見 Ch5。

MVCC (Multi-Version Concurrency Control)

中文：多版本並發控制 每筆寫產生新版本，讀根據 snapshot 過濾。Snapshot Isolation 的實作。

---

N

NoSQL

中文：NoSQL 非關聯式資料庫的統稱：document（MongoDB）、KV（Redis）、column-family（Cassandra）、graph（Neo4j）。各有適用場景，不是 SQL 的全面替代。詳見 Ch2。

NTP (Network Time Protocol)

中文：網路時間協定 跨機器同步時鐘的網路協定。透過階層式的時間伺服器同步，誤差通常數十毫秒，但 WAN 環境或高負載下可達數百毫秒。NTP 同步可能造成 wall clock 向後跳，這是 Ch8 強調「不要用 time-of-day clock 測 duration」的根本原因。詳見 Ch8。

---

P

PACELC

中文：PACELC（CAP 的補完） Daniel Abadi 2012 提出，補完 CAP 的盲點。

• Partition 時 → 選 Availability 或 Consistency（這就是 CAP）
• Else（網路正常）時 → 選 Latency 或 Consistency

CAP 只談分區時的權衡；PACELC 加上「正常時也要在延遲與一致性之間選」，更貼近實務。典型分類：

• PA/EL：Cassandra、Dynamo（兩邊都選 A/L）
• PC/EC：Spanner、HBase（兩邊都選 C）
• PA/EC：MongoDB 預設、CosmosDB（中間派）

詳見 Ch9。

Page Cache

中文：頁面快取 OS 把最近讀寫的磁碟頁保留在 RAM。為什麼讀 SSTable 第二次比第一次快很多就是它。fsync 才強制寫回磁碟。詳見 Part 0.5。

Page Fault

中文：頁面錯誤 程式存取的記憶體頁不在 RAM 中，OS 需從磁碟把它載入——過程中程式行程停下等磁碟。

Partitioning / Sharding

中文：分區 / 分片 把資料集橫向切分到多個節點。常見策略：hash、range、目錄式。詳見 Ch6。

Percentile (P50/P95/P99/P999)

中文：百分位數 P99 = 把全部請求按延遲排序、第 99% 名那個的延遲。比平均值更能反映尾端使用者體驗，是 SLA 的標準度量。詳見 Ch1 與 Part 0.2。

Predicate Lock

中文：謂詞鎖 鎖「符合某 WHERE 條件的所有列」（包括尚未存在但未來會匹配的列）——是擋 Phantom Read 寫入變種（write skew）的理論手段。維護成本極高：每次 commit 都要對其他並發交易的讀寫做謂詞匹配。實務 DB 多用近似實作：

• MySQL InnoDB：next-key lock（record lock + gap lock）鎖索引範圍
• PostgreSQL SSI：SIREAD lock（軟鎖，不阻塞，只紀錄讀集）+ commit 時偵測 rw-dependency cycle

讀者在 MySQL 文件找不到「謂詞鎖」字面是因為實作改叫 next-key lock。詳見 Ch7。

Next-Key Lock

中文：Next-Key 鎖 MySQL InnoDB 專用的組合鎖 = record lock（鎖該列本身）+ gap lock（鎖該列前的索引間隙）。能擋 Phantom Read —— 想插入到被鎖區間的新列會被擋。

InnoDB REPEATABLE READ 的 locking read（SELECT ... FOR UPDATE / UPDATE / DELETE）會用 next-key lock，繞過 MVCC snapshot 直接讀最新已 commit 版本再加鎖。這就是為什麼 MySQL InnoDB RR 內：

• 純 SELECT 看到的是 snapshot
• SELECT ... FOR UPDATE 看到的是最新值（可能與前面 SELECT 不同）

這是 InnoDB 與 PostgreSQL SI 行為差異的核心。詳見 Ch7 §7.2 命名地獄段。

Phantom Read

中文：幻讀 查詢條件對應的「列集合」在交易期間被其他交易改變（插入 / 刪除 / 更新使列符合或不符合條件）。Berenson et al. 1995《A Critique of ANSI SQL Isolation Levels》區分兩種：

• A3 / 讀取階段的 phantom：同交易兩次範圍查詢得不同列集合—— SI 因為讀走快照能擋住
• A5B / 基於不存在性寫入決策：讀「沒有衝突」→ 寫入 → 另一交易也讀「沒有衝突」→ 也寫入 → commit 後撞突—— SI 擋不住（它無法鎖「不存在的東西」），是 Write Skew 的特例

要完全擋住第二種需要 Serializable（SSI 或 2PL with predicate lock）。詳見 Ch7。

Process

中文：行程 作業系統分配資源的單位，有獨立的虛擬記憶體空間。注意：台灣譯「行程」、中國譯「進程」，DDIA 中文網站用前者。詳見 Part 0.5。

Process Pause

中文：行程暫停 GC、VM 遷移、闔上筆電都會造成行程「死一段時間」。在分散式系統中會被誤判為「節點失聯」。詳見 Ch8。

---

Q

Quorum 面試常考 ★

中文：法定人數 W + R > N 公式保證讀寫集有交集。注意：quorum 不無條件保證讀到最新值（網路分區、reordering 仍可能讀舊）。詳見 Ch5。

---

R

Race Condition

中文：競態條件 多個執行緒 / 行程同時存取共享狀態，結果取決於誰先誰後。lost update、phantom 都是 race condition 的特例。詳見 Part 0.7。

Read Your Writes

中文：讀己寫 會話保證之一。使用者寫入後，自己的後續讀取一定能看到自己的寫——即使副本還沒同步給其他人。常見違反情境：使用者更新自己的個人資料後立刻刷新，但被路由到一個還沒同步的 follower，看不到自己剛改的內容。實作：寫後該使用者的讀請求路由到 leader、或記下寫入時間戳要求 follower 至少同步到該時間。詳見 Ch5。

Raft

中文：Raft 易理解的共識演算法（2014）。etcd、Consul、TiKV 採用。比 Paxos 好教學是它的設計目標。詳見 Ch9。

Read Repair

中文：讀修復 讀取時偵測到舊副本就順便寫回新值。leaderless 複製的修復機制之一。

Redundancy

中文：冗餘 故意保留多份備援（RAID 多顆磁碟、雙電源、多副本）。容忍個別元件失效——「容錯（fault tolerance）」的實作手段。

Replication

中文：複製 把同一份資料儲存在多個節點。三種架構：single-leader、multi-leader、leaderless。詳見 Ch5。

Reverse Proxy

中文：反向代理 位於 client 與後端之間，代表後端接收請求並轉發（Nginx、HAProxy）。負責 load balancing、SSL termination、cache、限流。

RPC (Remote Procedure Call)

中文：遠端程序呼叫 偽裝成本地呼叫的網路請求，但永遠無法真正等價於本地（會丟包、會 timeout、有變動延遲）。gRPC、Thrift 是典型實作。詳見 Ch4。

---

S

Saga 面試常考 ★

中文：Saga 模式 / 補償交易 跨多服務 / 多 DB 的長流程交易模式，把「分散式 ACID 交易」換成「多步本地交易 + 補償動作（compensating action）」。每個本地交易成功後對外發布事件、下一步接著做；任一步失敗就依序執行先前步驟的補償(如「扣款」對應「退款」)。

兩種變體：

• Orchestration：中央協調器(Temporal、AWS Step Functions、Camunda)發 command、追蹤狀態
• Choreography：各服務訂閱事件、各自決定下一步(無中央協調)

關鍵釐清：compensating action 不是 rollback——是「邏輯上的取消」(例：訂單失敗發退款、而不是 DELETE 已 commit 的記錄)。中間狀態對外可能可見、業務層要理解這個。

• ✓ 適合 microservices、跨異質系統、長執行時間
• ✗ 失去 ACID isolation——中間狀態對外可見、需業務層處理冪等

DDIA 主文未直接展開、但與 Ch11 stream processing + Ch12 Unbundling the database 是同源思想——「事件 log 當骨幹、補償取代 rollback」。詳見 Ch9 §9.4、Ch11。

Saga 反 pattern：用 Saga 偽裝的 distributed monolith

Saga 用得過頭也是病——把所有跨服務 call 都包成 Saga、結果做出比 monolith 還難維護的「分散式單體」。這是 2023+ event-driven 圈最常見的反 pattern。

症狀：

• 簡單 CRUD 操作也走 Saga（明明一個 service 內就能解、硬要分散式）
• compensating action 鏈長到沒人看得懂（5 步 Saga 失敗時、要回退 4 個 service）
• Saga 之間互相依賴（A Saga 啟動 B Saga、B Saga 又啟動 C Saga）

判斷原則：

• 跨真正獨立的 bounded context 才用 Saga（訂單 / 付款 / 庫存 / 物流 是好分界、user / userProfile 是壞分界）
• 能用單一服務的本地 transaction 解、就不要 Saga（即使涉及多個 entity）
• 每個 Saga 的步驟 ≤ 5（超過要警覺、可能是 bounded context 切錯）

真實案例：某公司把「使用者註冊」拆成 Saga（驗證 email → 建 user 紀錄 → 發歡迎信 → 建初始設定）、結果生產環境每個 Saga 平均跑 30 秒、註冊轉換率掉 15%。回頭改成「單一 service 內事務 + 後續異步任務」、註冊延遲降到 200ms。Saga 是工具、不是萬靈丹。

Saga 適用前提（三個都要成立才考慮）：

• 真的有「跨多服務的長流程交易」需求（不是 CRUD 隨手 call 別人 API）
• 業務允許「中間狀態對外可見」（如訂單從「已付款 → 取消中 → 已退款」）
• 各服務能提供 idempotent 的 compensating action

不該用 Saga 的場景：

• 流程能在單一服務 / 單一資料庫完成 → 直接 ACID transaction
• 跨服務但只需要最終一致 + 重試（不需要補償）→ event-driven workflow 但不寫 compensating handler
• 「我加個 Saga 因為流程很複雜」→ 通常是服務邊界沒劃對、先回頭看 Ch4 bounded context

Scalability

中文：可擴展性 「當負載成長時，能否用合理成本撐住效能」的能力。不是抽象的「快」，必須回答「成長到什麼程度、什麼指標還能維持」。詳見 Ch1。

Scale Up / Scale Out

中文：垂直擴展 / 水平擴展

• Scale Up（vertical）：把單台機器升級到更強。簡單，但有單機天花板。
• Scale Out（horizontal）：加更多機器分擔負載。可無限擴展，但要面對分散式系統難題。

Schema Registry

中文：Schema 註冊中心 集中存放 Avro / Protobuf / JSON Schema 定義的服務（Confluent Schema Registry、AWS Glue Schema Registry、Apicurio）。Kafka 生態典型用法：

• Producer 寫訊息時、把 schema 註冊或取 schema ID，訊息只攜帶 ID + payload
• Consumer 用 ID 反查 schema 解碼
• Registry 強制檢查相容性（向前 / 向後 / 完全）—— 不相容的 schema 註冊會被拒絕

好處：訊息瘦身（不夾 schema）+ 演進可追溯 + 跨語言型別安全。代價：多一個必須高可用的中間元件、failure mode 要規劃。詳見 Ch4。

Schema-on-read / Schema-on-write

中文：讀時 / 寫時 schema 讀時 schema（NoSQL、JSON）vs 寫時 schema（SQL）。詳見 Ch2。

Sequential Consistency

中文：順序一致性 Lamport 1979 提出。比 Linearizability 弱、比 Causality 強的一致性等級：

• 保證：所有節點看到的操作順序相同、每個 process 自己的操作順序保留
• 不保證：這個全域順序對應實時 real-time（操作 A 物理上比 B 早完成、不代表所有人看到的順序是 A → B）

直覺對比：

• Linearizability = sequential + real-time 順序
• Sequential consistency = 全域單一順序、但可以「整體往後挪」（時光錯位）

實務上純 sequential consistency 很少被當產品保證——要嘛拉到 linearizability（Spanner、etcd）、要嘛降到 causal consistency（COPS、TaoStore）。DDIA Ch9 把它放在「全序廣播 ≡ 共識」的等價討論中。詳見 Ch9。

Serializability

中文：可序列化 最強的隔離級別，效果如同所有交易循序執行。實作：2PL、SSI、Actual Serial Execution。詳見 Ch7。

Serialization Failure (SQLSTATE 40001)

中文：序列化失敗 DB 在 SERIALIZABLE / REPEATABLE READ 下偵測到並發衝突而主動 abort 第二個交易時拋出的錯誤。SQLSTATE 40001 是 SQL 標準（class 40 = transaction rollback、subclass 001 = serialization failure）；應用層必須 catch + retry 整個 transaction（重讀 + 重判斷 + 重寫）。

各家 DB 實際拋的錯誤碼：

• PostgreSQL：SQLSTATE 40001、訊息 could not serialize access due to concurrent update
• Oracle：ORA-08177（vendor 專屬 code）。SQLSTATE 多為 generic 72000——但這是 Oracle 把幾乎所有執行期錯誤都歸 72000（"SQL execute phase errors" class）的副作用、不是「ORA-08177 對映專屬 SQLSTATE 72000」的乾淨關係。實務判斷序列化失敗仍要看 vendor code ORA-08177
• SQL Server：error number 1205（deadlock）/ 3960（snapshot update conflict）—— 不用 SQLSTATE
• MySQL InnoDB：SQLSTATE 40001 + error 1213（同上、但只在 deadlock 場景拋；RR 仍不偵測 lost update）

不要與 Serialization（資料編碼）混淆

中文「序列化錯誤」可能指：

• Serialization Failure（本條）：DB 並發控制下的 abort，與 transaction / isolation 相關
• Serialization Error：JSON / Protobuf / Avro 編碼失敗（Ch4 議題），完全不同

讀錯誤訊息要看語境：app code 拋 JSONSerializationError 是後者、DB driver 拋 40001 是前者。

Sink

中文：接收端 事件流 / 訊息隊列的「下游目的地」——通常是要把資料寫到的最終系統（如 Elasticsearch、DB、HTTP API）。詳見 Ch11。

SLA / SLO / SLI

中文：服務水準協定 / 目標 / 指標

• SLA = Agreement，對外合約、違反賠錢
• SLO = Objective，對內目標、違反觸發 alert
• SLI = Indicator，量測值本身（一個數字）

詳見 Part 0.2。

Sloppy Quorum

中文：寬鬆法定人數 Dynamo 風格的可用性權衡：當「指定的 W 個副本節點」不可達時，協調節點把寫入暫存到任何可達的節點上、湊到 W 份就回 OK——這些「錯位的副本」之後再透過 Hinted Handoff 移交回原本該寄的節點。

• 嚴格 quorum：W + R > N、保證讀寫節點集合有交集 → 能讀到最新（前提是無並發寫）
• Sloppy quorum：W 份可能落在 N 之外的節點上 → 讀寫集合可能完全不交集 → 不保證讀到最新

Cassandra / Riak / DynamoDB 預設啟用——換取可用性（網路分區或部分節點掛時仍能寫），代價是放棄嚴格 quorum 的線性保證。DDIA Ch5 明確標出這個權衡、避免讀者誤以為「W+R>N」永遠成立。詳見 Ch5。

Snapshot Isolation

中文：快照隔離 每筆交易看到開始時刻的快照。現代 DB 多以 MVCC 實作（PostgreSQL、Oracle、SQL Server snapshot mode）。

對 phantom 的處理要分兩種：

• 讀取階段的 phantom（同交易兩次範圍查詢得不同列集合）—— SI 因為讀走快照能擋住
• 基於不存在性寫入決策（讀「沒有衝突」→ 寫一個；另一交易也讀「沒有衝突」→ 也寫一個 → commit 後共同違反原本檢查的前提）—— SI 擋不住，這是 Write Skew 的特例

要完全擋住第二種需要 Serializable（SSI 或 2PL with predicate lock）。詳見 Ch7。

Split Brain

中文：腦裂 網路分區後兩邊都自認為 leader，造成資料衝突。多數系統用 fencing token 或共識協定避免。

SQL

中文：結構化查詢語言 關聯式資料庫的標準查詢語言（1974 IBM）。宣告式：你說「要什麼」，DB 自己想「怎麼拿」（執行計畫由 query planner 決定）。詳見 Ch2 與 Part 0.3。

SSTable (Sorted String Table)

中文：排序字串表 LSM-Tree 的儲存單位——key 已排序的不可變檔案。詳見 Ch3。

Stateful Service

中文：有狀態服務 服務內部儲存資料（DB、message broker、Stateful set）。擴展困難得多——這就是 DDIA 整本書在處理的主題。

Stateless Service

中文：無狀態服務 服務本身不儲存任何請求之間的狀態，所有狀態都丟給 DB / Cache。橫向擴展時可以隨意加機器、任意請求路由到任一台。詳見 Part 0.1。

Strict Serializability

中文：嚴格可序列化 Serializability + Linearizability 的組合：交易能可序列化執行，且全局順序與實時順序一致（A 在 B 之前 commit → 任何後續觀察者看到的順序都是 A → B）。

• 比 Linearizability 多了：跨多物件
• 比 Serializability 多了：尊重實時順序（real-time order）

Spanner、CockroachDB、FoundationDB 提供這個保證——這是工業界目前最強的一致性等級。詳見 Ch9。

「強一致」家族四者邊界（讀者最常混淆）

等級	跨多物件？	尊重 real-time 順序？
Linearizability	否（單物件）	✓
Serializability	✓	✗
Strict Serializability	✓	✓
Snapshot Isolation	✓	✗（讀走快照）

很多人把這四者混為一談——它們是不同維度組合出的四個等級：「跨物件 vs 單物件」與「時序敏感 vs 不敏感」。

Stop-the-World GC

中文：全停式垃圾回收 JVM 老式 GC 進行時整個程式行程暫停，所有執行緒卡住。一次可暫停數秒到數十秒，是分散式系統「process pause」的最常見來源。

Stream-Table Duality

中文：串流-表對偶 表是某時刻流的快照，流是表的變更歷史。Kafka Streams 核心概念。

---

T

Tail Latency

中文：尾端延遲 延遲分布的高百分位段（P99 以上）。當一個請求要 fan-out 給多個後端，整體延遲被「最慢的那個」決定——這叫 tail latency amplification。詳見 Ch1 與 Part 0.2。

TCP (Transmission Control Protocol)

中文：傳輸控制協定 可靠、有序、有流量控制的傳輸層協定。三次握手建立連線、超時重傳保證可靠——但「可靠」是指最終會送到或斷線，不是即時。詳見 Part 0.6。

Thread

中文：執行緒 行程內的執行單元，共享記憶體空間。並行寫共享資料就是 race condition 的溫床。詳見 Part 0.5。

Throughput / QPS

中文：吞吐量 系統每秒能處理的請求或事件數量，單位常見 req/s、QPS（queries per second）、events/s。與 latency 是不同維度的指標。詳見 Part 0.2。

Total Order Broadcast

中文：全序廣播 所有節點按相同順序接收所有訊息。等同共識、等同線性一致儲存——這個等價性是 Ch9 的核心結果。

Two-Phase Commit (2PC)

中文：兩階段提交 Prepare + Commit/Abort。跨節點原子提交的傳統解。Coordinator 有單點失效風險。詳見 Ch9。

Two-Phase Locking (2PL)

中文：兩階段鎖 讀加共享鎖、寫加排他鎖，commit 才釋放。傳統 serializable 實作。

---

U

Unbundling the Database

中文：拆解資料庫 把傳統 DB 內建功能（索引、複製、materialized view）拆散，用事件 log 串接專門系統。詳見 Ch12。

---

V

Vector Clock

中文：向量時鐘 向量時鐘（Fidge 1988、Mattern 1989——不是 Lamport）。每個節點一個計數器組成向量，可判定兩個事件是「因果先後」還是「並發獨立」。

常見誤植

中文圈很多教材把 vector clock 歸給 Lamport——這是錯的。Lamport 1978 提出的是純量 Lamport timestamp（單一計數器、能給與因果一致的 tie-breaking 全序排列，但從 timestamp 大小無法反推因果方向——L(a) < L(b) 不蘊含 a → b，兩個事件可能是並發）。Vector clock 真正的作者是 Fidge & Mattern，1988-89 同時獨立提出，能完整判定因果先後 vs 並發獨立，表達力比 Lamport timestamp 強。

Version Vector

中文：版本向量 版本向量（Dynamo）。每個 replica 一個計數器，用於 KV store 的並發寫衝突偵測。形式上與 vector clock 相似但用途不同，口語常被混用；DDIA 與 Dynamo 系列論文中「version vector」指這個——不是 Lamport 的 vector clock。詳見 Ch5。

---

W

WAL (Write-Ahead Log)

中文：預寫日誌 修改前先寫日誌，保證 crash recovery。B-Tree 與許多儲存引擎的基礎。

Wall Clock

中文：掛鐘時間 真實世界時間（如 System.currentTimeMillis()、Date.now()）。可被 NTP 校正甚至向後跳，不能用於測量 duration 或排序事件——改用 monotonic clock。詳見 Ch8。

Watermark

中文：水印 串流處理中標記「我認為時間 T 之前的事件都已到齊」的進度指標。用於決定何時關閉 window 並輸出結果。詳見 Ch11。

Write Amplification

中文：寫放大 每寫入 1 byte 邏輯資料，實際引發更多 byte 的磁碟寫入。LSM 與 B-Tree 的關鍵效能指標。

Write Skew

中文：寫偏差 兩個交易讀相同前提、各自做不衝突的寫（寫不同列，或基於「目前沒有衝突列」插入新列），但 commit 後共同違反原本檢查的前提。

Berenson et al. 1995 對照：

• 經典跨列 write skew（A5B）：例「至少要有一位醫生值班」—— T1 T2 各讀到 2 人值班、各改自己的 active=false → 違反 ≥ 1 約束
• 基於不存在性的 phantom write（A3 延伸）：例「同一時段不能撞會議」—— T1 T2 各讀「該時段沒會議」、各插一個 → 兩個會議撞時段；A3 原指「讀取階段看到 phantom」，這裡是把該前提應用到寫入決策

SI 擋不住兩種（SI 只能對「已存在的列」做衝突偵測），需 Serializable（SSI / 2PL with predicate lock）。詳見 Ch7。

---

詞彙表怎麼維護

• 精簡定義（hover 用）：docs/.vitepress/data/glossary.ts —— SSOT
• 完整解釋（本頁）：本檔
• 新增 / 移除詞彙時兩邊都要同步；修改長定義只動本檔。