本文是 KeyDB overview 的 implementation-layer deep article。選型層（KeyDB vs Redis / DragonflyDB / Valkey、為何選 fork）見 overview；本文只處理「決定用 KeyDB active-active 後，衝突與一致性怎麼判」。命令實機驗證於 eqalpha/keydb image、最後檢查日 2026-06-16；複製機制以 KeyDB active-replication 文件 為準。

兩邊都能寫，聽起來太美好

Redis 的複製是單向的：一個 master 寫、replica 唯讀。要跨區讓兩邊都能就近寫入，Redis 本身做不到（得靠應用層分區或外部工具）。KeyDB 的 active-active 把這個限制拿掉——兩個（含以上）KeyDB 節點都是 master、都能接受寫入、互相把寫入同步給對方。對「兩個 region 都要低延遲寫入同一份 cache」的場景，這聽起來解決了所有問題。

問題藏在「兩邊同時寫同一個 key」的那一刻。active-active 沒有全域協調者來仲裁誰對誰錯，它用 last-write-wins（LWW）：比較兩筆寫入的時間戳，留下較晚的、默默丟掉較早的。多數時候沒事，但當兩個 region 在幾毫秒內各自更新同一個 key，其中一筆寫入會無聲消失——沒有錯誤、沒有日誌、application 以為自己寫成功了。

理解 KeyDB active-active 就是理解這個取捨：它用 LWW 換到了「兩邊都能寫」的可用性，代價是放棄了強一致與「不丟寫入」的保證。本文展開複製機制、衝突語意，以及哪些資料放得進這個模型、哪些放進去就是 bug。

核心概念：active-active 的複製與衝突語意

active-active 不是「分散式交易」，它是「雙向非同步複製 + LWW 衝突解決」。理解它要抓三個點：

每個節點都是 active-replica。一般 Redis replica 是唯讀的；KeyDB 的 active-replica 既接受本地寫入、又接收對方的複製流。兩個節點互相設定對方為 master，形成雙向複製環。實機看到的 role 就是 active-replica（不是 master / slave）。

複製是非同步的。本地寫入立即回 OK 給 client，之後才非同步傳給對方節點。這意味著兩個節點之間永遠有一個複製延遲窗口——在這個窗口內，兩邊看到的資料可能不同。這是 active-active 是 AP（可用性 + 分區容忍）而非 CP 的根本原因。

衝突用 last-write-wins 解決。同一個 key 在兩個節點被並發修改時，KeyDB 比較版本，保留較晚的寫入、丟棄較早的。沒有 merge、沒有 vector clock、沒有 application callback——就是比誰較晚。KeyDB 用 hybrid logical clock（HLC）排序、不是純 wall-clock，但 HLC 仍綁節點實體時鐘——時鐘不同步（clock skew）會直接影響哪一筆被判定為「較晚」。同步的是 key 的「值」不是「操作」，這也是為什麼並發 INCR 會互相覆蓋而非累加（見故障演練 Case 1）。

每筆寫入帶來源標記避免無限迴圈。A 的寫入同步給 B 後，B 不會再把它當成新寫入傳回 A（否則會無限循環）。KeyDB 用來源標記處理這個，但複製拓樸設計錯（例如環狀多節點）仍可能放大流量。

配置：兩節點 active-active 的設定路徑

實機驗證的最小雙主設定（兩個節點互相複製）：

1# 節點 A 與 B 都開 active-replica + multi-master
2docker run -d --name kdb-a --network kdbnet -p 6401:6379 \
3  eqalpha/keydb keydb-server --active-replica yes --multi-master yes
4docker run -d --name kdb-b --network kdbnet -p 6402:6379 \
5  eqalpha/keydb keydb-server --active-replica yes --multi-master yes
6
7# 互相指向對方（形成雙向複製）
8keydb-cli -p 6401 replicaof kdb-b 6379
9keydb-cli -p 6402 replicaof kdb-a 6379

實機驗證雙向同步（最後檢查日 2026-06-16）：

 1# 寫 A、讀 B
 2keydb-cli -p 6401 SET fromA hello   # → OK
 3keydb-cli -p 6402 GET fromA         # → hello   （A 的寫入同步到 B）
 4
 5# 寫 B、讀 A（雙向）
 6keydb-cli -p 6402 SET fromB world   # → OK
 7keydb-cli -p 6401 GET fromB         # → world   （B 的寫入同步到 A）
 8
 9# 確認 role 與複製鏈路
10keydb-cli -p 6401 INFO replication | grep -E "role|master_link_status|connected_slaves"
11# role:active-replica
12# master_link_status:up
13# connected_slaves:1

