🎯 什麼情境該想到我
當一個業務動作要跨多個服務/資料庫、卻無法用單機交易保證「要嘛全成、要嘛全敗」時。
⚙️ 怎麼用（依一致性需求選方案，沒有銀彈）
- 可靠訊息佇列（本地訊息表 = Outbox）：把業務寫入與事件記錄放同一本地交易，再由 relay 投遞 → 最終一致。最常用、最務實（見 工具-Transactional-Outbox-Pattern）。
- TCC（Try-Confirm-Cancel）：業務層自己實作預留/確認/取消，強一致但侵入性高、開發成本大。
- Saga：把長交易拆成一連串本地交易 + 對應的補償動作，失敗就反向補償。適合長流程。
- 2PC/XA：強一致但同步阻塞、協調者單點，效能差，少用於高併發。
先問：這個場景需要強一致，還是最終一致就好？多數選最終一致（1）。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 別預設「一定要強一致」；強一致代價很高。也別在 DB 交易內直接發 MQ。
🔗 相關工具
- 工具-Transactional-Outbox-Pattern —— 最常落地的一種實作：用本地交易＋Outbox 換掉 2PC 的分散式鎖
- 工具-交易與隔離等級 —— 單機版的對照組，先懂單機保證了什麼，才知道跨服務失去了什麼
- 工具-MQ消費端防禦三原則 —— 走最終一致路線後的必要配套：consumer 必須能承受重複與亂序