幾乎所有的信息管理系統(tǒng)都會(huì)涉及到事務(wù)，事務(wù)的目的是為了保證數(shù)據(jù)的一致性，這里說的一致性是數(shù)據(jù)庫狀態(tài)的一致性。

說到數(shù)據(jù)庫狀態(tài)的一致性，相信大家都會(huì)想到 ACID ：

• 原子性（Atomic）：在一個(gè)事件的多個(gè)數(shù)據(jù)庫操作中，要么同時(shí)成功，要么同時(shí)失敗，例如：轉(zhuǎn)賬業(yè)務(wù)。
• 隔離性（Isolation）：不同的業(yè)務(wù)之間處理數(shù)據(jù)相互獨(dú)立，互不影響。
• 持久性（Durability）：正常提交的數(shù)據(jù)能夠被持久化，不丟失數(shù)據(jù)，比如 mysql 天然就能持久化，redis 、 rabbitmq 也能通過設(shè)置進(jìn)行持久化。
• 一致性（Consistency）：最終的數(shù)據(jù)正確，所以說是通過 AID 這些手段來保證了 C 。

在單體架構(gòu)中，通常是一套程序?qū)?yīng)一個(gè)數(shù)據(jù)庫，事務(wù)基于數(shù)據(jù)庫本身的能力,如果你在 .NET Core 中使用 dapper 或 sqlsugar ，可以很容易進(jìn)行事務(wù)的處理，可以參考下面文檔：

https://dapper-tutorial.net/transaction 。

https://www.donet5.com/Home/Doc?typeId=1183。

但是，在微服務(wù)架構(gòu)，分布式的場景中，事務(wù)的處理就會(huì)變得復(fù)雜，會(huì)存在多個(gè)節(jié)點(diǎn)，多個(gè)節(jié)點(diǎn)的同步、可用性等都是需要考慮的問題，在分布式中有一個(gè)著名的 CAP 理論：

• C：數(shù)據(jù)一致性（Consisitency）：分布式中存在多個(gè)節(jié)點(diǎn)，對(duì)某個(gè)指定的客戶端來說，從任一節(jié)點(diǎn)讀取的數(shù)據(jù)保證獲取到的是最新寫入的數(shù)據(jù)。
• A：可用性（Acailability），非故障節(jié)點(diǎn)在合理的時(shí)間內(nèi)返回合理的響應(yīng)（不是錯(cuò)誤和超時(shí)的響應(yīng)）。
• P：分區(qū)容錯(cuò)性（Partition Tolerance），節(jié)點(diǎn)之間的數(shù)據(jù)傳遞是基于網(wǎng)絡(luò)的，由于網(wǎng)絡(luò)本身不是 100% 可靠，極端情況下會(huì)出現(xiàn)網(wǎng)絡(luò)不可用的情況，進(jìn)而將網(wǎng)絡(luò)兩端的節(jié)點(diǎn)分隔開來，這就是所謂的「網(wǎng)絡(luò)分區(qū)」現(xiàn)象。在出現(xiàn)網(wǎng)絡(luò)分區(qū)時(shí)，兩部分的數(shù)據(jù)是不一致的，如果要保證數(shù)據(jù)的一致性，就必須要讓沒有及時(shí)同步數(shù)據(jù)的節(jié)點(diǎn)變?yōu)椴豢捎茫@就犧牲了可用性，否則就會(huì)犧牲一致性，所以在 P 一定存在的情況下，需要在 C 和 A 中間做取舍。

我們?cè)?CAP、ACID 中討論的一致性稱為「強(qiáng)一致性」（Strong Consistency），而把犧牲了 C 的 AP 系統(tǒng)，但又要保證最終的結(jié)果是一致的，稱為「弱一致性」，也叫最終一致性。最終一致性的概念由 eBay 的系統(tǒng)架構(gòu)師丹 · 普利切特（Dan Pritchett）在 2008 年發(fā)表于 ACM 的論文「Base: An Acid Alternative」中提出的。

本文主要說下保證一致性的幾種方式：TCC、SAGA 和消息隊(duì)列。

TCC

TCC 是 Try-Confirm-Cancel 的縮寫，表示將整個(gè)過程分為了三個(gè)階段：

• Try：一個(gè)請(qǐng)求涉及到多個(gè)服務(wù)，多個(gè)服務(wù)會(huì)同時(shí)進(jìn)行 Try，這個(gè)階段為嘗試執(zhí)行階段，在這個(gè)階段中會(huì)進(jìn)行數(shù)據(jù)的校驗(yàn)、檢查，保障一致性，并準(zhǔn)備資源，都成功會(huì)進(jìn)入到 Confirm 階段。
• Confirm：確認(rèn)執(zhí)行階段，不進(jìn)行任何業(yè)務(wù)檢查，多個(gè)服務(wù)的 Try 都執(zhí)行成功了，多個(gè)服務(wù)都進(jìn)入到 Confirm 階段，在這個(gè)階段直接使用 Try 階段準(zhǔn)備的資源來完成業(yè)務(wù)處理。注意，Confirm 階段可能會(huì)重復(fù)執(zhí)行，因此需要滿足冪等性。
• Cancel：如果在 Try 階段有一個(gè)服務(wù)沒有成功，那么所有的服務(wù)都進(jìn)入到 Cancel 階段，在該階段，釋放 Try 階段預(yù)留的業(yè)務(wù)資源。注意，Cancel 階段也可能會(huì)重復(fù)執(zhí)行，因此也需要滿足冪等性。