兩個節點都回報 role:active-replica（不是傳統的 master / slave），master_link_status:up 確認複製鏈路健康。寫入任一節點、另一節點都讀得到，這就是 active-active 的核心行為。

Production 故障演練

Case 1：並發寫同一 key、一筆寫入無聲消失

徵兆：兩個 region 的 application 各自更新同一個 user 的 cache（例如 profile），事後發現其中一個 region 的更新「沒生效」——但寫入時 application 收到的是 OK，沒有任何錯誤。

根因：active-active 的 LWW。兩筆寫入在複製延遲窗口內並發發生，KeyDB 比較時間戳保留較晚的、默默丟棄較早的。application 兩邊都以為自己寫成功了（本地確實 OK），但同步後只有一筆存活。

修法：

1. 不要讓同一個 key 被多個 region 並發寫——按 key 分區（user X 的寫入永遠路由到 region A），把多主退化成「就近讀 + 單點寫」
2. 真的需要多點寫的計數器類資料，用 CRDT 語意的結構（KeyDB 的 LWW 不適合 counter，並發 INCR 會互相覆蓋而非累加）
3. 接受 LWW 是 cache 的取捨——可重建的 cache 副本丟一筆寫入可回源重算，不可重建的資料不該放 active-active
4. 衝突無聲是最危險的——加應用層的寫入審計（不靠 KeyDB 告警）

Case 2：clock skew 讓「較晚」的判定錯亂

徵兆：明明 region B 後寫的值，最後存活的卻是 region A 先寫的值——LWW 的「後寫者勝」失效。

根因：LWW 比較時間戳，但兩個節點的系統時鐘若沒同步（clock skew），「較晚」的判定就錯了。B 的時鐘慢了 200ms，B 後寫的值帶的時間戳反而比 A 早，被判定為「較舊」丟棄。

修法：

1. 所有 KeyDB 節點強制 NTP 時鐘同步，把 skew 壓到毫秒級
2. 監控節點間的時鐘偏差，skew 超過複製延遲就有 LWW 判定錯亂風險
3. 對時間敏感的衝突，LWW 本質不可靠——時鐘永遠無法完美同步，這是 LWW 模型的固有弱點
4. 需要正確衝突解決的場景，不要用 LWW 的 active-active，改強一致儲存

Case 3：複製延遲下的 stale read

徵兆：region A 寫入後，立刻有請求打到 region B 讀同一 key，讀到舊值；幾百毫秒後再讀才是新值。

根因：active-active 是非同步複製，A 的寫入要經過網路傳到 B 才可見。在這個複製延遲窗口內，B 讀到的是 stale 值。跨 region 的延遲窗口比同 AZ 大得多。

修法：

1. 寫後需要立即一致讀的路徑，讀同一個寫入的節點（read-your-writes 綁定到寫入 region）
2. 監控節點間複製延遲，跨 region 的延遲是 stale window 的下界
3. 接受最終一致——這是 active-active 的本質，cache 場景多數可容忍短暫 stale
4. 不可容忍 stale 的資料不適合 active-active，走單寫入點 + 跨區唯讀 replica

Case 4：複製拓樸設計錯、流量放大或迴圈

徵兆：加了第三個 active 節點組成環狀後，節點間流量異常放大、CPU 升高，甚至同一筆寫入被反覆傳遞。

根因：active-active 多節點（> 2）的拓樸需要小心設計。全互連（full mesh）下每筆寫入要傳給所有其他節點、流量隨節點數平方成長；環狀拓樸若來源標記處理不當可能放大傳遞。

修法：

1. 多節點 active-active 優先用 full mesh 但控制節點數（active-active 不適合大量節點）
2. 監控節點間複製流量，異常放大代表拓樸或來源標記問題
3. 大規模多區優先考慮「每區單寫入點 + 跨區唯讀」而非全 active-active
4. active-active 的甜蜜點是 2-3 個區的雙向就近寫，不是大規模 mesh

Case 5：節點重連後的全量重同步衝擊

徵兆：一個節點短暫斷線後重連，重連瞬間 CPU / 網路尖峰，期間延遲升高。

根因：節點斷線時間過長、超過複製 backlog 能覆蓋的範圍，重連時要做全量重同步（full resync）——對方節點要產生快照（fork、見 Redis persistence 的 fork 成本，KeyDB 繼承 Redis 的 fork 機制）並傳輸整個 dataset。

修法：

1. 設足夠大的 repl-backlog-size，讓短暫斷線走部分同步（partial resync）而非全量
2. 重同步的 fork 成本跟記憶體 headroom 相關，節點要留 fork 空間
3. 監控 master_link_status，頻繁 down / up 代表網路不穩、要先修網路
4. 跨 region 的 active-active 對網路穩定性敏感，不穩的鏈路會頻繁觸發重同步

