分布式相關面試題匯總

現(xiàn)在Java面試，分布式系統(tǒng)、分布式事務幾乎是標配。而分布式系統(tǒng)、分

布式事務本身比較復雜，大家學起來也非常頭疼。

友情提示：

看完此文，在分布式事務這塊，基本可以做到吊打面試官了。

一圖解讀分布式事務

首先奉上一張全網(wǎng)最為牛逼的圖，給大家做個總覽：

I一圖搞一分布式事務V1.3BY架構師尼恩

名詞解釋

?事務：事務是由一組操作構成的可靠的獨立的工作單元，事務具備

ACID的特性，即原子性、一致性、隔離性和持久性。

?本地事務：當事務由資源管理器本地管理時被稱作本地事務。本地事務

的優(yōu)點就是支持嚴格的ACID特性，高效，可靠，狀態(tài)可以只在資源管

理器中維護，而且應用編程模型簡單。但是本地事務不具備分布式事務

的處理能力，隔離的最小單位受限于資源管理器。

?全局事務：當事務由全局事務管理器進行全局管理時成為全局事務，事

務管理器負責管理全局的事務狀態(tài)和參與的資源，協(xié)同資源的一致提交

回滾。

?TX協(xié)議：應用或者應用服務器與事務管理器的接口。

?XA協(xié)議：全局事務管理器與資源管理器的接口。XA是由X/Open組織提

出的分布式事務規(guī)范。該規(guī)范主要定義了全局事務管理器和局部資源管

理器之間的接口。主流的數(shù)據(jù)庫產(chǎn)品都實現(xiàn)了XA接口。XA接口是一個

雙向的系統(tǒng)接口，在事務管理器以及多個資源管理器之間作為通信橋

梁。之所以需要XA是因為在分布式系統(tǒng)中從理論上講兩臺機器是無法

達到一致性狀態(tài)的，因此引入一個單點進行協(xié)調(diào)。由全局事務管理器管

理和協(xié)調(diào)的事務可以跨越多個資源和進程。全局事務管理器一般使用

XA二階段協(xié)議與數(shù)據(jù)庫進行交互。

?AP：應用程序，可以理解為使用DTP(DataToolsPlatform)的程序。

?RM：資源管理器，這里可以是一個DBMS或者消息服務器管理系統(tǒng)，

應用程序通過資源管理器對資源進行控制，資源必須實現(xiàn)XA定義的接

□o資源管理器負責控制和管理實際的資源。

?TM：事務管理器，負責協(xié)調(diào)和管理事務，提供給AP編程接口以及管理

資源管理器。事務管理器控制著全局事務，管理事務的生命周期，并且

協(xié)調(diào)資源。

?兩階段提交協(xié)議：XA用于在全局事務中協(xié)調(diào)多個資源的機制。TM和

RM之間采取兩階段提交的方案來解決一致性問題。兩節(jié)點提交需要一

個協(xié)調(diào)者(TM)來掌控所有參與者(RM)節(jié)點的操作結果并且指引這

些節(jié)點是否需要最終提交。兩階段提交的局限在于協(xié)議成本，準備階段

的持久成本，全局事務狀態(tài)的持久成本，潛在故障點多帶來的脆弱性，

準備后，提交前的故障引發(fā)一系列隔離與恢復難題。

?BASE理論：BA指的是基本業(yè)務可用性，支持分區(qū)失敗，S表示柔性狀

態(tài)，也就是允許短時間內(nèi)不同步，E表示最終一致性，數(shù)據(jù)最終是一致

的，但是實時是不一致的。原子性和持久性必須從根本上保障，為了可

用性、性能和服務降級的需要，只有降低一致性和隔離性的要求。

?CAP定理：對于共享數(shù)據(jù)系統(tǒng)，最多只能同時擁有CAP其中的兩個，任

意兩個都有其適應的場景，真是的業(yè)務系統(tǒng)中通常是ACID與CAP的混

合體。分布式系統(tǒng)中最重要的是滿足業(yè)務需求，而不是追求高度抽象，

絕對的系統(tǒng)特性。C表示一致性，也就是所有用戶看到的數(shù)據(jù)是一樣

的。A表示可用性，是指總能找到一個可用的數(shù)據(jù)副本。P表示分區(qū)容

錯性，能夠容忍網(wǎng)絡中斷等故障。

分布式事務與分布式鎖的區(qū)別：

分布式鎖解決的是分布式資源搶占的問題；分布式事務和本地事務是

解決流程化提交問題。

事務簡介

事務(Transaction)是操作數(shù)據(jù)庫中某個數(shù)據(jù)項的一個程序執(zhí)行單元(uEt)。

事務應該具有4個屬性：原子性、一致性、隔離性、持久性。這四個屬性通

常稱為ACID特性。

事務的U!個特征:

1、Atomic原子性

事務必須是一個原子的操作序列單元，事務中包含的各項操作在一次執(zhí)行

過程中，要么全部執(zhí)行成功，要么全部不執(zhí)行，任何一項失敗，整個事務

回滾，只有全部都執(zhí)行成功，整個事務才算成功。

2、Consistency一致性

事務的執(zhí)行不能破壞數(shù)據(jù)庫數(shù)據(jù)的完整性和一致性，事務在執(zhí)行之前和之

后，數(shù)據(jù)庫都必須處于一致性狀態(tài)。

3、Isolation隔離性

在并發(fā)環(huán)境中，并發(fā)的事務是相互隔離的，一個事務的執(zhí)行不能被其他事

務干擾。即不同的事務并發(fā)操縱相同的數(shù)據(jù)時，每個事務都有各自完整的

數(shù)據(jù)空間，即一個事務內(nèi)部的操作及使用的數(shù)據(jù)對其他并發(fā)事務是隔離

的，并發(fā)執(zhí)行的各個事務之間不能相互干擾。

SQL中的4個事務隔離級別：

(1)讀未提交

允許臟讀。如果一個事務正在處理某一數(shù)據(jù)，并對其進行了更新，但同時尚未

完成事務，因此事務沒有提交，與此同時，允許另一個事務也能夠訪問該數(shù)

據(jù)。例如A將變量n從0累加到10才提交事務，此時B可能讀到n變量從0到10之

間的所有中間值。

(2)讀已提交

允許不可重復讀。只允許讀到已經(jīng)提交的數(shù)據(jù)。即事務A在將n從0累加到10的

過程中，B無法看到n的中間值，之中只能看到10。同時有事務C進行從10到

20的累加，此時B在同一個事務內(nèi)再次讀時，讀到的是20。

(3)可重復讀

允許幻讀。保證在事務處理過程中，多次讀取同一個數(shù)據(jù)時，其值都和事務開

始時刻時是一致的。禁止臟讀、不可重復讀?；米x即同樣的事務操作，在前后

兩個時間段內(nèi)執(zhí)行對同一個數(shù)據(jù)項的讀取，可能出現(xiàn)不一致的結果。保證B在

同一個事務內(nèi)，多次讀取n的值，讀到的都是初始值0?；米x，就是不同事

務，讀到的n的數(shù)據(jù)可能是0,可能10,可能是20

(4)串行化

最嚴格的事務，要求所有事務被串行執(zhí)行，不能并發(fā)執(zhí)行。

如果不對事務進行并發(fā)控制，我們看看數(shù)據(jù)庫并發(fā)操作是會有那些異常情

形

?(1)一類丟失更新：兩個事物讀同一數(shù)據(jù)，一個修改字段1,一個修改

