一、概述

1.1背景

?一次業(yè)務(wù)操作需要跨多個(gè)數(shù)據(jù)源或需要跨多個(gè)系統(tǒng)進(jìn)行遠(yuǎn)程調(diào)用，就會產(chǎn)生分布式事務(wù)問題

but

?

關(guān)系型數(shù)據(jù)庫提供的能力是基于單機(jī)事務(wù)的，一旦遇到分布式事務(wù)場景，就需要通過更多其他技術(shù)手段來解決問題。

• 全局事務(wù)：整個(gè)分布式事務(wù)

• 分支事務(wù)：分布式事務(wù)中包含的每個(gè)子系統(tǒng)的事務(wù)

• 最終一致思想：各分支事務(wù)分別執(zhí)行并提交，如果有不一致的情況，再想辦法恢復(fù)數(shù)據(jù)

• 強(qiáng)一致思想：各分支事務(wù)執(zhí)行完業(yè)務(wù)不要提交，等待彼此結(jié)果。而后統(tǒng)一提交或回滾

1.2相關(guān)概念

什么是事務(wù)

什么是事務(wù)？舉個(gè)生活中的例子：你去小賣鋪買東西，“一手交錢，一手交貨”就是一個(gè)事務(wù)的例子，交錢和交貨必 須全部成功，事務(wù)才算成功，任一個(gè)活動失敗，事務(wù)將撤銷所有已成功的活動。

明白上述例子，再來看事務(wù)的定義：

事務(wù)可以看做是一次大的活動，它由不同的小活動組成，這些活動要么全部成功，要么全部失敗。

本地事務(wù)

在計(jì)算機(jī)系統(tǒng)中，更多的是通過關(guān)系型數(shù)據(jù)庫來控制事務(wù)，這是利用數(shù)據(jù)庫本身的事務(wù)特性來實(shí)現(xiàn)的，因此叫數(shù)據(jù) 庫事務(wù)，由于應(yīng)用主要靠關(guān)系數(shù)據(jù)庫來控制事務(wù)，而數(shù)據(jù)庫通常和應(yīng)用在同一個(gè)服務(wù)器，所以基于關(guān)系型數(shù)據(jù)庫的 事務(wù)又被稱為本地事務(wù)。

分布式事務(wù)

隨著互聯(lián)網(wǎng)的快速發(fā)展，軟件系統(tǒng)由原來的單體應(yīng)用轉(zhuǎn)變?yōu)榉植际綉?yīng)用

分布式系統(tǒng)會把一個(gè)應(yīng)用系統(tǒng)拆分為可獨(dú)立部署的多個(gè)服務(wù)，因此需要服務(wù)與服務(wù)之間遠(yuǎn)程協(xié)作才能完成事務(wù)操 作，這種分布式系統(tǒng)環(huán)境下由不同的服務(wù)之間通過網(wǎng)絡(luò)遠(yuǎn)程協(xié)作完成事務(wù)稱之為分布式事務(wù)，例如用戶注冊送積分 事務(wù)、創(chuàng)建訂單減庫存事務(wù)，銀行轉(zhuǎn)賬事務(wù)等都是分布式事務(wù)。

舉例

1.3分布式事務(wù)產(chǎn)生的場景

典型的場景就是微服務(wù)架構(gòu) 微服務(wù)之間通過遠(yuǎn)程調(diào)用完成事務(wù)操作。 比如：訂單微服務(wù)和庫存微服務(wù)，下單的 同時(shí)訂單微服務(wù)請求庫存微服務(wù)減庫存。 簡言之：跨JVM進(jìn)程產(chǎn)生分布式事務(wù)。

單體系統(tǒng)訪問多個(gè)數(shù)據(jù)庫實(shí)例 當(dāng)單體系統(tǒng)需要訪問多個(gè)數(shù)據(jù)庫（實(shí)例）時(shí)就會產(chǎn)生分布式事務(wù)。 比如：用戶信 息和訂單信息分別在兩個(gè)MySQL實(shí)例存儲，用戶管理系統(tǒng)刪除用戶信息，需要分別刪除用戶信息及用戶的訂單信 息，由于數(shù)據(jù)分布在不同的數(shù)據(jù)實(shí)例，需要通過不同的數(shù)據(jù)庫鏈接去操作數(shù)據(jù)，此時(shí)產(chǎn)生分布式事務(wù)。 簡言之：跨 數(shù)據(jù)庫實(shí)例產(chǎn)生分布式事務(wù)。

多服務(wù)訪問同一個(gè)數(shù)據(jù)庫實(shí)例 比如：訂單微服務(wù)和庫存微服務(wù)即使訪問同一個(gè)數(shù)據(jù)庫也會產(chǎn)生分布式事務(wù)，原 因就是跨JVM進(jìn)程，兩個(gè)微服務(wù)持有了不同的數(shù)據(jù)庫鏈接進(jìn)行數(shù)據(jù)庫操作，此時(shí)產(chǎn)生分布式事務(wù)。

?1.4Seata介紹

解決分布式事務(wù)的方案有很多，但實(shí)現(xiàn)起來都比較復(fù)雜，因此我們一般會使用開源的框架來解決分布式事務(wù)問題。在眾多的開源分布式事務(wù)框架中，功能最完善、使用最多的就是阿里巴巴在2019年開源的Seata了。

https://seata.io/zh-cn/docs/overview/what-is-seata.html

其實(shí)分布式事務(wù)產(chǎn)生的一個(gè)重要原因，就是參與事務(wù)的多個(gè)分支事務(wù)互相無感知，不知道彼此的執(zhí)行狀態(tài)。因此解決分布式事務(wù)的思想非常簡單：

就是找一個(gè)統(tǒng)一的事務(wù)協(xié)調(diào)者，與多個(gè)分支事務(wù)通信，檢測每個(gè)分支事務(wù)的執(zhí)行狀態(tài)，保證全局事務(wù)下的每一個(gè)分支事務(wù)同時(shí)成功或失敗即可。大多數(shù)的分布式事務(wù)框架都是基于這個(gè)理論來實(shí)現(xiàn)的。

Seata也不例外，在Seata的事務(wù)管理中有三個(gè)重要的角色：

• TC (Transaction Coordinator) - 事務(wù)協(xié)調(diào)者：維護(hù)全局和分支事務(wù)的狀態(tài)，協(xié)調(diào)全局事務(wù)提交或回滾。

• TM (Transaction Manager) - 事務(wù)管理器：定義全局事務(wù)的范圍、開始全局事務(wù)、提交或回滾全局事務(wù)。