Capacity / cost 邊界

active-active 的容量判讀，核心在衝突率與複製健康：

撞牆後的路由判斷：

• 需要正確的衝突解決 / 不能丟寫入：LWW 不保證，走強一致儲存（database 模組 的 multi-region 一致性方案）或單寫入點架構。
• 需要 counter / 累加語意的多點寫：LWW 會讓並發 INCR 互相覆蓋，KeyDB active-active 不適合，改 CRDT 或單點 counter。
• 跨 region 但可接受單寫入點：用 Redis / Valkey 的單向複製（一區寫、其他區唯讀），比 active-active 簡單且無衝突。
• 大規模多區：active-active 的甜蜜點是 2-3 區，更大規模走 managed 的跨區方案（ElastiCache Global Datastore 的 active-passive）。

整合 / 下一步

active-active 是 KeyDB 區別於 Redis 的核心能力之一，但它的取捨跨多個子系統：

• 跟 KeyDB overview：overview 點到 active-active 是 last-write-wins、本文展開它什麼時候默默丟資料。
• 跟 Redis persistence / fork latency：KeyDB 繼承 Redis 的 fork 機制，節點重連的全量重同步付 fork 成本。
• 跟 cache copy boundary：active-active 的 stale window 與 LWW 丟寫入，本質是「cache 副本的新鮮度與一致性邊界」議題的多主版本。
• 跟 Snap KeyDB cross-cloud case：Snap 用 KeyDB 的主因是 cross-cloud latency 治理（cache 與 application 共置），active-active 的雙向就近寫是這類 multi-cloud 場景的工具，但要按 key 分區避開 LWW 衝突。

相關連結

• 上游 vendor 頁：KeyDB
• 對照 vendor：DragonflyDB 多核架構、Redis Sentinel failover（單向複製的 HA）
• 上游概念：2.7 cache copy boundary
• Methodology：Vendor 深度技術文章寫作方法論

本文是 PostgreSQL overview 的 implementation-layer deep article。Overview 已說明 PG 在 OLTP 譜系的定位、本文聚焦 multi-master / active-active replication — 不是 PG 預設、需要 extension。

PG 預設沒 multi-master、得用 extension

PG core 是 single-primary streaming replication：

• 寫入只能進 primary
• Standby 接受 read（hot_standby）但拒絕 write
• Failover 後新 primary 接管、不能多入口

對需要 active-active（多 region 各自接受 local write）的場景、PG 提供 3 條 extension 路徑：

每條路徑有不同 trade-off。對 99% PG production case、不需要 multi-master — single-primary streaming replication + read replica scaling 已夠。Multi-master 是 特殊需求（跨 region active-active write / 不可中斷 maintenance）才上。

跟 MySQL Group Replication 對比：MySQL GR 是 官方內建（5.7+）、PG 沒對應內建選項。MySQL 用戶 GR / InnoDB Cluster 直接套、PG 用戶要選 extension + license trade-off。

Multi-master 三方案對比

方案 1：BDR (EDB Postgres Distributed)

EDB 商業 distributed 方案、跑在 EDB Postgres Advanced Server 或 PG community 上。

特性：

• 雙向 logical replication、N-way active-active
• Built-in conflict detection + resolution（LWW / column-level / user-defined）
• Eager（sync）跟 async 兩種 mode
• Tightly integrated with EDB tooling

Trade-off：

• 商業 license、EDB 訂閱
• 對 cross-region multi-master 成熟（北美 enterprise 廣用）
• 對 新 PG version 通常滯後幾個月

方案 2：pgEdge（基於 Spock extension）

pgEdge 開源 multi-master、基於 Spock extension（從 BDR 衍生）：

特性：

• 開源、可自管
• 跟 BDR 架構接近、無 license fee
• Conflict resolution 用 LWW + column-level
• 對 edge / 地理分散 場景設計

Trade-off：

• 較新（2023+）、社群驗證度低於 BDR
• Conflict resolution policy 比 BDR 簡單
• 部分 EDB 商業 feature 沒對應

方案 3：Bucardo

PG community async multi-master、Perl 寫、trigger-based：

特性：

• 完全開源
• Trigger-based（不依賴 logical replication）
• 支援 multi-source replication（fan-in / fan-out）

Trade-off：

• Async only — higher latency conflict
• Trigger overhead（影響 primary 寫吞吐）
• 維護 Perl + tools chain 不普及
• 對 Sync 一致性 需求不適用