字段2,后提交的恢復了先提交修改的字段。

?(2)二類丟失更新：兩個事物讀同一數(shù)據(jù)，都修改同一字段，后提交

的覆蓋了先提交的修改。

?(3)臟讀：讀到了未提交的值，萬一該事物回滾，則產(chǎn)生臟讀。

?(4)不可重復讀：兩個查詢之間，被另外一個事務修改了數(shù)據(jù)的內(nèi)

容，產(chǎn)生內(nèi)容的不一致。

?(5)幻讀：兩個查詢之間，被另外一個事務插入或刪除了記錄，產(chǎn)生

結果集的不一致。

4、Durability持久性

持久性(durability)：持久性也稱永久性(permanence),指一個事務一

旦提交，它對數(shù)據(jù)庫中對應數(shù)據(jù)的狀態(tài)變更就應該是永久性的。

即使發(fā)生系統(tǒng)崩潰或機器宕機，只要數(shù)據(jù)庫能夠重新啟動，那么一定能夠

將其恢復到事務成功結束時的狀態(tài)。

比方說：一個人買東西的時候需要記錄在賬本上，即使老板忘記了那

也有據(jù)可查。

MySQL的本地事務實現(xiàn)方案

大多數(shù)場景下，我們的應用都只需要操作單一的數(shù)據(jù)庫，這種情況下的事

務稱之為本地事務(LocalTransaction)o本地事務的ACID特性是數(shù)據(jù)庫直

接提供支持。

了解過MySQL事務的同學，就會知道，為了達成本地事務，MySQL做了很

多的工作，比如回滾日志，重做日志，MVCC,讀寫鎖等。

MySQL數(shù)據(jù)庫的事務實現(xiàn)原理

以MySQL的InnoDB(InnoDB是MySQL的一個存儲引擎)為例，介紹一

下單一數(shù)據(jù)庫的事務實現(xiàn)原理。

InnoDB是通過日志和鎖來保證的事務的ACID特性，具體如下：

(1)通過數(shù)據(jù)庫鎖的機制，保障事務的隔離性；

(2)通過Red。Log(重做日志)來，保障事務的持久性；

(3)通過UndoLog(撤銷日志)來，保障事務的原子性；

(4)通過UndoLog(撤銷日志)來，保障事務的一致性；

UndoLog如何保障事務的原子性呢？

具體的方式為：在操作任何數(shù)據(jù)之前，首先將數(shù)據(jù)備份到一個地方(這個

存儲數(shù)據(jù)備份的地方稱為UndoLog),然后進行數(shù)據(jù)的修改。如果出現(xiàn)了

錯誤或者用戶執(zhí)行了Rollback語句，系統(tǒng)可以利用UndoLog中的備份將

數(shù)據(jù)恢復到事務開始之前的狀態(tài)。

RedoLog如何保障事務的持久性呢?

具體的方式為：Red。Log記錄的是新數(shù)據(jù)的備份(和UndoLog相反)。

在事務提交前，只要將Red。Log持久化即可，不需要將數(shù)據(jù)持久化。當

系統(tǒng)崩潰時，雖然數(shù)據(jù)沒有持久化，但是RedoLog已經(jīng)持久化。系統(tǒng)可

以根據(jù)RedoLog的內(nèi)容，將所有數(shù)據(jù)恢復到崩潰之前的狀態(tài)。

臟讀、幻讀、不可重復讀

在多個事務并發(fā)操作時，數(shù)據(jù)庫中會出現(xiàn)下面三種問題：臟讀，幻讀，不

可重復讀。

臟讀(DirtyRead)

事務A讀到了事務B還未提交的數(shù)據(jù)：

事務A讀取的數(shù)據(jù)，事務B對該數(shù)據(jù)進行修改還未提交數(shù)據(jù)之前，事務A再

次讀取數(shù)據(jù)會讀到事務B已經(jīng)修改后的數(shù)據(jù)，如果此時事務B進行回滾或再

次修改該數(shù)據(jù)然后提交，事務A讀到的數(shù)據(jù)就是臟數(shù)據(jù)，這個情況被稱為臟

讀(DirtyRead)o

臟讀

事務A事務B

selectuagefromcsdn

whereuname=,wyk,;

-res:28

updatecsdnsetuage=30

whereuname=,wyk’;

selectuagefromcsdn

whereuname=,wyk,;

-res:30（臟讀）

rollback;

-uname:wyk,uage:28

或

updatecsdnsetuage=33

whereuname=，wyk，;

commit;

-uname:wyk,uage:33

幻讀(PhantomRead)

事務A進行范圍查詢時，事務B中新增了滿足該范圍條件的記錄，當事務A

再次按該條件進行范圍查詢，會查到在事務B中提交的新的滿足條件的記錄

(幻行PhantomRow)o

幻讀

事務A事務B

select*fromcsdnwhere

uage>25;

-rescount:2

insertinto

csdn(uname,uage,ucompany)

values

('wyk3‘/28’/csdn');

commit;

select*fromcsdnwhere

uage>25;

--rescount:3(幻讀)

('wykl''28','csdn')

('wyk2'，'28、'csdn')

C3丫1￡3','28',%Sm')幻行

不可重復讀(UnrepeatableRead)

事務A在讀取某些數(shù)據(jù)后，再次讀取該數(shù)據(jù)，發(fā)現(xiàn)讀出的該數(shù)據(jù)已經(jīng)在事務

B中發(fā)生了變更或刪除。

不可重復讀

事務A事務B

select*fromcsdnwhere

uname=，wyk3';