• RM (Resource Manager) - 資源管理器：管理分支事務(wù)，與TC交談以注冊分支事務(wù)和報(bào)告分支事務(wù)的狀態(tài)，并驅(qū)動分支事務(wù)提交或回滾。

Seata的工作架構(gòu)如圖所示：

其中，TM和RM可以理解為Seata的客戶端部分，引入到參與事務(wù)的微服務(wù)依賴中即可。將來TM和RM就會協(xié)助微服務(wù)，實(shí)現(xiàn)本地分支事務(wù)與TC之間交互，實(shí)現(xiàn)事務(wù)的提交或回滾。

而TC服務(wù)則是事務(wù)協(xié)調(diào)中心，是一個(gè)獨(dú)立的微服務(wù)，需要單獨(dú)部署。

我們只需要使用一個(gè)@Global?Transactional注解在業(yè)務(wù)方法上：

歷史

1.3相關(guān)概念理解

TC (Transaction Coordinator)事務(wù)協(xié)調(diào)器

就是Seata,負(fù)責(zé)維護(hù)全局事務(wù)和分支事務(wù)的狀態(tài)，驅(qū)動全局事務(wù)提交或回滾。

TM (Transaction Manager)事務(wù)管理器

標(biāo)注全局@GlobalTransactional)啟動入口動作的微服務(wù)模塊（比如訂單模塊），它是事務(wù)的發(fā)起者，負(fù)責(zé)定義全局事務(wù)的范圍，并根據(jù)TC維護(hù)的全局事務(wù)和分支事務(wù)狀態(tài)，做出開始事務(wù)、提交事務(wù)、回滾事務(wù)的決議

RM (Resource Manager)資源管理器

就是mysql數(shù)據(jù)庫本身，可以是多個(gè)RM,負(fù)責(zé)管理分支事務(wù)上的資源，向TC
注冊分支事務(wù)，匯報(bào)分支事務(wù)狀態(tài)，驅(qū)動分支事務(wù)的提交或回滾

1.5安裝配置

見使用 docker-compose 部署 Seata Server

docker run --name seata \
-p 8091:8091 \
-p 8191:7091 \
-e SEATA_IP=youip \
-v ./seata-server/resources:/seata-server/resources \
--privileged=true \
-d \
seataio/seata-server:2.0.0

yml改

#  Unless required by applicable law or agreed to in writing, software#  distributed under the License is distributed on an "AS IS" BASIS,#  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.#  See the License for the specific language governing permissions and#  limitations under the License.server:port: 7091spring:application:name: seata-serverlogging:config: classpath:logback-spring.xmlfile:path: ${log.home:${user.home}/logs/seata}extend:logstash-appender:destination: 127.0.0.1:4560kafka-appender:bootstrap-servers: 127.0.0.1:9092topic: logback_to_logstashconsole:user:username: seatapassword: seataseata:config:type: nacosnacos:server-addr: 127.0.0.1:8848namespace:group: SEATA_GROUP #后續(xù)自己在nacos里面新建,不想新建SEATA_GROUP，就寫DEFAULT_GROUPusername: nacospassword: nacosregistry:type: nacosnacos:application: seata-serverserver-addr: 127.0.0.1:8848group: SEATA_GROUP #后續(xù)自己在nacos里面新建,不想新建SEATA_GROUP，就寫DEFAULT_GROUPnamespace:cluster: defaultusername: nacospassword: nacos    store:mode: dbdb:datasource: druiddb-type: mysqldriver-class-name: com.mysql.cj.jdbc.Driverurl: jdbc:mysql://localhost:3306/seata?characterEncoding=utf8&useSSL=false&serverTimezone=GMT%2B8&rewriteBatchedStatements=true&allowPublicKeyRetrieval=trueuser: rootpassword: 123456min-conn: 10max-conn: 100global-table: global_tablebranch-table: branch_tablelock-table: lock_tabledistributed-lock-table: distributed_lockquery-limit: 1000max-wait: 5000#  server:#    service-port: 8091 #If not configured, the default is '${server.port} + 1000'security:secretKey: SeataSecretKey0c382ef121d778043159209298fd40bf3850a017tokenValidityInMilliseconds: 1800000ignore:urls: /,/**/*.css,/**/*.js,/**/*.html,/**/*.map,/**/*.svg,/**/*.png,/**/*.jpeg,/**/*.ico,/api/v1/auth/login,/metadata/v1/**

1.6分類

Seata支持四種不同的分布式事務(wù)解決方案：

• XA

• TCC

• AT

• SAGA

Seata提供了四種不同的分布式事務(wù)解決方案：

• XA模式：強(qiáng)一致性分階段事務(wù)模式，犧牲了一定的可用性，無業(yè)務(wù)侵入
• TCC模式：最終一致的分階段事務(wù)模式，有業(yè)務(wù)侵入
• AT模式：最終一致的分階段事務(wù)模式，無業(yè)務(wù)侵入，也是Seata的默認(rèn)模式
• SAGA模式：長事務(wù)模式，有業(yè)務(wù)侵入

二、實(shí)戰(zhàn)演示

2.1引入依賴

<!--統(tǒng)一配置管理--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId></dependency><!--讀取bootstrap文件--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-bootstrap</artifactId></dependency><!--seata--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-seata</artifactId></dependency>

2.2yml修改

seata:registry:type: nacosnacos:server-addr: 127.0.0.1:8848namespace: ""group: SEATA_GROUPapplication: seata-servertx-service-group: default_tx_group # 事務(wù)組，由它獲得TC服務(wù)的集群名稱service:vgroup-mapping: # 點(diǎn)擊源碼分析default_tx_group: default # 事務(wù)組與TC服務(wù)集群的映射關(guān)系data-source-proxy-mode: AT

進(jìn)階

在nacos上添加一個(gè)共享的seata配置，命名為shared-seata.yaml：

然后，改造trade-service模塊，添加bootstrap.yaml：

spring:application:name: trade-service # 服務(wù)名稱profiles:active: devcloud:nacos:server-addr: 192.168.150.101 # nacos地址config:file-extension: yaml # 文件后綴名shared-configs: # 共享配置- dataId: shared-jdbc.yaml # 共享mybatis配置- dataId: shared-log.yaml # 共享日志配置- dataId: shared-swagger.yaml # 共享日志配置- dataId: shared-seata.yaml # 共享seata配置

2.3XA模式