Multi-Master Conflict Model

任何 multi-master 方案都要解決 同一 row 兩地同時改 的 conflict：

Conflict 來源

1Region A (primary 1)          Region B (primary 2)
2UPDATE orders                 UPDATE orders
3SET status='shipped'          SET status='cancelled'
4WHERE id=100                  WHERE id=100
5     ↓                              ↓
6   合併？哪個贏？

跨 region 兩地各自 commit、replication lag 期間發現 conflict、必須 自動 resolve（不能丟給 application）。

Conflict Resolution Strategies

1. Last-Write-Wins (LWW) — 最常見：

• 比較 transaction commit timestamp、晚的贏
• 簡單但 data loss（前一個 commit 的變更被覆蓋）
• 需要 clock 同步（NTP）— clock skew 造成不可預測

2. Column-level conflict resolution：

• 不同 column 各自 LWW（status column 跟 amount column 獨立解）
• 比 row-level LWW 細、但需 application semantics 配合

3. User-defined trigger：

• 寫 PG function 解 conflict
• 對 特殊 business logic（如：金額相加、不是覆蓋）有用
• 維護成本高

4. Manual reconciliation：

• Conflict 寫進 log table、application / DBA 手動處理
• 對 無法自動 resolve 場景（如金融）
• 高 ops cost

對 99% case 用 LWW、接受 small data loss、application 設計 idempotent / commutative 操作避免衝突。

Conflict 機率取決於 application pattern

• Tenant-isolated application（user_id 各自寫自己的 row）：基本無 conflict
• Shared counter / inventory application：高 conflict、multi-master 不適合
• Append-only event log：conflict 低、適合 multi-master

配置 step-by-step（pgEdge 為主）

pgEdge 開源、最常見的 self-hosted 選擇。

Step 1：在每個 region node 裝 pgEdge

1# Install pgEdge CLI
2curl -fsSL https://pgedge-upstream.s3.amazonaws.com/REPO/install.py | python3
3
4# Setup PG + Spock + pgEdge
5./pgedge install pg16
6./pgedge install spock

Step 2：配置每個 node

1-- 在 node1（us-east） 跑
2SELECT spock.node_create(node_name := 'node1', dsn := 'host=node1.example.com port=5432 dbname=production');
3
4-- 在 node2（eu-west）跑
5SELECT spock.node_create(node_name := 'node2', dsn := 'host=node2.example.com port=5432 dbname=production');

Step 3：建 replication set + subscribe

 1-- 在 node1 建 default replication set + 加 tables
 2SELECT spock.repset_add_all_tables('default');
 3
 4-- 在 node1 subscribe node2
 5SELECT spock.sub_create(
 6    subscription_name := 'sub_n1_n2',
 7    provider_dsn := 'host=node2.example.com port=5432 dbname=production'
 8);
 9
10-- 在 node2 subscribe node1（雙向）
11SELECT spock.sub_create(
12    subscription_name := 'sub_n2_n1',
13    provider_dsn := 'host=node1.example.com port=5432 dbname=production'
14);

Step 4：設 conflict resolution

1-- 設 LWW（預設）
2SELECT spock.conflict_resolution_setting_set(
3    conflict_type := 'update_origin_change',
4    resolution_setting := 'apply_remote'
5);

Step 5：驗證

1-- 看 subscription 狀態
2SELECT * FROM spock.subscription;
3
4-- 看 replication lag
5SELECT * FROM pg_stat_replication;

5 個 Production 踩雷

1. LWW data loss — Application 沒設計 commutative

LWW 預設、兩 region 同時 UPDATE 同 row → 晚的 commit 贏、早的丟失。Application 看不到「我寫的不見了」、debug 困難。

修法：

• Application schema 設計 tenant-isolated（user_id 各自寫自己 row）
• 對 shared counter / inventory 用 commutative operation（INCREMENT not SET）
• 重要寫入加 audit log — conflict 仍寫到 audit、application 看 audit 知道發生過
• 真的需要 strict consistency 別用 multi-master、用 single-primary + reader 或 distributed SQL

2. Sequence collision — Two region 各自 next 同號

SERIAL / IDENTITY 用 sequence、兩 region 各自 nextval 可能拿到同 number、INSERT 衝突（PK duplicate）。

修法：

• 用 staggered sequence range：node1 用 1-1M、node2 用 1M+1 到 2M（用 setval）
• 或用 UUID（v4 / v7）作 PK、跨 node 無 collision
• 或 sequence per-node namespace：CREATE SEQUENCE orders_id_node1 START 1 INCREMENT 2（odd vs even）

3. DDL replication 不自動