res:('wyk3,,528、’csdn,)

updatecsdnsetuage=30

whereuname=，wyk3’；

commit;

select*fromcsdnwhere

uname=，wyk3,;

res:('wyk3,,J30,,，csdn')

(不可重復讀)

幻讀和不可重復度的區(qū)別：

?幻讀：在同一事務中，相同條件下，兩次查詢出來的記錄數(shù)不一

樣；

?不可重復讀：在同一事務中，相同條件下，兩次查詢出來的數(shù)據(jù)

不一樣；

事務的隔離級別

為了解決數(shù)據(jù)庫中事務并發(fā)所產(chǎn)生的問題，在標準SQL規(guī)范中，定義了四

種事務隔離級別，每一種級別都規(guī)定了一個事務中所做的修改，哪些在事

務內(nèi)和事務間是可見的，哪些是不可見的。

低級別的隔離級一般支持更高的并發(fā)處理，并擁有更低的系統(tǒng)開銷。

MySQL事務隔離級別：https://dev.mysql.eom/doc/refman/8.0/en/innodb-tr

ansaction-isolation-levels.html

通過修改MySQL系統(tǒng)參數(shù)來控制事務的隔離級別，在MySQL8中該參數(shù)為

transactionjsolation,在MySQL5中該參數(shù)為txjsolation:

MySQL8：

—查看系統(tǒng)隔圖級別：

SELECT@^global.transaction_isolation;

一查看當前會話隔離級別

SELECT@@transaction_isolation;

--設置當前會話事務隔離級別

SETSESSIONTRANSACTIONISOLATIONLEVELSERIALIZABLE;

一設置全局事務隔離級別

SETGLOBALTRANSACTIONISOLATIONLEVELREADUNCOMMITTED;

事務的四個隔離級別：

?未提交讀(READUNCOMMITTED):所有事務都可以看到其他事務

未提交的修改。一般很少使用；

?提交讀(READCOMMITTED):Oracle默認隔離級別，事務之間只能

看到彼此已提交的變更修改；

?可重復讀(REPEATABLEREAD):MySQL默認隔離級別，同一事務

中的多次查詢會看到相同的數(shù)據(jù)行；可以解決不可重復讀，但可能出現(xiàn)

幻讀；

?可串行化(SERIALIZABLE)：最高的隔離級別，事務串行的執(zhí)行，

前一個事務執(zhí)行完，后面的事務會執(zhí)行。讀取每條數(shù)據(jù)都會加鎖，會導

致大量的超時和鎖爭用問題；

隔離級別臟讀可能性不可重復讀可能性幻讀可能性加鎖讀

READUNCOMMITTEDYesYesYesNo

READCOMMITTEDNoYesYesNo

REPEATABLEREADNoNoYesNo

SERIALIZABLENoNoNoYes

問：如何保證REPEATABLEREAD級別絕對不產(chǎn)生幻讀？

答：在SQL中加入forupdate(排他鎖)或lockinsharemode(共享

鎖)語句實現(xiàn)。就是鎖住了可能造成幻讀的數(shù)據(jù)，阻止數(shù)據(jù)的寫入操

作。

分布式事務的基本概念

分布式環(huán)境的事務復雜性

當本地事務要擴展到分布式時，它的復雜性進一步增加了。

存儲端的多樣性。

首先就是存儲端的多樣性。本地事務的情況下，所有數(shù)據(jù)都會落到同一個

DB中，但是，在分布式的情況下，就會出現(xiàn)數(shù)據(jù)可能要落到多個DB,或

者還會落到Redis,落到MQ等中。

存儲端多樣性,如下圖所示：

事務鏈路的延展性

本地事務的情況下，通常所有事務相關的業(yè)務操作，會被我們封裝到一個

Service方法中。而在分布式的情況下，請求鏈路被延展，拉長，一個操作

會被拆分成多個服務，它們呈現(xiàn)線狀或網(wǎng)狀，依靠網(wǎng)絡通信構建成一個整

體。在這種情況下，事務無疑變得更復雜。

事務鏈路延展性,如下圖所示:

基于上述兩個復雜性，期望有一個統(tǒng)一的分布式事務方案，能夠像本地事

務一樣，以幾乎無侵入的方式，滿足各種存儲介質(zhì)，各種復雜鏈路，是不

現(xiàn)實的。

至少，在當前，還沒有一個十分成熟的解決方案。所以，一般情況下，在

分布式下，事務會被拆分解決，并根據(jù)不同的情況，采用不同的解決方

案。

什么是分布式事務？

對于分布式系統(tǒng)而言，需要保證分布式系統(tǒng)中的數(shù)據(jù)一致性，保證數(shù)據(jù)在

子系統(tǒng)中始終保持一致，避免業(yè)務出現(xiàn)問題。分布式系統(tǒng)中對數(shù)要么一起

成功，要么一起失敗，必須是一個整體性的事務。

分布式事務指事務的參與者、支持事務的服務器、資源服務器以及事務管

理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上。

簡單的說，在分布式系統(tǒng)上一次大的操作由不同的小操作組成，這些小的

操作分布在不同的服務節(jié)點上，且屬于不同的應用，分布式事務需要保證

這些小操作要么全部成功，要么全部失敗。

舉個例子：在電商網(wǎng)站中，用戶對商品進行下單，需要在訂單表中創(chuàng)建一

條訂單數(shù)據(jù)，同時需要在庫存表中修改當前商品的剩余庫存數(shù)量，兩步操

作一個添加，一個修改，我們一定要保證這兩步操作一定同時操作成功或

失敗，否則業(yè)務就會出現(xiàn)問題。

任何事務機制在實現(xiàn)時，都應該考慮事務的ACID特性，包括：本地事務、

分布式事務。對于分布式事務而言，即使不能都很好的滿足，也要考慮支

持至U什么程度。

典型的分布式事務場景：

1.跨庫事務

跨庫事務指的是，一個應用某個功能需要操作多個庫，不同的庫中存儲不

同的業(yè)務數(shù)據(jù)。筆者見過一個相對比較復雜的業(yè)務，一個業(yè)務中同時操作

了9個庫。

下圖演示了一個服務同時操作2個庫的情況：

Transaction

數(shù)據(jù)庫A

Service

2.分庫分表

通常一個庫數(shù)據(jù)量比較大或者預期未來的數(shù)據(jù)量比較大，都會進行水平拆

分，也就是分庫分表。

如下圖，將數(shù)據(jù)庫B拆分成了2個庫:

對于分庫分表的情況，一般開發(fā)人員都會使用一些數(shù)據(jù)庫中間件來降低sql

操作的復雜性。

如，對于sql：insertintouser(id,name)values(1,"tianshouzhi"),

(2,"wangxiaoxiao")0這條sql是操作單庫的語法，單庫情況下，可以保證事

務的一致性。

但是由于現(xiàn)在進行了分庫分表，開發(fā)人員希望將1號記錄插入分庫1,2號記

錄插入分庫2。所以數(shù)據(jù)庫中間件要將其改寫為2條sql,分別插入兩個不同

的分庫，此時要保證兩個庫要不都成功，要不都失敗，因此基本上所有的

數(shù)據(jù)庫中間件都面臨著分布式事務的問題。

3.微服務化

微服務架構是目前一個比較一個比較火的概念。例如上面筆者提到的一個

案例，某個應用同時操作了9個庫，這樣的應用業(yè)務邏輯必然非常復雜，對

于開發(fā)人員是極大的挑戰(zhàn)，應該拆分成不同的獨立服務，以簡化業(yè)務邏

輯。拆分后，獨立服務之間通過RPC框架來進行遠程調(diào)用，實現(xiàn)彼此的通

信。下圖演示了一個3個服務之間彼此調(diào)用的架構：

Transaction

<ServiceB

--------------------\

ServiceA

ServiceC

ServiceA完成某個功能需要直接操作數(shù)據(jù)庫，同時需要調(diào)用ServiceB和

ServiceC,而ServiceB又同時操作了2個數(shù)據(jù)庫，ServiceC也操作了一個

庫。需要保證這些跨服務的對多個數(shù)據(jù)庫的操作要不都成功，要不都失

敗，實際上這可能是最典型的分布式事務場景。

分布式事務實現(xiàn)方案必須要考慮性能的問題，如果為了嚴格保證ACID特

性，導致性能嚴重下降，那么對于一些要求快速響應的業(yè)務，是無法接受

的。

CAP定理

分布式事務的理論基礎

數(shù)據(jù)庫事務ACID四大特性，無法滿足分布式事務的實際需求，這個時候又

有一些新的大牛提出一些新的理論。

CAP定理

CAP定理是由加州大學伯克利分校EricBrewer教授提出來的，他指出WEB

服務無法同時滿足一下3個屬性：

?一致性(Consistency):客戶端知道一系列的操作都會同時發(fā)生(生效)

?可用性(Availability):每個操作都必須以可預期的響應結束

?分區(qū)容錯性(Partitiontolerance)：即使出現(xiàn)單個組件無法可用，操作

依然可以完成

具體地講在分布式系統(tǒng)中，一個Web應用至多只能同時支持上面的兩個屬

性。因此，設計人員必須在一致性與可用性之間做出選擇。

2000年7月EricBrewer教授僅僅提出來的是一個猜想，2年后，麻省理工學

院的SethGilbert和NancyLynch從理論上證明了CAP理論，并且而一個分

布式系統(tǒng)最多只能滿足CAP中的2項。之后，CAP理論正式成為分布式計算

領域的公認定理。

ConsistencyCAAvailability

CPAP

Partition

Tolerance

所以，CAP定理在迄今為止的分布式系統(tǒng)中都是適用的！

CAP的一致性、可用性、分區(qū)容錯性具體如下：

1、一致性

數(shù)據(jù)一致性指"allnodesseethesamedataatthesametime",即更新操

作成功并返回客戶端完成后，所有節(jié)點在同一時間的數(shù)據(jù)完全一致，不能

存在中間狀態(tài)。

分布式環(huán)境中，一致性是指多個副本之間能否保持一致的特性。在一致性

的需求下，當一個系統(tǒng)在數(shù)據(jù)一致的狀態(tài)下執(zhí)行更新操作后，應該保證系

統(tǒng)的數(shù)據(jù)仍然處理一致的狀態(tài)。

例如對于電商系統(tǒng)用戶下單操作，庫存減少、用戶資金賬戶扣減、積分增

加等操作必須在用戶下單操作完成后必須是一致的。不能出現(xiàn)類似于庫存

已經(jīng)減少，而用戶資金賬戶尚未扣減，積分也未增加的情況。如果出現(xiàn)了

這種情況，那么就認為是不一致的。

數(shù)據(jù)一致性分為強一致性、弱一致性、最終一致性。

?如果的確能像上面描述的那樣時刻保證客戶端看到的數(shù)據(jù)都是一致的,

那么稱之為強一致性。

?如果允許存在中間狀態(tài)，只要求經(jīng)過一段時間后，數(shù)據(jù)最終是一致的,

則稱之為最終一致性。

?止匕外，如果允許存在部分數(shù)據(jù)不一致，那么就稱之為弱一致性。

面試題：什么是數(shù)據(jù)一致性？現(xiàn)在知道怎么回答了吧!

2、可用性

系統(tǒng)提供的服務必須一直處于可用的狀態(tài)，對于用戶的每一個操作請求總

是能夠在有限的時間內(nèi)返回結果。

兩個度量的維度：

(1)有限時間內(nèi)

對于用戶的一個操作請求，系統(tǒng)必須能夠在指定的時間(響應時間)內(nèi)返

回對應的處理結果，如果超過了這個時間范圍，那么系統(tǒng)就被認為是不可

用的。即這個響應時間必須在一個合理的值內(nèi)，不讓用戶感到失望。

試想，如果一個下單操作，為了保證分布式事務的一致性，需要10分鐘才

能處理完，那么用戶顯然是無法忍受的。

(2)返回正常結果

要求系統(tǒng)在完成對用戶請求的處理后，返回一個正常的響應結果。正常的

響應結果通常能夠明確地反映出對請求的處理結果，即成功或失敗，而不

是一個讓用戶感到困惑的返回結果。比如返回一個系統(tǒng)錯誤如

OutOfMemory,則認為系統(tǒng)是不可用的。

“返回結栗'是可用性的另一個非常重要的指標，它要求系統(tǒng)在完成對用戶請

求的處理后，返回一個正常的響應結果，不論這個結果是成功還是失敗。

3、分區(qū)容錯性

即分布式系統(tǒng)在遇到任何網(wǎng)絡分區(qū)故障時，仍然需要能夠保證對外提供滿

足一致性和可用性的服務，除非是整個網(wǎng)絡環(huán)境都發(fā)生了故障。

網(wǎng)絡分區(qū)，是指分布式系統(tǒng)中，不同的節(jié)點分布在不同的子網(wǎng)絡(機房/異

地網(wǎng)絡)中，由于一些特殊的原因?qū)е逻@些子網(wǎng)絡之間出現(xiàn)網(wǎng)絡不連通的