2PC的傳統(tǒng)方案是在數(shù)據(jù)庫層面實(shí)現(xiàn)的，如Oracle、MySQL都支持2PC協(xié)議，為了統(tǒng)一標(biāo)準(zhǔn)減少行業(yè)內(nèi)不必要的對 接成本，需要制定標(biāo)準(zhǔn)化的處理模型及接口標(biāo)準(zhǔn)，國際開放標(biāo)準(zhǔn)組織Open Group定義了分布式事務(wù)處理模型 DTP（Distributed Transaction Processing Reference Model）。

XA 規(guī)范 是 X/Open 組織定義的分布式事務(wù)處理（DTP，Distributed Transaction Processing）標(biāo)準(zhǔn)，XA 規(guī)范 描述了全局的TM與局部的RM之間的接口，幾乎所有主流的數(shù)據(jù)庫都對 XA 規(guī)范 提供了支持。

兩階段提交

A是規(guī)范，目前主流數(shù)據(jù)庫都實(shí)現(xiàn)了這種規(guī)范，實(shí)現(xiàn)的原理都是基于兩階段提交。

正常情況：

異常情況：

一階段：

• 事務(wù)協(xié)調(diào)者通知每個(gè)事務(wù)參與者執(zhí)行本地事務(wù)

• 本地事務(wù)執(zhí)行完成后報(bào)告事務(wù)執(zhí)行狀態(tài)給事務(wù)協(xié)調(diào)者，此時(shí)事務(wù)不提交，繼續(xù)持有數(shù)據(jù)庫鎖

二階段：

• 事務(wù)協(xié)調(diào)者基于一階段的報(bào)告來判斷下一步操作

• 如果一階段都成功，則通知所有事務(wù)參與者，提交事務(wù)

• 如果一階段任意一個(gè)參與者失敗，則通知所有事務(wù)參與者回滾事務(wù)

Seata的XA模型

Seata對原始的XA模式做了簡單的封裝和改造，以適應(yīng)自己的事務(wù)模型，基本架構(gòu)如圖：

RM一階段的工作：

1. 注冊分支事務(wù)到TC

2. 執(zhí)行分支業(yè)務(wù)sql但不提交

3. 報(bào)告執(zhí)行狀態(tài)到TC

TC二階段的工作：

1. TC檢測各分支事務(wù)執(zhí)行狀態(tài)

   1. 如果都成功，通知所有RM提交事務(wù)

   2. 如果有失敗，通知所有RM回滾事務(wù)

RM二階段的工作：

• 接收TC指令，提交或回滾事務(wù)

實(shí)現(xiàn)XA模式