PG logical replication（pgEdge / BDR 基礎）不自動 replicate DDL。每 node CREATE TABLE / ALTER TABLE 必須 分別跑。

修法：

• 用 deployment automation（Ansible / Terraform）對所有 node 同時跑 DDL
• pgEdge 提供 spock.replicate_ddl(...) 把 DDL 轉成可 replicate event
• BDR Enterprise 有 DDL replication（商業 feature）
• DDL 變更前確認 所有 node 都健康、減少 partial state

4. Conflict log 治理 — Log table 爆滿

每個 conflict 寫進 spock.conflict_log / bdr.conflict_history 等 table、log 累積 disk 爆。

修法：

• 設 log retention：cron 定期 archive + delete 老 conflict log
• 監控 conflict rate — 高 conflict rate 是 application 設計問題（不是 ops 問題）
• 對 strict business conflict 寫進 application-level audit table、不只 system log

5. Failover 後 timeline 分歧

Multi-master 設計上 每 region 是 primary、Region A 掛了 Region B 接管 — 但 Region A 復活後 仍認為自己是 primary。如果 Region A 復活前已有寫入沒 replicate 出去、resolution 跟 LWW 衝突。

修法：

• Fence Region A 復活：物理 fence（network firewall）+ 手動 unfence 流程
• 用 etcd / Consul 跟 BDR / Spock 整合 leader election（避免 split-brain）
• 對 cross-region multi-master、必須有 runbook 處理 region 復活流程、不靠自動

何時用 multi-master vs 不用

跟 MySQL Group Replication 對比

MySQL GR 內建 + Oracle 推、PG 沒對應內建。對 multi-master 需求重的 org、MySQL 走 GR 路徑更直接。

跟其他模組整合

跟 Replication Topology

Multi-master 是 streaming replication 之上的 logical replication 加雙向、不取代 streaming。Streaming 仍給 standby / failover、multi-master 給 active-active write。詳見 Replication Topology。

跟 Logical Replication

pgEdge / BDR 都基於 logical replication slot、跟 Logical Replication + Debezium 共用 PG logical decoding infrastructure、但 配置 + tooling 不同。

跟 MVCC

Multi-master 的 conflict 在 commit 後 偵測（async）、不在 transaction 內。跟單機 MVCC（同 cluster 內 transaction snapshot）不同層。詳見 MVCC + Lock Model。

相關連結

• PostgreSQL vendor overview
• PG Replication Topology（streaming + multi-master 共存）
• PG Logical Replication + Debezium（logical decoding 基礎）
• PG MVCC + Lock Model（multi-master conflict vs 單機 MVCC）
• PG Patroni HA（single-primary HA 替代方案）
• 1.11 全球分散式 OLTP（multi-master vs distributed SQL）
• MySQL Group Replication（sibling、不同實作）
• 官方：EDB BDR / pgEdge / Spock GitHub / Bucardo

本文是 Cosmos DB vendor 頁 的深度展開、也是 Strong + multi-region 互斥 議題的 SSoT 主寫位置（consistency-levels-engineering cross-link 過來、不展開）。Case anchor 是 9.C11 Minecraft Earth（AR 遊戲跨 region 寫入、5 consistency level + multi-region SLA）+ 9.C21 ASOS（Black Friday 全球零售）+ 9.C38 Toyota Connected（鏈路 SLA 拆解、跨 vendor 適用做 frame anchor）。

Cosmos DB 適用度前置判讀：本篇假設 workload 已通過 Cosmos DB 適用度四層 framing（API model 三型遷移路徑 / RU 思維轉換成本 / multi-model 差異化是否真用上 / 跨雲 hedging vs 單雲 lock-in）— 詳見 mongodb-api-vs-sql-api 開頭四層 framing、本篇不重複展開。Multi-region write + conflict resolution 是 已選 Cosmos DB 後 的拓樸決策；strong global consistency 必要的 workload 應走 Spanner 或 Cosmos DB Strong（單一 write region）、不是用 LWW 補。

問題情境：active-active 的 conflict 是必然代價

典型觸發場景：產品要 global active-active（每個 region 都能寫、低延遲）、Cosmos DB 是 AP 系統、不像 Spanner 用 quorum 強一致；跨 region 寫同一筆 document 必然有 conflict、團隊不知道「conflict 真的發生時、誰贏 / 怎麼處理 / 業務語義保不保得住」。

讀者徵兆：

• 「multi-region write 開了、user 在 A region 寫『加入購物車』、B region 寫『移除購物車』、最後哪個贏」
• 「LWW 用 timestamp 決定、client clock skew 不就破壞了嗎」
• 「conflict feed 是什麼、要不要消費」
• 「multi-region write 開了之後 consistency level 還能設 Strong 嗎」
• 「廣告寫 99.999%、為什麼實測只有 99%」