狀態(tài)，但各個子網(wǎng)絡的內(nèi)部網(wǎng)絡是正常的，從而導致整個系統(tǒng)的網(wǎng)絡環(huán)境

被切分成了若干孤立的區(qū)域。組成一個分布式系統(tǒng)的每個節(jié)點的加入與退

出都可以看做是一個特殊的網(wǎng)絡分區(qū)。

CAP的應用

1、放棄P

放棄分區(qū)容錯性的話，則放棄了分布式，放棄了系統(tǒng)的可擴展性

2、放棄A

放棄可用性的話，則在遇到網(wǎng)絡分區(qū)或其他故障時，受影響的服務需要等

待一定的時間，再此期間無法對外提供政策的服務，即不可用

3、放棄C

放棄一致性的話(這里指強一致)，則系統(tǒng)無法保證數(shù)據(jù)保持實時的一致

性，在數(shù)據(jù)達到最終一致性時，有個時間窗口，在時間窗口內(nèi)，數(shù)據(jù)是不

一致的。

對于分布式系統(tǒng)來說，P是不能放棄的，因此架構師通常是在可用性和一致

性之間權衡。

CAP理論告訴我們：

目前很多大型網(wǎng)站及應用都是分布式部署的，分布式場景中的數(shù)據(jù)一致性

問題一直是一個比較重要的話題。

基于CAP理論，很多系統(tǒng)在設計之初就要對這三者做出取舍：

任何一個分布式系統(tǒng)都無法同時滿足一致性(Consistency),可用性

(Availability)和分區(qū)容錯性(Partitiontolerance),最多只能同時

滿足兩項。在互聯(lián)網(wǎng)領域的絕大多數(shù)的場景中，都需要犧牲強一致性

來換取系統(tǒng)的高可用性，系統(tǒng)往往只需要保證最終一致性。

問：為什么分布式系統(tǒng)中無法同時保證一致性和可用性?

答：首先一個前提，對于分布式系統(tǒng)而言，分區(qū)容錯性是一個最基本

的要求，因此基本上我們在設計分布式系統(tǒng)的時候只能從一致性

（C）和可用性（A）之間進行取舍。

如果保證了一致性（C）：對于節(jié)點N1和N2,當往N1里寫數(shù)據(jù)時，

N2上的操作必須被暫停，只有當N1同步數(shù)據(jù)到N2時才能對N2進行讀

寫請求，在N2被暫停操作期間客戶端提交的請求會收到失敗或超時。

顯然，這與可用性是相悖的。

如果保證了可用性（A）：那就不能暫停N2的讀寫操作，但同時N1在

寫數(shù)據(jù)的話，這就違背了一致性的要求。

CAP權衡

通過CAP理論，我們知道無法同時滿足一致性、可用性和分區(qū)容錯

性這三個特性，那要舍棄哪個呢？

對于多數(shù)大型互聯(lián)網(wǎng)應用的場景，主機眾多、部署分散，而且現(xiàn)在的集群

規(guī)模越來越大，所以節(jié)點故障、網(wǎng)絡故障是常態(tài)，而且要保證服務可用性

達到N個9,即保證P和A,舍棄C（退而求其次保證最終一致性）。雖

然某些地方會影響客戶體驗，但沒達到造成用戶流程的嚴重程度。

對于涉及到錢財這樣不能有一絲讓步的場景，C必須保證。網(wǎng)絡發(fā)生故障

寧可停止服務，這是保證CA,舍棄P。貌似這幾年國內(nèi)銀行業(yè)發(fā)生了不下

10起事故，但影響面不大，報道也不多，廣大群眾知道的少。還有一種是

保證CP,舍棄A。例如網(wǎng)絡故障是只讀不寫。

CAP和ACID中的A和C是完全不一樣的

A的區(qū)別：

