?? 《SpringCloud入門實戰(zhàn)系列》解鎖SpringCloud主流組件入門應用及關鍵特性偎捎。帶你了解SpringCloud主流組件,是如何一戰(zhàn)解決微服務諸多難題的疚顷。
?? 作者：一只IT攻城獅蔓纠。關注我厦幅，不迷路。
?? 再小的收獲x365天都會成就不一樣的自己，一起學習，一起進步缰犁。

我們先來回顧下事務和分布式事務是什么？然后我們面臨哪些分布式事務問題，如何解決帅容？帶著問題我們一起向下學習颇象。

一、分布式事務

1并徘、我們先回顧下事務

事務是指數(shù)據(jù)庫中的一組操作遣钳，這些操作要么全部成功執(zhí)行，要么全部回滾饮亏，以保持數(shù)據(jù)的一致性和完整性耍贾。事務具有以下四個特性，通常稱為ACID特性：

• 原子性（Atomicity）：事務中的所有操作要么全部執(zhí)行成功路幸，要么全部失敗回滾荐开，沒有中間狀態(tài)。
• 一致性（Consistency）：事務的執(zhí)行使數(shù)據(jù)庫從一個一致性狀態(tài)轉移到另一個一致性狀態(tài)简肴。事務在開始和結束時晃听，數(shù)據(jù)庫必須滿足預定義的一致性規(guī)則。
• 隔離性（Isolation）：事務的執(zhí)行應該與其他并發(fā)執(zhí)行的事務相互隔離砰识，每個事務都感覺不到其他事務的存在能扒。
• 持久性（Durability）：一旦事務提交，其對數(shù)據(jù)庫的修改應該是永久性的辫狼，即使在系統(tǒng)故障的情況下也不應丟失初斑。

本地事務：Spring本地事務使用@Transactional 大多數(shù)場景下，我們的應用都只需要操作單一的數(shù)據(jù)庫膨处，這種情況下的事務被稱之為本地事務（Local Transaction）见秤。本地事務的ACID特性是數(shù)據(jù)庫直接提供支持。

分布式事務（Distributed Transaction）是指跨越多個分布式系統(tǒng)的事務真椿，其中涉及到多個獨立的參與者和資源鹃答。分布式事務需要確保多個參與者之間的操作的一致性和原子性。

2突硝、分布式事務問題

如圖测摔，用戶購買商品的業(yè)務邏輯。整個業(yè)務邏輯由3個微服務提供支持：

• 倉儲服務（Stock）：對給定的商品扣除倉儲數(shù)量解恰。
• 訂單服務（Order）：根據(jù)采購需求創(chuàng)建訂單锋八。
• 賬戶服務（Account）：從用戶賬戶中扣除余額。

單體應用被拆分成微服務應用护盈，原來的三個模塊被拆分為三個獨立的應用查库，分別使用三個獨立的數(shù)據(jù)源。
業(yè)務操作需要調用三個服務來完成黄琼，此時每個服務內(nèi)部的數(shù)據(jù)一致性由本地事務來保證，但是全局的數(shù)據(jù)一致性問題沒法保證。
故一次業(yè)務操作需要跨多個數(shù)據(jù)源或者需要跨多個系統(tǒng)進行遠程調用脏款，就會產(chǎn)生分布式事務問題围苫。

由于網(wǎng)絡延遲、節(jié)點故障撤师、通信失敗等原因剂府，導致分布式事務無法像單個系統(tǒng)的事務那樣簡單地實現(xiàn)ACID特性。

常見的分布式事務問題包括：

• 部分失斕甓堋：在一個分布式事務中腺占，有些參與者執(zhí)行成功，而其他參與者執(zhí)行失敗痒谴，導致事務的部分操作成功衰伯，部分操作失敗。
• 數(shù)據(jù)不一致：在一個分布式事務中积蔚，數(shù)據(jù)的一致性無法保證意鲸，可能因為參與者之間的數(shù)據(jù)沖突或者數(shù)據(jù)同步延遲。

3尽爆、一般事務的解決方案為什么不能作用于分布式事務怎顾？

解決一般事務問題的方法，例如使用數(shù)據(jù)庫的ACID特性漱贱、鎖機制槐雾、回滾和恢復機制等，無法直接應用于分布式事務問題幅狮，原因如下：