真實壓力：購物車跨 region 寫入丟失、遊戲玩家狀態跨 region 衝突回滾、IoT device 跨 region 寫 telemetry 後消失。這些事故的根因不是 bug、是 multi-region write 的 設計取捨、需要在 selection 階段就決定 conflict resolution policy。

核心機制

AP 取捨的硬約束：為什麼 Strong + multi-region write 互斥

Cosmos DB 是 AP 系統（在 partition 的情況下選 availability 跟 partition tolerance、放棄 cross-region linearizability）。multi-region write 的兩個前置條件：

• account 開啟 enableMultipleWriteLocations = true
• consistency level 不能設 Strong（multi-region write 跟 Strong 互斥、時間敏感 claim、查 最新文件）

為什麼互斥（CAP 三選二的硬約束）：

• Strong consistency 在 Cosmos DB 的實作是 quorum-based linearizable read — 確保 read 拿到最新 commit、需要 單一 write region 來保證寫入順序
• Multi-region write 是 active-active、每個 region 都能寫 — 不存在「單一 write region」、寫入是 LWW-based eventual consistency
• 兩者在技術上 不能同時成立 — 不是 Microsoft 工程選擇問題、是 distributed system 的基本限制（跟 Spanner 用 Paxos quorum + TrueTime 不同的設計路徑）

對 selection 的意義：產品要「全球都能寫」就接受 eventual consistency；產品要「全球 linearizable」就轉 Spanner / Aurora DSQL、Cosmos DB 不是替代品。把 Cosmos DB Strong 跟 Spanner external consistency 等同視之是 常見的選型誤判。

consistency-levels-engineering 的 Strong 段只 cross-link 過來、不展開 conflict resolution 細節 — 本篇是 SSoT 主寫位置。

Conflict 偵測

同一 document（partition key + id）在多 region 並發寫入、Cosmos DB 偵測為 conflict。偵測機制基於 LSN（log sequence number）、不是 timestamp — 兩個 region 對同一 document 寫入時、replication 過程比對 LSN 發現分歧、進 resolution。

三種 conflict resolution policy

LWW（Last-Writer-Wins、預設）

• 機制：用 _ts（system timestamp）或自訂 numeric property、value 大的贏
• 副作用：clock skew 在 ms 級就能讓「先寫的反而贏」、業務邏輯破洞
• 適合：純覆寫場景（如玩家位置最新值、IoT 最新讀數）— write 順序不影響業務語義

1"conflictResolutionPolicy": {
2  "mode": "LastWriterWins",
3  "conflictResolutionPath": "/customTimestamp"
4}

Custom merge stored procedure

• 機制：寫一個 JavaScript stored proc、conflict 時 Cosmos DB 呼叫、proc 回傳 merge 結果
• 適合：要保留業務語義的場景（購物車 merge = union 兩邊 items、計數器 merge = sum、status 機器 merge = 狀態圖規則）
• 風險：stored proc 在 Cosmos DB JavaScript runtime 跑、有 timeout / RU 限制；複雜 merge 邏輯難 debug

1"conflictResolutionPolicy": {
2  "mode": "Custom",
3  "conflictResolutionProcedure": "dbs/mydb/colls/mycoll/sprocs/resolveCart"
4}

Conflict feed manual reconciliation

• 機制：Cosmos DB 把 conflict 寫入 conflict feed、不自動解決、app 自行消費並 reconcile
• 適合：conflict 需要人工 / 業務流程判斷、不能 auto-resolve（如金融交易、合規場景）
• 風險：feed 不消費就累積、後續分析失準；app 需要實作 reconcile 流程

1"conflictResolutionPolicy": { "mode": "Custom" }

（沒指 procedure、conflict 全進 feed、app 用 SDK ReadConflictsAsync() / Change Feed Processor pattern 消費）

跟其他 vendor 對比

• DynamoDB Global Tables：也是 LWW、無 custom merge、無 conflict feed — 行為比 Cosmos DB 簡單但彈性少
• Spanner：用 Paxos quorum、不會有 conflict（CP 系統、可用性換一致性）— 跨 region write 需 quorum、latency 100-200ms
• Aurora Global Database：single-primary（一個 region 寫、其他 region 讀）、不是真 multi-region write、無 conflict

對應 knowledge cards：stale-read、rpo、rto。

操作流程

開啟 multi-region write

1az cosmosdb update --name mycosmos --resource-group myrg \
2  --enable-multiple-write-locations true \
3  --locations regionName=eastus failoverPriority=0 \
4  --locations regionName=westeurope failoverPriority=1