?ACID中的A指的是原子性(Atomidty),是指事務被視為一個不可分割的

最小工作單元，事務中的所有操作要么全部提交成功，要么全部失敗回

滾；

?CAP中的A指的是可用性(Availability),是指集群中一部分節(jié)點故障后，

集群整體是否還能響應客戶端的讀寫請求；

C的區(qū)別：

?ACID一致性是有關數(shù)據(jù)庫規(guī)則，數(shù)據(jù)庫總是從一個一致性的狀態(tài)轉(zhuǎn)換

到另外一個一致性的狀態(tài)；

?CAP的一致性是分布式多服務器之間復制數(shù)據(jù)令這些服務器擁有同樣的

數(shù)據(jù)，由于網(wǎng)速限制，這種復制在不同的服務器上所消耗的時間是不固

定的，集群通過組織客戶端查看不同節(jié)點上還未同步的數(shù)據(jù)維持邏輯視

圖，這是一種分布式領域的一致性概念；

總之：

ACID里的一致性指的是事務執(zhí)行前后，數(shù)據(jù)庫完整性，而CAP的一致性，

指的是分布式節(jié)點的數(shù)據(jù)的一致性。背景不同，無從可比

BASE定理

CAP是分布式系統(tǒng)設計理論，BASE是CAP理論中AP方案的延伸，對

于C我們采用的方式和策略就是保證最終一致性；

eBay的架構師DanPHtchett源于對大規(guī)模分布式系統(tǒng)的實踐總結，在ACM

上發(fā)表文章提出BASE理論，BASE理論是對CAP理論的延伸，核心思想是

即使無法做到強一致性（StrongConsistency,CAP的一致性就是強一致

性），但應用可以采用適合的方式達到最終一致性（Eventual

Consitency）o

BASE定理

BASE>BasicallyAvailable（基本可用）、Softstate（軟狀態(tài)）和

Eventuallyconsistent（最終一致性）三個短語的縮寫。BASE基于CAP定

理演化而來，核心思想是即時無法做到強一致性，但每個應用都可以根據(jù)

自身業(yè)務特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。

1、BasicallyAvailable（基本可用）

基本可用是指分布式系統(tǒng)在出現(xiàn)不可預知的故障的時候，允許損失部分可用

性，但不等于系統(tǒng)不可用。

（D響應時間上的損失

當出現(xiàn)故障時，響應時間增加

（2）功能上的損失

當流量高峰期時，屏蔽一些功能的使用以保證系統(tǒng)穩(wěn)定性（服務降級）

2、Softstate（軟狀態(tài)）

指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認為該中間狀態(tài)的存在不會影

響系統(tǒng)的整體可用性。

與硬狀態(tài)相對，即是指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認為該中間狀

態(tài)的存在不會影響系統(tǒng)的整體可用性，即允許系統(tǒng)在不同節(jié)點的數(shù)據(jù)副本

之間進行數(shù)據(jù)同步的過程存在延時。

3、Eventuallyconsistent（最終一致性）

強調(diào)系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過一段時間的同步后，最終能夠達到一

個一致的狀態(tài)。其本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達到一致，而不需要

實時保證系統(tǒng)數(shù)據(jù)的強一致性。

最終一致性可分為如下幾種:

?（1）因果一致性（Causalconsistency）

即進程A在更新完數(shù)據(jù)后通知進程B,那么之后進程B對該項數(shù)據(jù)的范圍

都是進程A更新后的最新值。

?(2)讀己之所寫(Readyourwhtes)

進程A更新一項數(shù)據(jù)后，它自己總是能訪問到自己更新過的最新值。

?(3)會話一致性(Sessionconsistency)

將數(shù)據(jù)一致性框定在會話當中，在一個會話當中實現(xiàn)讀己之所寫的一致

性。即執(zhí)行更新后，客戶端在同一個會話中始終能讀到該項數(shù)據(jù)的最新

值

?(4)單調(diào)讀一致性(Monotonicreadconsistency)

如果一個進程從系統(tǒng)中讀取出一個數(shù)據(jù)項的某個值后，那么系統(tǒng)對于該

進程后續(xù)的任何數(shù)據(jù)訪問都不應該返回更舊的值。

?(5)單調(diào)寫一致性(Monotoicwriteconsistency)

一個系統(tǒng)需要保證來自同一個進程的寫操作被順序執(zhí)行。

BASE理論是提出通過犧牲一致性來獲得可用性，并允許數(shù)據(jù)在一段時間內(nèi)

是不一致的，但最終達到一致狀態(tài)。

BASE理論的特點：

BASE理論面向的是大型高可用可擴展的分布式系統(tǒng)，和傳統(tǒng)的事物ACID

特性是相反的。

它完全不同于ACID的強一致性模型，而是通過犧牲強一致性來獲得可用

性，并允許數(shù)據(jù)在一段時間內(nèi)是不一致的，但最終達到一致狀態(tài)。

但同時，在實際的分布式場景中，不同業(yè)務單元和組件對數(shù)據(jù)一致性的要

求是不同的，因此在具體的分布式系統(tǒng)架構設計過程中，ACID特性和

BASE理論往往又會結合在一起。

BASE理論與CAP的關系

BASE理論是對CAP中一致性和可用性權衡的結果，其來源于對大規(guī)?；ヂ?lián)

網(wǎng)系統(tǒng)分布式實踐的總結，是基于CAP定理逐步演化而來的。BASE理論

的核心思想是：即使無法做到強一致性，但每個應用都可以根據(jù)自身業(yè)務

特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。

BASE理論其實就是對CAP理論的延伸和補充，主要是對AP的補充。犧牲

數(shù)據(jù)的強一致性，來保證數(shù)據(jù)的可用性，雖然存在中間裝填，但數(shù)據(jù)最終

一致。

ACID和BASE的區(qū)別與聯(lián)系

ACID是傳統(tǒng)數(shù)據(jù)庫常用的設計理念，追求強一致性模型。BASE支持的是

大型分布式系統(tǒng)，提出通過犧牲強一致性獲得高可用性。

ACID和BASE代表了兩種截然相反的設計哲學，在分布式系統(tǒng)設計的場

景中，系統(tǒng)組件對一致性要求是不同的，因此ACID和BASE又會結合使

用。

分布式事務分類：柔性事務和剛性事務

分布式場景下，多個服務同時對服務一個流程，比如電商下單場景，需要

支付服務進行支付、庫存服務扣減庫存、訂單服務進行訂單生成、物流服

務更新物流信息等。如果某一個服務執(zhí)行失敗，或者網(wǎng)絡不通引起的請求

丟失，那么整個系統(tǒng)可能出現(xiàn)數(shù)據(jù)不一致的原因。

上述場景就是分布式一致性問題，追根到底，分布式一致性的根本原因在

于數(shù)據(jù)的分布式操作，引起的本地事務無法保障數(shù)據(jù)的原子性引起。

分布式一致性問題的解決思路有兩種，一種是分布式事務，一種是盡量通

過業(yè)務流程避免分布式事務。分布式事務是直接解決問題，而業(yè)務規(guī)避其

實通過解決出問題的地方（解決提問題的人）。其實在真實業(yè)務場景中，如果

業(yè)務規(guī)避不是很麻煩的前提，最優(yōu)雅的解決方案就是業(yè)務規(guī)避。

分布式事務分類

分布式事務實現(xiàn)方案從類型上去分剛性事務、柔型事務：

?剛性事務滿足CAP的CP理論

?柔性事務滿足BASE理論（基本可用，最終一致）