在 .NET Core 中可以參考：

https://github.com/simpleway2016/JMS。

在 Java 中可以使用 seata：

https://github.com/seata/seata https://seata.io/zh-cn/。

因?yàn)樵?TCC 中的第一步 Try 需要預(yù)留資源，進(jìn)行檢查和校驗(yàn)，但在某些場景下，資源不是我們所能控制的，比如支付中，余額是銀行管理的，我們通常沒有權(quán)限。所以這時(shí)就不太適合 TCC ，可以考慮用 SAGA 來代替 TCC。

SAGA

SAGA 起源于 1987 年普林斯頓大學(xué)的赫克托 · 加西亞 · 莫利納（Hector Garcia Molina）和肯尼斯 · 麥克米倫（Kenneth Salem）在 ACM 發(fā)表的一篇論文《SAGAS》。

SAGA 和 TCC 最大的區(qū)別是基于數(shù)據(jù)補(bǔ)償機(jī)制來代替回滾。一個(gè) SAGA 表示處理多個(gè)服務(wù)中數(shù)據(jù)的一系列操作，由一連串的本地事務(wù)組成，每個(gè)獨(dú)立的本地事務(wù)中還是能夠使用 ACID 。

SATA 由兩部分組成：

• 將一個(gè)大的事務(wù)拆分成的若干個(gè)小的事務(wù)，比如一個(gè)大的事務(wù) T ，拆分成 T1、T2、T3。
• 每一個(gè)子事務(wù)有對(duì)應(yīng)的補(bǔ)償動(dòng)作,例如對(duì)應(yīng)上面的 T1、T2、T3 有 C1、C2、C3 的補(bǔ)償動(dòng)作。

在 ACID 中如果出現(xiàn)異常，可以很容易進(jìn)行回滾，但 SAGA 沒辦法自己回滾，必須依賴補(bǔ)償動(dòng)作來進(jìn)行回滾。

如果 T1、T2、T3 都提交成功了，整個(gè)事務(wù) T 就提交成功，如果執(zhí)行 T2 時(shí)出現(xiàn)異常，這時(shí)有兩種方式進(jìn)行處理：

正向（不斷重試）：不斷對(duì) T2 進(jìn)行重試操作，直到成功（不排除人工干預(yù)），等 T2 重試成功后，繼續(xù)執(zhí)行后面的 T3。

反向（補(bǔ)償）：T2 出現(xiàn)異常時(shí)，執(zhí)行對(duì)應(yīng)的補(bǔ)償 C2，C2 必須執(zhí)行成功（不排除人工），然后執(zhí)行 T1 對(duì)應(yīng)的補(bǔ)償動(dòng)作 C1 。

在上面提到的 seata 中也同樣可以支持 SAGA 模式。

除了 seata ，還有一個(gè)用 go 語言寫的 DTM 分布式事務(wù)框架也不錯(cuò)：

https://dtm.pub/ https://github.com/dtm-labs/dtm。

重要的是，DTM 支持 C# 客戶端：

https://github.com/dtm-labs/dtmcli-csharp。

消息隊(duì)列

消息隊(duì)列相信大家都不陌生，我們零代碼產(chǎn)品中調(diào)用外部接口的組件，會(huì)被用在一些復(fù)雜的業(yè)務(wù)邏輯編排中，對(duì)外部接口的調(diào)用就是使用消息隊(duì)列，RabbitMQ 的延時(shí)隊(duì)列加上死信隊(duì)列可以來進(jìn)行重試的操作，來保證數(shù)據(jù)的最終一致。

還有另一種方式就是使用事務(wù)消息表，比如有這樣一個(gè)場景，在系統(tǒng)列表中刪除一條流程數(shù)據(jù)，這時(shí)需要做：

1、列表服務(wù)中對(duì)數(shù)據(jù)進(jìn)行刪除；。

2、文件服務(wù)對(duì)這條數(shù)據(jù)相關(guān)的附件進(jìn)行刪除。

3、流程服務(wù)對(duì)該業(yè)務(wù)數(shù)據(jù)的所有流程信息進(jìn)行刪除。

具體的步驟如下：

1、列表服務(wù)刪除數(shù)據(jù)成功后，在數(shù)據(jù)庫中創(chuàng)建一張事務(wù)消息表，該表中記錄事務(wù) ID、數(shù)據(jù)刪除成功的狀態(tài)、業(yè)務(wù)數(shù)據(jù) ID、附件待刪除的狀態(tài)、流程信息待刪除的狀態(tài)等。

2、列表服務(wù)刪除數(shù)據(jù)成功后，發(fā)送消息分別進(jìn)行附件刪除處理和流程信息刪除處理。

3、消息被正確處理后，修改事務(wù)消息表的狀態(tài)。

4、創(chuàng)建一個(gè)單獨(dú)的消息服務(wù)程序，輪詢掃描事務(wù)消息表，如果發(fā)現(xiàn)狀態(tài)沒有變成已完成，就重新發(fā)送一個(gè)新的消息，這樣附件刪除和流程信息刪除就會(huì)進(jìn)行多次執(zhí)行，這也要求這些操作必須是冪等的。

RabbitMQ 本身不支持分布式事務(wù)，不過有一些消息中間件是支持的，例如：RocketMQ，原生就支持分布式事務(wù)操作，可以更方便進(jìn)行事務(wù)處理。

本文是一些理論的梳理，要想更徹底地掌握，可以選擇一個(gè)框架，找?guī)讉€(gè)場景，寫寫代碼演練一下。