開啟後 不能直接關回、要 disable + 改 region 配置 + re-enable、有停機窗口。

設定 LWW policy（container 層）

建 container 時指定、可事後改但 conflict 行為以新 policy 為準（既有 conflict 不會重 resolve）。預設用 _ts 比較；改成 customTimestamp 時要保證 application 寫入時 用單調遞增 的 timestamp source（不能用 client clock）。

設定 custom merge

建 stored proc：

1function resolveCart(incomingItem, existingItem, isTombstone, conflictingItems) {
2  // 範例：merge 購物車 items（取 union）
3  var merged = existingItem;
4  merged.items = mergeArrays(existingItem.items, incomingItem.items);
5  merged._ts = Math.max(existingItem._ts, incomingItem._ts);
6  __.response.setBody(merged);
7}

1"conflictResolutionPolicy": {
2  "mode": "Custom",
3  "conflictResolutionProcedure": "dbs/mydb/colls/mycoll/sprocs/resolveCart"
4}

驗證：proc 內處理 timeout / exception；測 edge case（空 array / null / 並發 3+ region 寫入）。

消費 conflict feed

1// .NET SDK
2var iterator = container.GetItemQueryIterator<ConflictProperties>(
3    "SELECT * FROM c");
4while (iterator.HasMoreResults) {
5    var response = await iterator.ReadNextAsync();
6    foreach (var conflict in response) {
7        await ProcessConflict(conflict);
8    }
9}

用 Change Feed Processor pattern 把 conflict feed 當 stream 消費、寫到 reconcile queue、由業務流程處理。

驗證點

• 跨 region 並發寫測試（synthetic load）、觀察 conflict count / resolution result
• Custom merge stored proc 跑過 edge case（exception / null / 並發 3+）
• Conflict feed 不積壓（lag < 5 min）
• Region 故障時 application 仍能寫（active-active 設計、不需 manual failover）

失敗模式

Failure 1：全用 LWW + 用 server timestamp

clock skew 在 ms 級可能讓「先寫的反而贏」、業務邏輯破洞。常見徵兆：使用者反映「我明明先按確認、後來改的反而是舊的」、debug 才發現是跨 region clock skew。

修：

• 用 customTimestamp 從 application 端 monotonic source 取（如 Snowflake ID、HLC、Lamport clock）
• 或改用 custom merge stored proc、用業務邏輯而非 timestamp 決勝
• 或拆 collection、把 conflict 高的 collection 用 stored proc、低的用 LWW

Failure 2：業務語義不適合 LWW

購物車（要 union）、計數器（要 sum）、status 機器（要狀態圖）全用 LWW = 資料丟失。LWW 的設計假設是「最新 write 就是正確答案」、但很多業務語義不是覆寫關係。

修：盤點 collection 的業務語義、選對應 resolution policy：

• 覆寫關係 → LWW
• 累積關係 → custom merge stored proc（union / sum / set 合併）
• 狀態機 → custom merge stored proc（按狀態圖規則 resolve）
• 需要人工裁決 → conflict feed

Failure 3：Custom merge stored proc 沒測 edge case

proc throw exception 時 Cosmos DB 行為：conflict 留 feed、不會自動 retry。團隊以為 proc 跑了就沒事、實際 conflict 累積在 feed、後續分析失準。

修：proc 內部 try-catch、log exception、確保 任何輸入都能 return 一個合理結果（即使是 fallback 到 LWW）；定期掃 conflict feed 檢查積壓。

Failure 4：不消費 conflict feed

選 manual mode 後忘記實作 feed consumer、conflict 累積、後續分析失準。常見徵兆：feed lag metric alert、或業務反映「資料對不上」、最後發現 conflict feed 裡躺著一堆未處理的 conflict。

修：選 conflict feed mode 前先實作 consumer pipeline（Azure Function trigger on Change Feed / 自建 worker）；設 alert：feed lag > 5 min 通知。

Failure 5：期待 multi-region write 還有 Strong consistency

兩者互斥、開啟 multi-region write 後 Strong 自動 downgrade（或拒絕設定、時間敏感、查最新文件）。團隊以為「multi-region + Strong = 全球 linearizable」、底層是設計 incompatibility。

修：在 selection 階段就決定「要 active-active write 還是要 Strong」 — 兩者只能擇一。要全球 linearizable 轉 Spanner / Aurora DSQL、要 active-active 就接受 eventual / session / bounded staleness。

Failure 6：跨 region 寫入後立即同 session read 看不到