剛性事務

剛性事務：通常無業(yè)務改造，強一致性，原生支持回滾/隔離性，低并發(fā)，

適合短事務。

原則：剛性事務滿足足CAP的CP理論

剛性事務指的是，要使分布式事務，達到像本地式事務一樣，具備數(shù)

據(jù)強一致性，從CAP來看，就是說，要達到CP狀態(tài)。

剛性事務：XA協(xié)議（2PC、JTA、JTS）、3PC,但由于同步阻塞，處理

效率低，不適合大型網(wǎng)站分布式場景。

柔性事務

柔性事務指的是，不要求強一致性，而是要求最終一致性，允許有中間狀

態(tài)，也就是Base理論，換句話說，就是AP狀態(tài)。

與剛性事務相比，柔性事務的特點為：有業(yè)務改造，最終一致性，實

現(xiàn)補償接口，實現(xiàn)資源鎖定接口，高并發(fā)，適合長事務。

柔性事務分為：

?補償型

?異步確保型

?最大努力通知型。

柔型事務：TCC/FMT.Saga(狀態(tài)機模式、Aop模式)、本地事務消息、

消息事務(半消息)

剛性事務：XA模型、XA接口規(guī)范、XA實現(xiàn)

XA模型或者X/OpenDTP模型

X/OPEN是一個組織.X/Open國際聯(lián)盟有限公司是一個歐洲基金會，它

的建立是為了向UNIX環(huán)境提供標準。它主要的目標是促進對UNIX語

言、接口、網(wǎng)絡和應用的開放式系統(tǒng)協(xié)議的制定。它還促進在不同的

UNIX環(huán)境之間的應用程序的互操作性，以及支持對電氣電子工程師協(xié)

會(IEEE)對UNIX的可移植操作系統(tǒng)接口(POSIX)規(guī)范。

X/OpenDTP(DistributedTransactionProcess)是一個分布式事務模

型。這個模型主要使用了兩段提交(2PC-Two-Phase-Comm讓)來保證分布

式事務的完整性。

在X/OpenDTP(DistributedTransactionProcess)模型里面，有三個角

色：

AP:Application,應用程序。也就是業(yè)務層。哪些操作屬于一個事務，就

是AP定義的。

TM:TransactionManager,事務管理器。接收AP的事務請求，對全局事

務進行管理，管理事務分支狀態(tài)，協(xié)調(diào)RM的處理，通知RM哪些操作屬于

哪些全局事務以及事務分支等等。這個也是整個事務調(diào)度模型的核心部

分。

RM：ResourceManager,資源管理器。一般是數(shù)據(jù)庫，也可以是其他的

資源管理器，如消息隊列(如JMS數(shù)據(jù)源)，文件系統(tǒng)等。

XA把參與事務的角色分成AP,RM,TMO

AP,即應用，也就是我們的業(yè)務服務。

RM指的是資源管理器，即DB,MQ等。

TM則是事務管理器。

AP自己操作TM,當需要事務時，AP向TM請求發(fā)起事務，TM負責整

個事務的提交，回滾等。

XA規(guī)范主要定義了(全局)事務管理器(TransactionManager)和(局部)資源管

理器(ResourceManager)之間的接口。XA接口是雙向的系統(tǒng)接口，在事務

管理器(TransactionManager)以及一個或多個資源管理器(Resource

Manager)之間形成通信橋梁。

XA之所以需要引入事務管理器是因為，在分布式系統(tǒng)中，從理論上講(參

考Fischer等的論文)，兩臺機器理論上無法達到一致的狀態(tài)，需要引入一

個單點進行協(xié)調(diào)。事務管理器控制著全局事務，管理事務生命周期，并協(xié)

調(diào)資源。資源管理器負責控制和管理實際資源(如數(shù)據(jù)庫或JMS隊列)

(2)APdefines

(1)APusestransaction

resourcesfromboundaries

asetofRMsthroughthe

TXinterface

(3)TMandRMsexchangetransactioninformation

XA規(guī)范

什么是XA

用非常官方的話來說：

?XA規(guī)范是X/Open組織定義的分布式事務處理(DTP,Distributed

TransactionProcessing)標準。

?XA規(guī)范描述了全局的事務管理器與局部的資源管理器之間的接口。

XA規(guī)范的目的是允許的多個資源(如數(shù)據(jù)庫，應用服務器，消息隊列

等)在同一事務中訪問，這樣可以使ACID屬性跨越應用程序而保持有

效。

?XA規(guī)范使用兩階段提交(2PC,Two-PhaseCommit)協(xié)議來保證所

有資源同時提交或回滾任何特定的事務。

?XA規(guī)范在上世紀90年代初就被提出。目前，幾乎所有主流的數(shù)據(jù)庫

都對XA規(guī)范提供了支持。

XA規(guī)范(XASpecification)是X/OPEN提出的分布式事務處理規(guī)范。XA則

規(guī)范了TM與RM之間的通信接口，在TM與多個RM之間形成一個雙向通信

橋梁，從而在多個數(shù)據(jù)庫資源下保證ACID四個特性。目前知名的數(shù)據(jù)庫，

如Oracle,DB2,mysql等，都是實現(xiàn)了XA接口的，都可以作為RM。

XA是數(shù)據(jù)庫的分布式事務，強一致性，在整個過程中，數(shù)據(jù)一張鎖住狀

態(tài)，即從prepare到commit、rollback的整個過程中，TM一直把持折數(shù)據(jù)庫

的鎖，如果有其他人要修改數(shù)據(jù)庫的該條數(shù)據(jù)，就必須等待鎖的釋放，存

在長事務風險。

以下的函數(shù)使事務管理器可以對資源管理器進行的操作：

1)xa_open,xa_close：建立和關閉與資源管理器的連接。

2)xa_start,xa_end：開始和結束一個本地事務。

3)xa_prepare,xa_commit,xa_rollback：預提交、提交和回滾一個本地事

務。

4)xa_recover：回滾一個已進行預提交的事務。

5)ax_開頭的函數(shù)使資源管理器可以動態(tài)地在事務管理器中進行注冊，并

可以對XID(TRANSACTIONIDS)進行操作。

6)ax_reg,ax_unreg；允許一個資源管理器在一個TMS(TRANSACTION

MANAGERSERVER)中動態(tài)注冊或撤消注冊。

XA各個階段的處理流程

APTMRM

發(fā)起全局事務

--

ax_reg():注冊分支事務

xa_open():打開連接

xa_start():標識分支事務開始

變更數(shù)據(jù)操作階段1

--------------------------------->

xa_end():標識分支事務結束

xa_prepare():準備提交事務

xa_commit():提交事務

xa_dose():關閉連接>階段2

ax_unreg():退出全局事務

XA協(xié)議的實現(xiàn)

2PC/3PC協(xié)議

兩階段提交(2PC)協(xié)議是XA規(guī)范定義的數(shù)據(jù)一致性協(xié)議。

三階段提交(3PC)協(xié)議對2PC協(xié)議的一種擴展。

Seata

Seata,官網(wǎng),github,1萬多星

Seata是一款開源的分布式事務解決方案，致力于在微服務架構下提供高

性能和簡單易用的分布式事務服務。Seata將為用戶提供了AT、TCC、

SAGA和XA事務模式

在Seata開源之前，Seata對應的內(nèi)部版本在阿里經(jīng)濟體內(nèi)部一直扮演著

分布式一致性中間件的角色，幫助經(jīng)濟體平穩(wěn)的度過歷年的雙11,對各BU

