聊聊微服務中的事務管理
幾乎所有的信息管理系統都會涉及到事務，事務的目的是為了保證數據的一致性，這里說的一致性是數據庫狀態的一致性。
說到數據庫狀態的一致性，相信大家都會想到 ACID ：
- 原子性（Atomic）：在一個事件的多個數據庫操作中，要么同時成功，要么同時失敗，例如：轉賬業務。
- 隔離性（Isolation）：不同的業務之間處理數據相互獨立，互不影響。
- 持久性（Durability）：正常提交的數據能夠被持久化，不丟失數據，比如 mysql 天然就能持久化，redis 、 rabbitmq 也能通過設置進行持久化。
- 一致性（Consistency）：最終的數據正確，所以說是通過 AID 這些手段來保證了 C 。
在單體架構中，通常是一套程序對應一個數據庫，事務基于數據庫本身的能力,如果你在 .NET Core 中使用 dapper 或 sqlsugar ，可以很容易進行事務的處理，可以參考下面文檔：
https://dapper-tutorial.net/transaction 。
https://www.donet5.com/Home/Doc?typeId=1183。
但是，在微服務架構，分布式的場景中，事務的處理就會變得復雜，會存在多個節點，多個節點的同步、可用性等都是需要考慮的問題，在分布式中有一個著名的 CAP 理論：
- C：數據一致性（Consisitency）：分布式中存在多個節點，對某個指定的客戶端來說，從任一節點讀取的數據保證獲取到的是最新寫入的數據。
- A：可用性（Acailability），非故障節點在合理的時間內返回合理的響應（不是錯誤和超時的響應）。
- P：分區容錯性（Partition Tolerance），節點之間的數據傳遞是基于網絡的，由于網絡本身不是 100% 可靠，極端情況下會出現網絡不可用的情況，進而將網絡兩端的節點分隔開來，這就是所謂的「網絡分區」現象。在出現網絡分區時，兩部分的數據是不一致的，如果要保證數據的一致性，就必須要讓沒有及時同步數據的節點變為不可用，這就犧牲了可用性，否則就會犧牲一致性，所以在 P 一定存在的情況下，需要在 C 和 A 中間做取舍。
我們在 CAP、ACID 中討論的一致性稱為「強一致性」（Strong Consistency），而把犧牲了 C 的 AP 系統，但又要保證最終的結果是一致的，稱為「弱一致性」，也叫最終一致性。最終一致性的概念由 eBay 的系統架構師丹 · 普利切特（Dan Pritchett）在 2008 年發表于 ACM 的論文「Base: An Acid Alternative」中提出的。
本文主要說下保證一致性的幾種方式：TCC、SAGA 和消息隊列。
TCC
TCC 是 Try-Confirm-Cancel 的縮寫，表示將整個過程分為了三個階段：
- Try：一個請求涉及到多個服務，多個服務會同時進行 Try，這個階段為嘗試執行階段，在這個階段中會進行數據的校驗、檢查，保障一致性，并準備資源，都成功會進入到 Confirm 階段。
- Confirm：確認執行階段，不進行任何業務檢查，多個服務的 Try 都執行成功了，多個服務都進入到 Confirm 階段，在這個階段直接使用 Try 階段準備的資源來完成業務處理。注意，Confirm 階段可能會重復執行，因此需要滿足冪等性。
- Cancel：如果在 Try 階段有一個服務沒有成功，那么所有的服務都進入到 Cancel 階段，在該階段，釋放 Try 階段預留的業務資源。注意，Cancel 階段也可能會重復執行，因此也需要滿足冪等性。
在 .NET Core 中可以參考：
https://github.com/simpleway2016/JMS。
在 Java 中可以使用 seata：
https://github.com/seata/seata https://seata.io/zh-cn/。
因為在 TCC 中的第一步 Try 需要預留資源，進行檢查和校驗，但在某些場景下，資源不是我們所能控制的，比如支付中，余額是銀行管理的，我們通常沒有權限。所以這時就不太適合 TCC ，可以考慮用 SAGA 來代替 TCC。
SAGA
SAGA 起源于 1987 年普林斯頓大學的赫克托 · 加西亞 · 莫利納（Hector Garcia Molina）和肯尼斯 · 麥克米倫（Kenneth Salem）在 ACM 發表的一篇論文《SAGAS》。
SAGA 和 TCC 最大的區別是基于數據補償機制來代替回滾。一個 SAGA 表示處理多個服務中數據的一系列操作，由一連串的本地事務組成，每個獨立的本地事務中還是能夠使用 ACID 。
SATA 由兩部分組成：
- 將一個大的事務拆分成的若干個小的事務，比如一個大的事務 T ，拆分成 T1、T2、T3。
- 每一個子事務有對應的補償動作,例如對應上面的 T1、T2、T3 有 C1、C2、C3 的補償動作。
在 ACID 中如果出現異常，可以很容易進行回滾，但 SAGA 沒辦法自己回滾，必須依賴補償動作來進行回滾。
如果 T1、T2、T3 都提交成功了，整個事務 T 就提交成功，如果執行 T2 時出現異常，這時有兩種方式進行處理：
正向（不斷重試）：不斷對 T2 進行重試操作，直到成功（不排除人工干預），等 T2 重試成功后，繼續執行后面的 T3。
反向（補償）：T2 出現異常時，執行對應的補償 C2，C2 必須執行成功（不排除人工），然后執行 T1 對應的補償動作 C1 。
在上面提到的 seata 中也同樣可以支持 SAGA 模式。
除了 seata ，還有一個用 go 語言寫的 DTM 分布式事務框架也不錯：
https://dtm.pub/ https://github.com/dtm-labs/dtm。
重要的是，DTM 支持 C# 客戶端：
https://github.com/dtm-labs/dtmcli-csharp。
消息隊列
消息隊列相信大家都不陌生，我們零代碼產品中調用外部接口的組件，會被用在一些復雜的業務邏輯編排中，對外部接口的調用就是使用消息隊列，RabbitMQ 的延時隊列加上死信隊列可以來進行重試的操作，來保證數據的最終一致。
還有另一種方式就是使用事務消息表，比如有這樣一個場景，在系統列表中刪除一條流程數據，這時需要做：
1、列表服務中對數據進行刪除；。
2、文件服務對這條數據相關的附件進行刪除。
3、流程服務對該業務數據的所有流程信息進行刪除。
具體的步驟如下：
1、列表服務刪除數據成功后，在數據庫中創建一張事務消息表，該表中記錄事務 ID、數據刪除成功的狀態、業務數據 ID、附件待刪除的狀態、流程信息待刪除的狀態等。
2、列表服務刪除數據成功后，發送消息分別進行附件刪除處理和流程信息刪除處理。
3、消息被正確處理后，修改事務消息表的狀態。
4、創建一個單獨的消息服務程序，輪詢掃描事務消息表，如果發現狀態沒有變成已完成，就重新發送一個新的消息，這樣附件刪除和流程信息刪除就會進行多次執行，這也要求這些操作必須是冪等的。
RabbitMQ 本身不支持分布式事務，不過有一些消息中間件是支持的，例如：RocketMQ，原生就支持分布式事務操作，可以更方便進行事務處理。
本文是一些理論的梳理，要想更徹底地掌握，可以選擇一個框架，找幾個場景，寫寫代碼演練一下。