session token 沒跨 region 傳遞、看似 inconsistency 其實是 session 沒對齊。典型 anti-pattern：service A 在 region 1 寫、用 region 1 session token；service B 在 region 2 讀、沒拿到 A 的 token、看不到 A 的寫。

修：session token 隨 request 傳遞（通常進 HTTP header）；或改 account 層 Bounded staleness（提供跨 session 的 K/T bound）；見 consistency-levels-engineering 的 session token 管理段。

Failure 7：Region 故障時的 failover 邏輯誤判

multi-region write 已是 active-active、不需要 manual failover — 一個 region 掛、其他 region 自動承接寫入。但若用了 failoverPriority 配置、failover 邏輯仍要審 — priority 是 當 multi-region read 切到哪個 region 為 primary、不是 active-active 的 routing。

修：multi-region write 場景不用依賴 failoverPriority、用 Traffic Manager / Front Door 做 region routing；application 端 SDK 配置 PreferredLocations 讓 SDK 自己選 nearest region。

容量與觀測

• 必看 metric：ConflictCount、ReplicationLatency per region pair、conflict feed lag
• Conflict rate 監控：正常 < 0.01%、突增代表 hot key 或 region 同步異常
• Cost 影響：multi-region write 開啟後、寫入成本 × region 數（每個 region 都 replicate）— 3 region active-active = 3x write Request Unit cost
• 對應 9.6 容量規劃模型：multi-region write multiplier 進 sizing
• 對應 4.20 Observability Evidence Package：conflict rate 當 reliability evidence
• Alert：conflict rate > 0.1%、conflict feed lag > 5 min、cross-region replication lag > SLA

廣告 SLA vs 實測可用性鏈路拆解（本章合成 frame）

9.C11 Minecraft Earth 平台揭露的 Cosmos DB SLA：

• single-region 99.99%
• multi-region 99.999%

這是 DB 端 SLA、不是 端到端系統 SLA。真實 production 系統的可用性是鏈路乘積：

1實測可用性 = DB SLA × 網路 SLA × 應用層 SLA × 客戶端可達性

9.C38 Toyota Connected 揭露「99.99% target vs 99% 實測」段的觀察：兩個 9 的差距 不是 MongoDB / Atlas 自身問題、是 end-to-end 鏈路（車輛無線網路 / cellular tower / cloud network / event bus / microservice / DB cluster 任一環節掉都會打掉可用性）。Cosmos DB multi-region write 同模型：

• 多 region active-active 可解 DB 端可用性、但網路 / 應用層任一掉、實測仍 < 99.99%
• 廣告 99.999% 是 multi-region availability zone 級、不是 「使用者 request 成功率」

引用時必須明示：Cosmos DB multi-region 廣告 99.999% 是 DB 端、要算實測可用性必須補網路 / 應用層 SLA 乘積、Toyota case 的「99% 實測」揭露的就是這個鏈路問題、跨 vendor 都適用。

跟 conflict resolution 的關係：多 region 高可用性 買來 的代價是 conflict、conflict rate 是 reliability 的暗稅 — 廣告 SLA 不計 conflict 處理成本。production 設計要把「conflict resolution 的工程成本」加進 multi-region write 的 ROI 評估。

邊界與整合

• Sibling deep articles：consistency-levels-engineering（multi-region write 跟 Strong 互斥的 cross-link 來源）、partition-key-design（hot partition 會放大 conflict）、ru-cost-model-sizing（multi-region cost × region 數）
• 跟 Spanner vendor 對比：CP vs AP、無 conflict vs LWW / custom
• 跟 DynamoDB Global Tables 對比：兩者都 LWW、Cosmos DB 多 custom merge + conflict feed
• 跟 1.x 章節：1.11 全球分散式 OLTP 把 multi-region write 模式並陳
• Knowledge cards：stale-read / rpo / rto
• Anti-recommendation：single-region write + cross-region read replica 在大多數情況更便宜、更易推理；只有 write residency 是產品契約（合規 / latency / 業務需求）時才升 multi-region write

相關連結

• Cosmos DB vendor overview — 本文是該頁尾 multi-region write + conflict resolution backlog 的深度展開
• 9.C11 Minecraft Earth case — multi-region 99.999% / single-region 99.99% SLA 來源
• 9.C21 ASOS case — 全球零售 multi-region 補充
• 9.C38 Toyota Connected case — 鏈路 SLA 拆解 frame anchor（跨 vendor 適用）
• consistency-levels-engineering — Strong + multi-region 互斥的 cross-link 目的地
• Stale Read 卡片 / RPO 卡片 / RTO 卡片 — 概念基底
• 官方：Cosmos DB conflict resolution / Multi-region writes