業(yè)務進行了有力的支撐。商業(yè)化產(chǎn)品GTS先后在阿里云、金融云進行售賣

Jta規(guī)范

作為java平臺上事務規(guī)范JTA(JavaTransactionAPI)也定義了對XA事務

的支持，實際上，JTA是基于XA架構上建模的，在JTA中，事務管理器抽

象為javax.transaction.TransactionManager接口，并通過底層事務服務

(即JTS)實現(xiàn)。像很多其他的java規(guī)范一樣，JTA僅僅定義了接口，具體

的實現(xiàn)則是由供應商(如J2EE廠商)負責提供，目前JTA的實現(xiàn)主要由以下

幾種：

1.J2EE容器所提供的JTA實現(xiàn)(JBoss)

2.獨立的JTA實現(xiàn):如JOTM,Atomikos.

這些實現(xiàn)可以應用在那些不使用J2EE應用服務器的環(huán)境里用以提供分布事

事務保證。如Tomcat,Jetty以及普通的java應用。

JTS規(guī)范

事務是編程中必不可少的一項內(nèi)容，基于此，為了規(guī)范事務開發(fā)，Java增

加了關于事務的規(guī)范，即JTA和JTS

JTA定義了一套接口，其中約定了幾種主要的角色：

TransactionManager.UserTransaction.TransactionsXAResource,并

定義了這些角色之間需要遵守的規(guī)范，如Transaction的委托給

TransactionManager^0

JTS也是一組規(guī)范，上面提到JTA中需要角色之間的交互，那應該如何交

互？JTS就是約定了交互細節(jié)的規(guī)范。

總體上來說JTA更多的是從框架的角度來約定程序角色的接口，而JTS則是

從具體實現(xiàn)的角度來約定程序角色之間的接口，兩者各司其職。

Atomikos分布式事務實現(xiàn)

Atomikos公司旗下有兩款著名的分布事務產(chǎn)品:

?TransactionEssentials：開源的免費產(chǎn)品

?ExtremeTransactions：商業(yè)版，需要收費

這兩個產(chǎn)品的關系如下圖所示：

可以看到，在開源版本中支持JTA/XA、JDBC、JMS的事務。

atom汰os也支持與spring事務整合。

spring事務管理器的頂級抽象是PlatformTransactionManager接口，其提供

了個重要的實現(xiàn)類：

?DataSourceTransactionManager：用于實現(xiàn)本地事務

?JTATransactionManager：用于實現(xiàn)分布式事務

顯然，在這里，我們需要配置的是JTATransactionManager。