@GlobalTransactional`注解

@GlobalTransactional注解是用于聲明分布式全局事務(wù)的注解。

在分布式系統(tǒng)中，一個(gè)業(yè)務(wù)操作可能會涉及多個(gè)服務(wù)之間的調(diào)用，這些服務(wù)可能部署在不同的服務(wù)器上，甚至使用不同的數(shù)據(jù)庫。在這種情況下，保證整個(gè)業(yè)務(wù)流程的數(shù)據(jù)一致性就顯得尤為重要。@GlobalTransactional注解就是用于標(biāo)識這樣一個(gè)全局事務(wù)的邊界，確保所有涉及到的服務(wù)要么全部成功提交，要么全部回滾，以保持?jǐn)?shù)據(jù)的一致性。

優(yōu)缺點(diǎn)

XA模式的優(yōu)點(diǎn)是什么？

• 事務(wù)的強(qiáng)一致性，滿足ACID原則

• 常用數(shù)據(jù)庫都支持，實(shí)現(xiàn)簡單，并且沒有代碼侵入

XA模式的缺點(diǎn)是什么？

• 因?yàn)橐浑A段需要鎖定數(shù)據(jù)庫資源，等待二階段結(jié)束才釋放，性能較差

• 依賴關(guān)系型數(shù)據(jù)庫實(shí)現(xiàn)事務(wù)

2.4AT模式

AT模式同樣是分階段提交的事務(wù)模型，不過缺彌補(bǔ)了XA模型中資源鎖定周期過長的缺陷。

Seata的AT模型

階段一RM的工作：

• 注冊分支事務(wù)

• 記錄undo-log（數(shù)據(jù)快照）

• 執(zhí)行業(yè)務(wù)sql并提交

• 報(bào)告事務(wù)狀態(tài)

階段二提交時(shí)RM的工作：

• 刪除undo-log即可

階段二回滾時(shí)RM的工作：

• 根據(jù)undo-log恢復(fù)數(shù)據(jù)到更新前

AT與XA的區(qū)別

• XA模式一階段不提交事務(wù)，鎖定資源；AT模式一階段直接提交，不鎖定資源。

• XA模式依賴數(shù)據(jù)庫機(jī)制實(shí)現(xiàn)回滾；AT模式利用數(shù)據(jù)快照實(shí)現(xiàn)數(shù)據(jù)回滾。

• XA模式強(qiáng)一致；AT模式最終一致

AT模式原理

優(yōu)缺點(diǎn)

AT模式的優(yōu)點(diǎn)：

• 一階段完成直接提交事務(wù)，釋放數(shù)據(jù)庫資源，性能比較好
• 利用全局鎖實(shí)現(xiàn)讀寫隔離
• 沒有代碼侵入，框架自動完成回滾和提交

AT模式的缺點(diǎn)：

• 兩階段之間屬于軟狀態(tài)，屬于最終一致
• 框架的快照功能會影響性能，但比XA模式要好很多

實(shí)現(xiàn)AT模式

建表

總結(jié)

本節(jié)講解了傳統(tǒng)2PC（基于數(shù)據(jù)庫XA協(xié)議）和Seata實(shí)現(xiàn)2PC的兩種2PC方案，由于Seata的0侵入性并且解決了傳 統(tǒng)2PC長期鎖資源的問題，所以推薦采用Seata實(shí)現(xiàn)2PC。

Seata實(shí)現(xiàn)2PC要點(diǎn)：

1、全局事務(wù)開始使用 @GlobalTransactional標(biāo)識 。

2、每個(gè)本地事務(wù)方案仍然使用@Transactional標(biāo)識。

3、每個(gè)數(shù)據(jù)都需要?jiǎng)?chuàng)建undo_log表，此表是seata保證本地事務(wù)一致性的關(guān)鍵。

2.5TCC模式

seata的TCC模型

優(yōu)缺點(diǎn)

TCC的優(yōu)點(diǎn)是什么？

• ·一階段完成直接提交事務(wù)，釋放數(shù)據(jù)庫資源，性能好
• 相比AT模型，無需生成快照，無需使用全局鎖，性能最強(qiáng)
• ·不依賴數(shù)據(jù)庫事務(wù)，而是依賴補(bǔ)償操作，可以用于非事務(wù)型數(shù)據(jù)庫

TCC的缺點(diǎn)是什么？

• 有代碼侵入，需要人為編寫try、Confirm和Cancel接口，太麻煩
• 軟狀態(tài)，事務(wù)是最終一致
• 需要考慮Confirm和Cancel的失敗情況，做好冪等處理

實(shí)現(xiàn)TCC模式

空回滾

?在沒有調(diào)用 TCC 資源 Try 方法的情況下，調(diào)用了二階段的 Cancel 方法，Cancel 方法需要識別出這是一個(gè)空回 滾，然后直接返回成功。

出現(xiàn)原因是當(dāng)一個(gè)分支事務(wù)所在服務(wù)宕機(jī)或網(wǎng)絡(luò)異常，分支事務(wù)調(diào)用記錄為失敗，這個(gè)時(shí)候其實(shí)是沒有執(zhí)行Try階 段，當(dāng)故障恢復(fù)后，分布式事務(wù)進(jìn)行回滾則會調(diào)用二階段的Cancel方法，從而形成空回滾。

解決思路是關(guān)鍵就是要識別出這個(gè)空回滾。思路很簡單就是需要知道一階段是否執(zhí)行，如果執(zhí)行了，那就是正?；?滾；如果沒執(zhí)行，那就是空回滾。前面已經(jīng)說過TM在發(fā)起全局事務(wù)時(shí)生成全局事務(wù)記錄，全局事務(wù)ID貫穿整個(gè)分 布式事務(wù)調(diào)用鏈條。再額外增加一張分支事務(wù)記錄表，其中有全局事務(wù) ID 和分支事務(wù) ID，第一階段 Try 方法里會 插入一條記錄，表示一階段執(zhí)行了。Cancel 接口里讀取該記錄，如果該記錄存在，則正常回滾；如果該記錄不存 在，則是空回滾。

冪等： ?

TM在發(fā)起全局事務(wù)時(shí)生成全局事務(wù)記錄，全局事務(wù)ID貫穿整個(gè)分布式事務(wù)調(diào)用鏈條，用來記錄事務(wù)上下文， 追蹤和記錄狀態(tài)，由于Con?rm 和cancel失敗需進(jìn)行重試，因此需要實(shí)現(xiàn)為冪等，冪等性是指同一個(gè)操作無論請求 多少次，其結(jié)果都相同。

通過前面介紹已經(jīng)了解到，為了保證TCC二階段提交重試機(jī)制不會引發(fā)數(shù)據(jù)不一致，要求 TCC 的二階段 Try、 Con?rm 和 Cancel 接口保證冪等，這樣不會重復(fù)使用或者釋放資源。如果冪等控制沒有做好，很有可能導(dǎo)致數(shù)據(jù) 不一致等嚴(yán)重問題。

解決思路在上述“分支事務(wù)記錄”中增加執(zhí)行狀態(tài)，每次執(zhí)行前都查詢該狀態(tài)。

業(yè)務(wù)懸掛

懸掛就是對于一個(gè)分布式事務(wù)，其二階段 Cancel 接口比 Try 接口先執(zhí)行。

出現(xiàn)原因是在 RPC 調(diào)用分支事務(wù)try時(shí)，先注冊分支事務(wù)，再執(zhí)行RPC調(diào)用，如果此時(shí) RPC 調(diào)用的網(wǎng)絡(luò)發(fā)生擁堵， 通常 RPC 調(diào)用是有超時(shí)時(shí)間的，RPC 超時(shí)以后，TM就會通知RM回滾該分布式事務(wù)，可能回滾完成后，RPC 請求 才到達(dá)參與者真正執(zhí)行，而一個(gè) Try 方法預(yù)留的業(yè)務(wù)資源，只有該分布式事務(wù)才能使用，該分布式事務(wù)第一階段預(yù) 留的業(yè)務(wù)資源就再也沒有人能夠處理了，對于這種情況，我們就稱為懸掛，即業(yè)務(wù)資源預(yù)留后沒法繼續(xù)處理。

解決思路是如果二階段執(zhí)行完成，那一階段就不能再繼續(xù)執(zhí)行。在執(zhí)行一階段事務(wù)時(shí)判斷在該全局事務(wù)下，“分支 事務(wù)記錄”表中是否已經(jīng)有二階段事務(wù)記錄，如果有則不執(zhí)行Try。

接口聲明

總結(jié)·

如果拿TCC事務(wù)的處理流程與2PC兩階段提交做比較，2PC通常都是在跨庫的DB層面，而TCC則在應(yīng)用層面的處 理，需要通過業(yè)務(wù)邏輯來實(shí)現(xiàn)。這種分布式事務(wù)的實(shí)現(xiàn)方式的優(yōu)勢在于，可以讓應(yīng)用自己定義數(shù)據(jù)操作的粒度，使 得降低鎖沖突、提高吞吐量成為可能。

而不足之處則在于對應(yīng)用的侵入性非常強(qiáng)，業(yè)務(wù)邏輯的每個(gè)分支都需要實(shí)現(xiàn)try、con?rm、cancel三個(gè)操作。此 外，其實(shí)現(xiàn)難度也比較大，需要按照網(wǎng)絡(luò)狀態(tài)、系統(tǒng)故障等不同的失敗原因?qū)崿F(xiàn)不同的回滾策略。

2.6SAGA模式

Saga模式是SEATA提供的長事務(wù)解決方案。也分為兩個(gè)階段：

• ·一階段：直接提交本地事務(wù)
• 二階段：成功則什么都不做；失敗則通過編寫補(bǔ)償業(yè)務(wù)來回滾

沒有隔離性

優(yōu)缺點(diǎn)

總結(jié)

2.7高可用

將事務(wù)組映射配置到nacos

# 事務(wù)組映射關(guān)系
service.vgroupMapping.seata-demo=SHservice.enableDegrade=false
service.disableGlobalTransaction=false
# 與TC服務(wù)的通信配置
transport.type=TCP
transport.server=NIO
transport.heartbeat=true
transport.enableClientBatchSendRequest=false
transport.threadFactory.bossThreadPrefix=NettyBoss
transport.threadFactory.workerThreadPrefix=NettyServerNIOWorker
transport.threadFactory.serverExecutorThreadPrefix=NettyServerBizHandler
transport.threadFactory.shareBossWorker=false
transport.threadFactory.clientSelectorThreadPrefix=NettyClientSelector
transport.threadFactory.clientSelectorThreadSize=1
transport.threadFactory.clientWorkerThreadPrefix=NettyClientWorkerThread
transport.threadFactory.bossThreadSize=1
transport.threadFactory.workerThreadSize=default
transport.shutdown.wait=3
# RM配置
client.rm.asyncCommitBufferLimit=10000
client.rm.lock.retryInterval=10
client.rm.lock.retryTimes=30
client.rm.lock.retryPolicyBranchRollbackOnConflict=true
client.rm.reportRetryCount=5
client.rm.tableMetaCheckEnable=false
client.rm.tableMetaCheckerInterval=60000
client.rm.sqlParserType=druid
client.rm.reportSuccessEnable=false
client.rm.sagaBranchRegisterEnable=false
# TM配置
client.tm.commitRetryCount=5
client.tm.rollbackRetryCount=5
client.tm.defaultGlobalTransactionTimeout=60000
client.tm.degradeCheck=false
client.tm.degradeCheckAllowTimes=10
client.tm.degradeCheckPeriod=2000# undo日志配置
client.undo.dataValidation=true
client.undo.logSerialization=jackson
client.undo.onlyCareUpdateColumns=true
client.undo.logTable=undo_log
client.undo.compress.enable=true
client.undo.compress.type=zip
client.undo.compress.threshold=64k
client.log.exceptionRate=100

微服務(wù)讀取nacos配置?

重啟微服務(wù)，現(xiàn)在微服務(wù)到底是連接tc的SH集群，還是tc的HZ集群，都統(tǒng)一由nacos的client.properties來決定了。

三、知識擴(kuò)展

3.1可靠消息最終一致性

可靠消息最終一致性方案是指當(dāng)事務(wù)發(fā)起方執(zhí)行完成本地事務(wù)后并發(fā)出一條消息，事務(wù)參與方(消息消費(fèi)者)一定能 夠接收消息并處理事務(wù)成功，此方案強(qiáng)調(diào)的是只要消息發(fā)給事務(wù)參與方最終事務(wù)要達(dá)到一致。

此方案是利用消息中間件完成，如下圖： 事務(wù)發(fā)起方（消息生產(chǎn)方）將消息發(fā)給消息中間件，事務(wù)參與方從消息中間件接收消息，事務(wù)發(fā)起方和消息中間件 之間，事務(wù)參與方（消息消費(fèi)方）和消息中間件之間都是通過網(wǎng)絡(luò)通信，由于網(wǎng)絡(luò)通信的不確定性會導(dǎo)致分布式事 務(wù)問題。

因此可靠消息最終一致性方案要解決以下幾個(gè)問題：

問題產(chǎn)生

1.本地事務(wù)與消息發(fā)送的原子性問題

本地事務(wù)與消息發(fā)送的原子性問題即：事務(wù)發(fā)起方在本地事務(wù)執(zhí)行成功后消息必須發(fā)出去，否則就丟棄消息。即實(shí) 現(xiàn)本地事務(wù)和消息發(fā)送的原子性，要么都成功，要么都失敗。本地事務(wù)與消息發(fā)送的原子性問題是實(shí)現(xiàn)可靠消息最 終一致性方案的關(guān)鍵問題。

先來嘗試下這種操作，先發(fā)送消息，再操作數(shù)據(jù)庫：

begin?transaction；?//1.發(fā)送MQ?//2.數(shù)據(jù)庫操作?
commit?transation;?

這種情況下無法保證數(shù)據(jù)庫操作與發(fā)送消息的一致性，因?yàn)榭赡馨l(fā)送消息成功，數(shù)據(jù)庫操作失敗。 你立馬想到第二種方案，先進(jìn)行數(shù)據(jù)庫操作，再發(fā)送消息：

begin?transaction；?//1.數(shù)據(jù)庫操作?//2.發(fā)送MQ?
commit?transation;?

這種情況下貌似沒有問題，如果發(fā)送MQ消息失敗，就會拋出異常，導(dǎo)致數(shù)據(jù)庫事務(wù)回滾。但如果是超時(shí)異常，數(shù) 據(jù)庫回滾，但MQ其實(shí)已經(jīng)正常發(fā)送了，同樣會導(dǎo)致不一致。

2、事務(wù)參與方接收消息的可靠性

事務(wù)參與方必須能夠從消息隊(duì)列接收到消息，如果接收消息失敗可以重復(fù)接收消息。

3、消息重復(fù)消費(fèi)的問題

由于網(wǎng)絡(luò)2的存在，若某一個(gè)消費(fèi)節(jié)點(diǎn)超時(shí)但是消費(fèi)成功，此時(shí)消息中間件會重復(fù)投遞此消息，就導(dǎo)致了消息的重 復(fù)消費(fèi)。

要解決消息重復(fù)消費(fèi)的問題就要實(shí)現(xiàn)事務(wù)參與方的方法冪等性。

解決方案

本地消息表方案

本地消息表這個(gè)方案最初是eBay提出的，此方案的核心是通過本地事務(wù)保證數(shù)據(jù)業(yè)務(wù)操作和消息的一致性，然后 通過定時(shí)任務(wù)將消息發(fā)送至消息中間件，待確認(rèn)消息發(fā)送給消費(fèi)方成功再將消息刪除。

下面以注冊送積分為例來說明：

下例共有兩個(gè)微服務(wù)交互，用戶服務(wù)和積分服務(wù)，用戶服務(wù)負(fù)責(zé)添加用戶，積分服務(wù)負(fù)責(zé)增加積分。

交互流程如下：

1、用戶注冊

用戶服務(wù)在本地事務(wù)新增用戶和增加 ”積分消息日志“。（用戶表和消息表通過本地事務(wù)保證一致）

begin?transaction；?//1.新增用戶?//2.存儲積分消息日志?
commit?transation;?

這種情況下，本地?cái)?shù)據(jù)庫操作與存儲積分消息日志處于同一個(gè)事務(wù)中，本地?cái)?shù)據(jù)庫操作與記錄消息日志操作具備原 子性。

2、定時(shí)任務(wù)掃描日志

如何保證將消息發(fā)送給消息隊(duì)列呢？

經(jīng)過第一步消息已經(jīng)寫到消息日志表中，可以啟動獨(dú)立的線程，定時(shí)對消息日志表中的消息進(jìn)行掃描并發(fā)送至消息 中間件，在消息中間件反饋發(fā)送成功后刪除該消息日志，否則等待定時(shí)任務(wù)下一周期重試。

3、消費(fèi)消息

如何保證消費(fèi)者一定能消費(fèi)到消息呢？

這里可以使用MQ的ack（即消息確認(rèn)）機(jī)制，消費(fèi)者監(jiān)聽MQ，如果消費(fèi)者接收到消息并且業(yè)務(wù)處理完成后向MQ 發(fā)送ack（即消息確認(rèn)），此時(shí)說明消費(fèi)者正常消費(fèi)消息完成，MQ將不再向消費(fèi)者推送消息，否則消費(fèi)者會不斷重 試向消費(fèi)者來發(fā)送消息。

積分服務(wù)接收到”增加積分“消息，開始增加積分，積分增加成功后向消息中間件回應(yīng)ack，否則消息中間件將重復(fù) 投遞此消息。

由于消息會重復(fù)投遞，積分服務(wù)的”增加積分“功能需要實(shí)現(xiàn)冪等性。

RocketMQ事務(wù)消息方案

執(zhí)行流程如下：

為方便理解我們還以注冊送積分的例子來描述 整個(gè)流程。

Producer 即MQ發(fā)送方，本例中是用戶服務(wù)，負(fù)責(zé)新增用戶。MQ訂閱方即消息消費(fèi)方，本例中是積分服務(wù)，負(fù)責(zé) 新增積分。

1、Producer 發(fā)送事務(wù)消息

Producer （MQ發(fā)送方）發(fā)送事務(wù)消息至MQ Server，MQ Server將消息狀態(tài)標(biāo)記為Prepared（預(yù)備狀態(tài)），注 意此時(shí)這條消息消費(fèi)者（MQ訂閱方）是無法消費(fèi)到的。

本例中，Producer 發(fā)送 ”增加積分消息“ 到MQ Server。

2、MQ Server回應(yīng)消息發(fā)送成功

MQ Server接收到Producer 發(fā)送給的消息則回應(yīng)發(fā)送成功表示MQ已接收到消息。

3、Producer 執(zhí)行本地事務(wù)

Producer 端執(zhí)行業(yè)務(wù)代碼邏輯，通過本地?cái)?shù)據(jù)庫事務(wù)控制。

本例中，Producer 執(zhí)行添加用戶操作。

4、消息投遞

若Producer 本地事務(wù)執(zhí)行成功則自動向MQServer發(fā)送commit消息，MQ Server接收到commit消息后將”增加積 分消息“ 狀態(tài)標(biāo)記為可消費(fèi)，此時(shí)MQ訂閱方（積分服務(wù)）即正常消費(fèi)消息；

若Producer 本地事務(wù)執(zhí)行失敗則自動向MQServer發(fā)送rollback消息，MQ Server接收到rollback消息后 將刪 除”增加積分消息“ 。

MQ訂閱方（積分服務(wù)）消費(fèi)消息，消費(fèi)成功則向MQ回應(yīng)ack，否則將重復(fù)接收消息。這里ack默認(rèn)自動回應(yīng)，即 程序執(zhí)行正常則自動回應(yīng)ack。

5、事務(wù)回查

如果執(zhí)行Producer端本地事務(wù)過程中，執(zhí)行端掛掉，或者超時(shí)，MQ Server將會不停的詢問同組的其他 Producer 來獲取事務(wù)執(zhí)行狀態(tài)，這個(gè)過程叫事務(wù)回查。MQ Server會根據(jù)事務(wù)回查結(jié)果來決定是否投遞消息。

以上主干流程已由RocketMQ實(shí)現(xiàn)，對用戶側(cè)來說，用戶需要分別實(shí)現(xiàn)本地事務(wù)執(zhí)行以及本地事務(wù)回查方法，因此 只需關(guān)注本地事務(wù)的執(zhí)行狀態(tài)即可。

需求

小結(jié)

可靠消息最終一致性就是保證消息從生產(chǎn)方經(jīng)過消息中間件傳遞到消費(fèi)方的一致性，本案例使用了RocketMQ作為 消息中間件，RocketMQ主要解決了兩個(gè)功能：

1、本地事務(wù)與消息發(fā)送的原子性問題。

2、事務(wù)參與方接收消息的可靠性。

可靠消息最終一致性事務(wù)適合執(zhí)行周期長且實(shí)時(shí)性要求不高的場景。引入消息機(jī)制后，同步的事務(wù)操作變?yōu)榛谙?息執(zhí)行的異步操作, 避免了分布式事務(wù)中的同步阻塞操作的影響，并實(shí)現(xiàn)了兩個(gè)服務(wù)的解耦。

3.2最大努力通知

什么是最大努力通知

最大努力通知也是一種解決分布式事務(wù)的方案，下邊是一個(gè)是充值的例子：

交互流程:

1、賬戶系統(tǒng)調(diào)用充值系統(tǒng)接口

2、充值系統(tǒng)完成支付處理向賬戶系統(tǒng)發(fā)起充值結(jié)果通知

若通知失敗，則充值系統(tǒng)按策略進(jìn)行重復(fù)通知

3、賬戶系統(tǒng)接收到充值結(jié)果通知修改充值狀態(tài)。

4、賬戶系統(tǒng)未接收到通知會主動調(diào)用充值系統(tǒng)的接口查詢充值結(jié)果。

通過上邊的例子我們總結(jié)最大努力通知方案的目標(biāo)：

目標(biāo)：發(fā)起通知方通過一定的機(jī)制最大努力將業(yè)務(wù)處理結(jié)果通知到接收方。

具體包括：

1、有一定的消息重復(fù)通知機(jī)制。 因?yàn)榻邮胀ㄖ娇赡軟]有接收到通知，此時(shí)要有一定的機(jī)制對消息重復(fù)通知。

2、消息校對機(jī)制。

如果盡最大努力也沒有通知到接收方，或者接收方消費(fèi)消息后要再次消費(fèi)，此時(shí)可由接收方主動向通知方查詢消息 信息來滿足需求。

最大努力通知與可靠消息一致性有什么不同？

解決方案

通過對最大努力通知的理解，采用MQ的ack機(jī)制就可以實(shí)現(xiàn)最大努力通知。

方案1：

本方案是利用MQ的ack機(jī)制由MQ向接收通知方發(fā)送通知，流程如下：

1、發(fā)起通知方將通知發(fā)給MQ。 使用普通消息機(jī)制將通知發(fā)給MQ。

注意：如果消息沒有發(fā)出去可由接收通知方主動請求發(fā)起通知方查詢業(yè)務(wù)執(zhí)行結(jié)果。（后邊會講）

2、接收通知方監(jiān)聽 MQ。

3、接收通知方接收消息，業(yè)務(wù)處理完成回應(yīng)ack。

4、接收通知方若沒有回應(yīng)ack則MQ會重復(fù)通知。 MQ會按照間隔1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知間隔 （如果MQ采用 rocketMq，在broker中可進(jìn)行配置），直到達(dá)到通知要求的時(shí)間窗口上限。

5、接收通知方可通過消息校對接口來校對消息的一致性。

方案2： 本方案也是利用MQ的ack機(jī)制，與方案1不同的是應(yīng)用程序向接收通知方發(fā)送通知，如下圖：

交互流程如下：

1、發(fā)起通知方將通知發(fā)給MQ。 使用可靠消息一致方案中的事務(wù)消息保證本地事務(wù)與消息的原子性，最終將通知先發(fā)給MQ。

2、通知程序監(jiān)聽 MQ，接收MQ的消息。 方案1中接收通知方直接監(jiān)聽MQ，方案2中由通知程序監(jiān)聽MQ。通知程序若沒有回應(yīng)ack則MQ會重復(fù)通知。

3、通知程序通過互聯(lián)網(wǎng)接口協(xié)議（如http、webservice）調(diào)用接收通知方案接口，完成通知。 通知程序調(diào)用接收通知方案接口成功就表示通知成功，即消費(fèi)MQ消息成功，MQ將不再向通知程序投遞通知消 息。

4、接收通知方可通過消息校對接口來校對消息的一致性。

小結(jié)

小結(jié) 最大努力通知方案是分布式事務(wù)中對一致性要求最低的一種,適用于一些最終一致性時(shí)間敏感度低的業(yè)務(wù)；

最大努力通知方案需要實(shí)現(xiàn)如下功能： 1、消息重復(fù)通知機(jī)制。 2、消息校對機(jī)制。

3.3總結(jié)

在學(xué)習(xí)各種分布式事務(wù)的解決方案后，我們了解到各種方案的優(yōu)缺點(diǎn)：

2PC 最大的詬病是一個(gè)阻塞協(xié)議。RM在執(zhí)行分支事務(wù)后需要等待TM的決定，此時(shí)服務(wù)會阻塞并鎖定資源。由于其 阻塞機(jī)制和最差時(shí)間復(fù)雜度高， 因此，這種設(shè)計(jì)不能適應(yīng)隨著事務(wù)涉及的服務(wù)數(shù)量增加而擴(kuò)展的需要，很難用于并 發(fā)較高以及子事務(wù)生命周期較長 (long-running transactions) 的分布式服務(wù)中。

如果拿TCC事務(wù)的處理流程與2PC兩階段提交做比較，2PC通常都是在跨庫的DB層面，而TCC則在應(yīng)用層面的處 理，需要通過業(yè)務(wù)邏輯來實(shí)現(xiàn)。這種分布式事務(wù)的實(shí)現(xiàn)方式的優(yōu)勢在于，可以讓應(yīng)用自己定義數(shù)據(jù)操作的粒度，使 得降低鎖沖突、提高吞吐量成為可能。而不足之處則在于對應(yīng)用的侵入性非常強(qiáng)，業(yè)務(wù)邏輯的每個(gè)分支都需要實(shí)現(xiàn) try、con?rm、cancel三個(gè)操作。此外，其實(shí)現(xiàn)難度也比較大，需要按照網(wǎng)絡(luò)狀態(tài)、系統(tǒng)故障等不同的失敗原因?qū)?現(xiàn)不同的回滾策略。典型的使用場景：滿，登錄送優(yōu)惠券等。

可靠消息最終一致性事務(wù)適合執(zhí)行周期長且實(shí)時(shí)性要求不高的場景。引入消息機(jī)制后，同步的事務(wù)操作變?yōu)榛谙?息執(zhí)行的異步操作, 避免了分布式事務(wù)中的同步阻塞操作的影響，并實(shí)現(xiàn)了兩個(gè)服務(wù)的解耦。典型的使用場景：注 冊送積分，登錄送優(yōu)惠券等。

最大努力通知是分布式事務(wù)中要求最低的一種,適用于一些最終一致性時(shí)間敏感度低的業(yè)務(wù)；允許發(fā)起通知方處理業(yè) 務(wù)失敗，在接收通知方收到通知后積極進(jìn)行失敗處理，無論發(fā)起通知方如何處理結(jié)果都會不影響到接收通知方的后 續(xù)處理；發(fā)起通知方需提供查詢執(zhí)行情況接口，用于接收通知方校對結(jié)果。典型的使用場景：銀行通知、支付結(jié)果 通知等。

四、分布式事務(wù)概述

簡述

分布式事務(wù)指事務(wù)的操作位于不同的節(jié)點(diǎn)上，需要保證事務(wù)的 AICD 特性。
例如在下單場景下，庫存和訂單如果不在同一個(gè)節(jié)點(diǎn)上，就涉及分布式事務(wù)。

分布式事務(wù)的方式

在分布式系統(tǒng)中，要實(shí)現(xiàn)分布式事務(wù)，無外乎那幾種解決方案。

4.1兩階段提交（2PC）

需要數(shù)據(jù)庫產(chǎn)商的支持，java組件有atomikos等。

兩階段提交（Two-phase Commit，2PC），通過引入?yún)f(xié)調(diào)者（Coordinator）來協(xié)調(diào)參與者的行為，并最終決定這些參與者是否要真正執(zhí)行事務(wù)。

準(zhǔn)備階段

協(xié)調(diào)者詢問參與者事務(wù)是否執(zhí)行成功，參與者發(fā)回事務(wù)執(zhí)行結(jié)果。

提交階段

如果事務(wù)在每個(gè)參與者上都執(zhí)行成功，事務(wù)協(xié)調(diào)者發(fā)送通知讓參與者提交事務(wù)；否則，協(xié)調(diào)者發(fā)送通知讓參與者回滾事務(wù)。
需要注意的是，在準(zhǔn)備階段，參與者執(zhí)行了事務(wù)，但是還未提交。只有在提交階段接收到協(xié)調(diào)者發(fā)來的通知后，才進(jìn)行提交或者回滾。

存在的問題

• 同步阻塞 所有事務(wù)參與者在等待其它參與者響應(yīng)的時(shí)候都處于同步阻塞狀態(tài)，無法進(jìn)行其它操作。
• 單點(diǎn)問題 協(xié)調(diào)者在 2PC 中起到非常大的作用，發(fā)生故障將會造成很大影響。特別是在階段二發(fā)生故障，所有參與者會一直等待狀態(tài)，無法完成其它操作。
• 數(shù)據(jù)不一致 在階段二，如果協(xié)調(diào)者只發(fā)送了部分 Commit 消息，此時(shí)網(wǎng)絡(luò)發(fā)生異常，那么只有部分參與者接收到 Commit 消息，也就是說只有部分參與者提交了事務(wù)，使得系統(tǒng)數(shù)據(jù)不一致。
• 太過保守 任意一個(gè)節(jié)點(diǎn)失敗就會導(dǎo)致整個(gè)事務(wù)失敗，沒有完善的容錯(cuò)機(jī)制。

4.2補(bǔ)償事務(wù)（TCC）

嚴(yán)選，阿里，螞蟻金服。

TCC 其實(shí)就是采用的補(bǔ)償機(jī)制，其核心思想是：針對每個(gè)操作，都要注冊一個(gè)與其對應(yīng)的確認(rèn)和補(bǔ)償（撤銷）操作。它分為三個(gè)階段：

• Try 階段主要是對業(yè)務(wù)系統(tǒng)做檢測及資源預(yù)留
• Confirm 階段主要是對業(yè)務(wù)系統(tǒng)做確認(rèn)提交，Try階段執(zhí)行成功并開始執(zhí)行 Confirm階段時(shí)，默認(rèn) - - - Confirm階段是不會出錯(cuò)的。即：只要Try成功，Confirm一定成功。
• Cancel 階段主要是在業(yè)務(wù)執(zhí)行錯(cuò)誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務(wù)取消，預(yù)留資源釋放。

舉個(gè)例子，假入 Bob 要向 Smith 轉(zhuǎn)賬，思路大概是： 我們有一個(gè)本地方法，里面依次調(diào)用
1：首先在 Try 階段，要先調(diào)用遠(yuǎn)程接口把 Smith 和 Bob 的錢給凍結(jié)起來。
2：在 Confirm 階段，執(zhí)行遠(yuǎn)程調(diào)用的轉(zhuǎn)賬的操作，轉(zhuǎn)賬成功進(jìn)行解凍。
3：如果第2步執(zhí)行成功，那么轉(zhuǎn)賬成功，如果第二步執(zhí)行失敗，則調(diào)用遠(yuǎn)程凍結(jié)接口對應(yīng)的解凍方法 (Cancel)。

優(yōu)點(diǎn)： 跟2PC比起來，實(shí)現(xiàn)以及流程相對簡單了一些，但數(shù)據(jù)的一致性比2PC也要差一些
缺點(diǎn)： 缺點(diǎn)還是比較明顯的，在2,3步中都有可能失敗。TCC屬于應(yīng)用層的一種補(bǔ)償方式，所以需要程序員在實(shí)現(xiàn)的時(shí)候多寫很多補(bǔ)償?shù)拇a，在一些場景中，一些業(yè)務(wù)流程可能用TCC不太好定義及處理。

4.3本地消息表（異步確保）

比如：支付寶、微信支付主動查詢支付狀態(tài)，對賬單的形式

本地消息表與業(yè)務(wù)數(shù)據(jù)表處于同一個(gè)數(shù)據(jù)庫中，這樣就能利用本地事務(wù)來保證在對這兩個(gè)表的操作滿足事務(wù)特性，并且使用了消息隊(duì)列來保證最終一致性。

• 在分布式事務(wù)操作的一方完成寫業(yè)務(wù)數(shù)據(jù)的操作之后向本地消息表發(fā)送一個(gè)消息，本地事務(wù)能保證這個(gè)消息一定會被寫入本地消息表中。
• 之后將本地消息表中的消息轉(zhuǎn)發(fā)到 Kafka 等消息隊(duì)列中，如果轉(zhuǎn)發(fā)成功則將消息從本地消息表中刪除，否則繼續(xù)重新轉(zhuǎn)發(fā)。
• 在分布式事務(wù)操作的另一方從消息隊(duì)列中讀取一個(gè)消息，并執(zhí)行消息中的操作。

優(yōu)點(diǎn)： 一種非常經(jīng)典的實(shí)現(xiàn)，避免了分布式事務(wù)，實(shí)現(xiàn)了最終一致性。
缺點(diǎn)： 消息表會耦合到業(yè)務(wù)系統(tǒng)中，如果沒有封裝好的解決方案，會有很多雜活需要處理。

4.4MQ 事務(wù)消息

異步場景，通用性較強(qiáng)，拓展性較高。

有一些第三方的MQ是支持事務(wù)消息的，比如RocketMQ，他們支持事務(wù)消息的方式也是類似于采用的二階段提交，但是市面上一些主流的MQ都是不支持事務(wù)消息的，比如 Kafka 不支持。
以阿里的 RabbitMQ 中間件為例，其思路大致為：

• 第一階段Prepared消息，會拿到消息的地址。 第二階段執(zhí)行本地事務(wù)，第三階段通過第一階段拿到的地址去訪問消息，并修改狀態(tài)。

• 也就是說在業(yè)務(wù)方法內(nèi)要想消息隊(duì)列提交兩次請求，一次發(fā)送消息和一次確認(rèn)消息。如果確認(rèn)消息發(fā)送失敗了RabbitMQ會定期掃描消息集群中的事務(wù)消息，這時(shí)候發(fā)現(xiàn)了Prepared消息，它會向消息發(fā)送者確認(rèn)，所以生產(chǎn)方需要實(shí)現(xiàn)一個(gè)check接口，RabbitMQ會根據(jù)發(fā)送端設(shè)置的策略來決定是回滾還是繼續(xù)發(fā)送確認(rèn)消息。這樣就保證了消息發(fā)送與本地事務(wù)同時(shí)成功或同時(shí)失敗。

優(yōu)點(diǎn)： 實(shí)現(xiàn)了最終一致性，不需要依賴本地?cái)?shù)據(jù)庫事務(wù)。
缺點(diǎn)： 實(shí)現(xiàn)難度大，主流MQ不支持，RocketMQ事務(wù)消息部分代碼也未開源。