• 并發(fā)控制問題：在分布式環(huán)境中募强，由于多個事務同時執(zhí)行，并發(fā)控制變得更加復雜彪笼。傳統(tǒng)的鎖機制在分布式環(huán)境中無法有效地協(xié)調多個參與者之間的并發(fā)訪問钻注。
• 通信故障：分布式事務中的參與者之間通過網(wǎng)絡進行通信，網(wǎng)絡延遲配猫、斷開連接或消息丟失可能導致事務協(xié)調失敗或超時幅恋。
• 參與者故障：在分布式系統(tǒng)中，參與者可能由于硬件故障泵肄、軟件錯誤或其他原因而崩潰或無響應捆交。這可能導致事務無法完成或導致數(shù)據(jù)不一致。
• 同步問題：在分布式環(huán)境中腐巢，數(shù)據(jù)的復制和同步可能存在延遲品追，導致不同參與者之間的數(shù)據(jù)不一致。
• 跨越多個系統(tǒng)：分布式事務涉及跨越多個獨立的系統(tǒng)冯丙，每個系統(tǒng)可能具有不同的事務管理機制和數(shù)據(jù)存儲方式肉瓦，這增加了事務管理的復雜性。

二、分布式事務解決方案

這里先簡單提及一下常見的分布式事務解決方案：

• seata阿里分布式事務框架
• 消息隊列
• saga
• XA

這四種常見的分布式事務解決方案泞莉，分別對應著分布式事務的四種模式：AT哪雕、TCC、Saga鲫趁、XA斯嚎；

四種分布式事務模式，都有各自的理論基礎挨厚，分別在不同的時間被提出堡僻；每種模式都有他的適用場景，同樣每個模式也都誕生有各自的代表產(chǎn)品疫剃，而這些代表產(chǎn)品钉疫，可能就是我們常見的（全局事務、基于可靠消息慌申、最大努力通知陌选、TCC）。

分布式事務相關的協(xié)議有2PC蹄溉、3PC咨油。由于三階段提交協(xié)議3PC非常難實現(xiàn)，目前市面主流的分布式事務解決方案都是2PC協(xié)議柒爵。兩階段提交協(xié)議顧名思義役电，分為兩個階段：Prepare和Commit。

TCC（Try-Confirm-Cancel）實際上是服務化的兩階段提交協(xié)議棉胀。

三法瑟、分布式事務框架Seata

1、Seata是什么

【Seata官網(wǎng)】

Seata（Simple Extensible Autonomous Transaction Architecture）是一款開源的分布式事務解決方案唁奢，致力于提供高性能和簡單易用的分布式事務服務霎挟。Seata 將為用戶提供了 AT、TCC麻掸、SAGA 和 XA四種事務模式酥夭，為用戶打造一站式的分布式解決方案，包括事務管理脊奋、本地事務協(xié)調熬北、分布式事務日志和分布式鎖等組件。

Seata通過使用分布式事務日志和分布式鎖來保證事務的一致性和可靠性诚隙。分布式事務日志記錄全局事務的操作日志讶隐，并提供了事務的恢復和回滾能力。分布式鎖用于保護全局事務在不同參與者之間的并發(fā)訪問久又，確保數(shù)據(jù)的一致性和正確性巫延。

2效五、Seata整體架構

一個典型的分布式事務過程分為一ID（全局事務id）+三組件模型。

• TC (Transaction Coordinator) - 事務協(xié)調者
  維護全局和分支事務的狀態(tài)烈评，驅動全局事務提交或回滾火俄。

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

• RM (Resource Manager) - 資源管理器
  管理分支事務處理的資源，與TC交談以注冊分支事務和報告分支事務的狀態(tài)适瓦，并驅動分支事務提交或回滾竿开。

Seata的整體架構如上圖，分TC玻熙、TM和RM三個角色否彩，TC（Server端）為單獨服務端部署，負責維護分布式事務的運行狀態(tài)嗦随，TM和RM（Client端）由業(yè)務系統(tǒng)集成列荔，TM是一個分布式事務的發(fā)起者和終結者，而RM則負責本地事務的運行并上報枚尼。

一個典型的事務過程：

1贴浙、TM向TC申請開啟一個全局事務 ，全局事務創(chuàng)建成功并生成一個全局唯一的XID;

2署恍、XID在微服務調用鏈路的上下文中傳播崎溃；

3、RM向TC注冊分支事務盯质，將其納入XID對應全局事務的管轄袁串；

4、TM向TC發(fā)起針對XID的全局提交或回滾決議呼巷；

5囱修、TC調度XID下管轄的全部分支事務完成提交或回滾請求；

3王悍、Seata支持的配置中心

Seata是一個分布式事務破镰，seata服務端也是一個微服務，需要和其他微服務一樣需要注冊中心和配置中心配名。

4渠脉、事務信息存儲配置

Server 端存儲模式（store.mode）支持三種方式：