publicclassJTAService{

@Autowired

privateUserMapperuserMapper;//操作db_user庫

@Autowired

privateAccountMapperaccountMapper;//操作db_account

庫

@Transactional

publicvoidinsert(){

Useruser=newUser();

user.setName("wangxiaoxiao**);

userMapper?insert(user);

//模擬異常，spring回滾后，db_user庫中user表中也不會插

入記錄

Accountaccount=newAccount();

account.setUserId(user.getld());

account.setMoney(123456789);

accountMapper?insert(account);

)

)

XA的主要限制

?必須要拿到所有數(shù)據(jù)源，而且數(shù)據(jù)源還要支持XA協(xié)議。目前MySQL中

只有InnoDB存儲引擎支持XA協(xié)議。

?性能比較差，要把所有涉及到的數(shù)據(jù)都要鎖定，是強一致性的，會產(chǎn)生

長事務。

SeataAT模式

SeataAT模式是增強型2pc模式。

AT模式：兩階段提交協(xié)議的演變，沒有一直鎖表

?一階段：業(yè)務數(shù)據(jù)和回滾日志記錄在同一個本地事務中提交，釋放本地

鎖和連接資源

?二階段：提交異步化，非?？焖俚赝瓿伞；蚧貪L通過一階段的回滾日志

進行反向補償

LCN(2pc)

TX-LCN,官方文檔，g4hub,3千多星，5.0以后由于框架兼容了LCN

(2pc)、TCC、TXC三種事務模式，為了區(qū)分LCN模式，特此將LCN分

布式事務改名為TX-LCN分布式事務框架。

TX-LCN定位于一款事務協(xié)調(diào)性框架，框架其本身并不生產(chǎn)事務，而是本地

事務的協(xié)調(diào)者，從而達到事務一致性的效果。

TX-LCN主要有兩個模塊，Tx-Client(TC),Tx-Manager?.

?TM(Tx-Manager)：是獨立的服務，是分布式事務的控制方，協(xié)調(diào)分

布式事務的提交，回滾

?TC(Tx-Client)：由業(yè)務系統(tǒng)集成，事務發(fā)起方、參與方都由TxClient

端來控制

2PC(標準XA模型)

2PC即Two-PhaseCommit,二階段提交。

詳解：二個階段

廣泛應用在數(shù)據(jù)庫領域，為了使得基于分布式架構的所有節(jié)點可以在進行

事務處理時能夠保持原子性和一致性。絕大部分關系型數(shù)據(jù)庫，都是基于

2PC完成分布式的事務處理。

顧名思義，2PC分為兩個階段處理，階段一：提交事務請求、階段二：執(zhí)

行事務提交；

如果階段一超時或者出現(xiàn)異常，2PC的階段二：中斷事務

階段一：提交事務請求

1.事務詢問。協(xié)調(diào)者向所有參與者發(fā)送事務內(nèi)容，詢問是否可以執(zhí)行提交

操作，并開始等待各參與者進行響應；

2.執(zhí)行事務。各參與者節(jié)點，執(zhí)行事務操作，并將Undo和Red。操作計入

本機事務日志；

3.各參與者向協(xié)調(diào)者反饋事務問詢的響應。成功執(zhí)行返回Yes,否則返回

No0

階段二：執(zhí)行事務提交

協(xié)調(diào)者在階段二決定是否最終執(zhí)行事務提交操作。這一階段包含兩種情

形：

執(zhí)行事務提交

所有參與者replyYes,那么執(zhí)行事務提交。

1.發(fā)送提交請求。協(xié)調(diào)者向所有參與者發(fā)送Commit請求；

2.事務提交。參與者收到Comm讓請求后，會正式執(zhí)行事務提交操作，并

在完成提交操作之后，釋放在整個事務執(zhí)行期間占用的資源；

3.反饋事務提交結果。參與者在完成事務提交后，寫協(xié)調(diào)者發(fā)送Ack消息

確認；

4.完成事務。協(xié)調(diào)者在收到所有參與者的Ack后，完成事務。

階段二：中斷事務

事情總會出現(xiàn)意外，當存在某一參與者向協(xié)調(diào)者發(fā)送No響應，或者等待超

時。協(xié)調(diào)者只要無法收到所有參與者的Yes響應，就會中斷事務。

1.發(fā)送回滾請求。協(xié)調(diào)者向所有參與者發(fā)送Rollback請求；

2.回滾。參與者收到請求后，利用本機Undo信息，執(zhí)行Rollback操作。并

在回滾結束后釋放該事務所占用的系統(tǒng)資源；

3.反饋回滾結果。參與者在完成回滾操作后，向協(xié)調(diào)者發(fā)送Ack消息；

4.中斷事務。協(xié)調(diào)者收到所有參與者的回滾Ack消息后，完成事務中斷。

2pc解決的是分布式數(shù)據(jù)強一致性問題

顧名思義，兩階段提交在處理分布式事務時分為兩個階段：voting（投票階

段，有的地方會叫做prepare階段）和commit階段。

2pc中存在兩個角色，事務協(xié)調(diào)者（seata、atomikos、Icn）和事務參與

者，事務參與者通常是指應用的數(shù)據(jù)庫。

1.協(xié)調(diào)者向所有的參與者發(fā)送事務執(zhí)行請

求，并等待參與者反饋事務執(zhí)行結果。

投票階段Y2.事務參與者收到請求之后，執(zhí)行事務但不

提交，并記錄事務日志。

3.參與者將自己事務執(zhí)行情況反饋給協(xié)調(diào)

者，同時阻塞等待協(xié)調(diào)者的后續(xù)指令。

經(jīng)過第一階段協(xié)調(diào)者的詢盤

之后，各個參與者會回復自

己事務的執(zhí)行情況，這時候

存在三種可能性

提交階段Y

2PC二階段提交的特點

2PC方案比較適合單體應用

2PC方案中，有一個事務管理器的角色，負責協(xié)調(diào)多個數(shù)據(jù)庫（資源管理

器）的事務，事務管理器先問問各個數(shù)據(jù)庫你準備好了嗎？如果每個數(shù)據(jù)

庫都回復ok,那么就正式提交事務，在各個數(shù)據(jù)庫上執(zhí)行操作；如果任何

其中一個數(shù)據(jù)庫回答不。k,那么就回滾事務。

2PC方案比較適合單體應用里，跨多個庫的分布式事務，而且因為嚴重依

賴于數(shù)據(jù)庫層面來搞定復雜的事務，效率很低，絕對不適合高并發(fā)的場

景。

2PC方案實際很少用，一般來說某個系統(tǒng)內(nèi)部如果出現(xiàn)跨多個庫的這么一

個操作，是不合規(guī)的。我可以給大家介紹一下，現(xiàn)在微服務，一個大的系

統(tǒng)分成幾百個服務，幾十個服務。一般來說，我們的規(guī)定和規(guī)范，是要求

每個服務只能操作自己對應的一個數(shù)據(jù)庫。

如果你要操作別的服務對應的庫，不允許直連別的服務的庫，違反微服務

架構的規(guī)范，你隨便交叉胡亂訪問，幾百個服務的話，全體亂套，這樣的

一套服務是沒法管理的，沒法治理的，可能會出現(xiàn)數(shù)據(jù)被別人改錯，自己

的庫被別人寫掛等情況。

如果你要操作別人的服務的庫，你必須是通過調(diào)用別的服務的接口來實

現(xiàn)，絕對不允許交叉訪問別人的數(shù)據(jù)庫。

2PC具有明顯的優(yōu)缺點：

優(yōu)點主要體現(xiàn)在實現(xiàn)原理簡單;

缺點比較多：

?2PC的提交在執(zhí)行過程中，所有參與事務操作的邏輯都處于阻塞狀態(tài)，

也就是說，各個參與者都在等待其他參與者響應，無法進行其他操作；

?協(xié)調(diào)者是個單點，一旦出現(xiàn)問題，其他參與者將無法釋放事務資源，也

無法完成事務操作；

?數(shù)據(jù)不一致。當執(zhí)行事務提交過程中，如果協(xié)調(diào)者向所有參與者發(fā)送

Comm計請求后，發(fā)生局部網(wǎng)絡異?；蛘邊f(xié)調(diào)者在尚未發(fā)送完Comm計請

求，即出現(xiàn)崩潰，最終導致只有部分參與者收到、執(zhí)行請求。于是整個

系統(tǒng)將會出現(xiàn)數(shù)據(jù)不一致的情形；

?保守。2PC沒有完善的容錯機制，當參與者出現(xiàn)故障時，協(xié)調(diào)者無法快

速得知這一失敗，只能嚴格依賴超時設置來決定是否進一步的執(zhí)行提交

還是中斷事務。

實際上分布式事務是一件非常復雜的事情，兩階段提交只是通過增加了事

務協(xié)調(diào)者(Coordinator)的角色來通過2個階段的處理流程來解決分布式

系統(tǒng)中一個事務需要跨多個服務節(jié)點的數(shù)據(jù)一致性問題。但是從異常情況

上考慮，這個流程也并不是那么的無懈可擊。

假設如果在第二個階段中Coordinator在接收到Partcipant

的"Vote_Request”后掛掉了或者網(wǎng)絡出現(xiàn)了異常，那么止匕時Partcipant節(jié)點

就會一直處于本地事務掛起的狀態(tài)，從而長時間地占用資源。當然這種情

況只會出現(xiàn)在極端情況下，然而作為一套健壯的軟件系統(tǒng)而言，異常Case

的處理才是真正考驗方案正確性的地方。

總結一下：XA?兩階段提交協(xié)議中會遇到的一些問題

?性能問題

從流程上我們可以看得出，其最大缺點就在于它的執(zhí)行過程中間，節(jié)點都

處于阻塞狀態(tài)。各個操作數(shù)據(jù)庫的節(jié)點此時都占用著數(shù)據(jù)庫資源，只有當

所有節(jié)點準備完畢，事務協(xié)調(diào)者才會通知進行全局提交，參與者進行本地

事務提交后才會釋放資源。這樣的過程會比較漫長，對性能影響比較大。

?協(xié)調(diào)者單點故障問題

事務協(xié)調(diào)者是整個XA模型的核心，一旦事務協(xié)調(diào)者節(jié)點掛掉，會導致參與

者收不到提交或回滾的通知，從而導致參與者節(jié)點始終處于事務無法完成

的中間狀態(tài)。

?丟失消息導致的數(shù)據(jù)不一致問題

在第二個階段，如果發(fā)生局部網(wǎng)絡問題，一部分事務參與者收到了提交消

息，另一部分事務參與者沒收到提交消息、，那么就會導致節(jié)點間數(shù)據(jù)的不

一致問題。

3PC

針對2PC的缺點，研究者提出了3PC,即Three-PhaseCommit。

作為2PC的改進版，3PC將原有的兩階段過程，重新劃分為CanCommit、

PreCommit和doComm計三個階段。

詳解：三個階段

CoordinatorParticipant

階段一：CanCommit

1.事務詢問。協(xié)調(diào)者向所有參與者發(fā)送包含事務內(nèi)容的canCommit的請

求，詢問是否可以執(zhí)行事務提交，并等待應答；

2.各參與者反饋事務詢問。正常情況下，如果參與者認為可以順利執(zhí)行事

務，則返回Yes,否則返回No。

階段二：PreCommit

在本階段，協(xié)調(diào)者會根據(jù)上一階段的反饋情況來決定是否可以執(zhí)行事務的

PreComm計操作。有以下兩種可能：

執(zhí)行事務預提交

1.發(fā)送預提交請求。協(xié)調(diào)者向所有節(jié)點發(fā)出PreComm讓請求，并進入

prepared階段；

2.事務預提交。參與者收到PreCommit請求后，會執(zhí)行事務操作，并將

Undo和Redo日志寫入本機事務日志；

3.各參與者成功執(zhí)行事務操作，同時將反饋以Ack響應形式發(fā)送給協(xié)調(diào)

者，同事等待最終的Commit或Abort指令。

中斷事務

加入任意一個參與者向協(xié)調(diào)者發(fā)送No響應，或者等待超時，協(xié)調(diào)者在沒有

得到所有參與者響應時，即可以中斷事務：

1.發(fā)送中斷請求。協(xié)調(diào)者向所有參與者發(fā)送A