1.0 分布式事務(wù)概述 2018-02-05 02:05:26 32,685 16
1、事務(wù)簡介
事務(wù)(Transaction)是訪問并可能更新數(shù)據(jù)庫中各種數(shù)據(jù)項的一個程序執(zhí)行單元(unit)。在關(guān)系數(shù)據(jù)庫中，一個事務(wù)由一組SQL語句組成。事務(wù)應(yīng)該具有4個屬性：原子性、一致性、隔離性、持久性。這四個屬性通常稱為ACID特性。 原子性（atomicity）：個事務(wù)是一個不可分割的工作單位，事務(wù)中包括的諸操作要么都做，要么都不做。 一致性（consistency）：事務(wù)必須是使數(shù)據(jù)庫從一個一致性狀態(tài)變到另一個一致性狀態(tài)，事務(wù)的中間狀態(tài)不能被觀察到的。 隔離性（isolation）：一個事務(wù)的執(zhí)行不能被其他事務(wù)干擾。即一個事務(wù)內(nèi)部的操作及使用的數(shù)據(jù)對并發(fā)的其他事務(wù)是隔離的，并發(fā)執(zhí)行的各個事務(wù)之間不能互相干擾。隔離性又分為四個級別：讀未提交(read uncommitted)、讀已提交(read committed，解決臟讀)、可重復(fù)讀(repeatable read，解決虛讀)、串行化(serializable，解決幻讀)。持久性（durability）：持久性也稱永久性（permanence），指一個事務(wù)一旦提交，它對數(shù)據(jù)庫中數(shù)據(jù)的改變就應(yīng)該是永久性的。接下來的其他操作或故障不應(yīng)該對其有任何影響。任何事務(wù)機制在實現(xiàn)時，都應(yīng)該考慮事務(wù)的ACID特性，包括：本地事務(wù)、分布式事務(wù)，及時不能都很好的滿足，也要考慮支持到什么程度。
2 本地事務(wù)
大多數(shù)場景下，我們的應(yīng)用都只需要操作單一的數(shù)據(jù)庫，這種情況下的事務(wù)稱之為本地事務(wù)(Local Transaction)。本地事務(wù)的ACID特性是數(shù)據(jù)庫直接提供支持。本地事務(wù)應(yīng)用架構(gòu)如下所示：
Connection conn = ... //獲取數(shù)據(jù)庫連接
conn.setAutoCommit(false); //開啟事務(wù)
try{
//...執(zhí)行增刪改查sql
conn.commit(); //提交事務(wù)
}catch (Exception e) {
conn.rollback();//事務(wù)回滾
}finally{
conn.close();//關(guān)閉鏈接
}
此外，很多java應(yīng)用都整合了spring，并使用其聲明式事務(wù)管理功能來完成事務(wù)功能。一般使用的步驟如下：
1、配置事務(wù)管理器。spring提供了一個PlatformTransactionManager接口，其有2個重要的實現(xiàn)類： DataSourceTransactionManager：用于支持本地事務(wù)，事實上，其內(nèi)部也是通過操作java.sql.Connection來開啟、提交和回滾事務(wù)。 JtaTransactionManager：用于支持分布式事務(wù)，其實現(xiàn)了JTA規(guī)范，使用XA協(xié)議進行兩階段提交。需要注意的是，這只是一個代理，我們需要為其提供一個JTA provider，一般是Java EE容器提供的事務(wù)協(xié)調(diào)器(Java EE server's transaction coordinator)，也可以不依賴容器，配置一個本地的JTA provider。2、 在需要開啟的事務(wù)的bean的方法上添加@Transitional注解可以看到，spring除了支持本地事務(wù)，也支持分布式事務(wù)，下面我們先對分布式事務(wù)的典型應(yīng)用場景進行介紹。
3 分布式事務(wù)典型場景
當(dāng)下互聯(lián)網(wǎng)發(fā)展如火如荼，絕大部分公司都進行了數(shù)據(jù)庫拆分和服務(wù)化(SOA)。在這種情況下，完成某一個業(yè)務(wù)功能可能需要橫跨多個服務(wù)，操作多個數(shù)據(jù)庫。這就涉及到到了分布式事務(wù)，用需要操作的資源位于多個資源服務(wù)器上，而應(yīng)用需要保證對于多個資源服務(wù)器的數(shù)據(jù)的操作，要么全部成功，要么全部失敗。本質(zhì)上來說，分布式事務(wù)就是為了保證不同資源服務(wù)器的數(shù)據(jù)一致性。
典型的分布式事務(wù)場景：
1、跨庫事務(wù)
跨庫事務(wù)指的是，一個應(yīng)用某個功能需要操作多個庫，不同的庫中存儲不同的業(yè)務(wù)數(shù)據(jù)。筆者見過一個相對比較復(fù)雜的業(yè)務(wù)，一個業(yè)務(wù)中同時操作了9個庫。下圖演示了一個服務(wù)同時操作2個庫的情況：
通常一個庫數(shù)據(jù)量比較大或者預(yù)期未來的數(shù)據(jù)量比較大，都會進行水平拆分，也就是分庫分表。如下圖，將數(shù)據(jù)庫B拆分成了2個庫：
但是由于現(xiàn)在進行了分庫分表，開發(fā)人員希望將1號記錄插入分庫1，2號記錄插入分庫2。所以數(shù)據(jù)庫中間件要將其改寫為2條sql，分別插入兩個不同的分庫，此時要保證兩個庫要不都成功，要不都失敗，因此基本上所有的數(shù)據(jù)庫中間件都面臨著分布式事務(wù)的問題。
3、服務(wù)化(SOA)
微服務(wù)架構(gòu)是目前一個比較一個比較火的概念。例如上面筆者提到的一個案例，某個應(yīng)用同時操作了9個庫，這樣的應(yīng)用業(yè)務(wù)邏輯必然非常復(fù)雜，對于開發(fā)人員是極大的挑戰(zhàn)，應(yīng)該拆分成不同的獨立服務(wù)，以簡化業(yè)務(wù)邏輯。拆分后，獨立服務(wù)之間通過RPC框架來進行遠程調(diào)用，實現(xiàn)彼此的通信。下圖演示了一個3個服務(wù)之間彼此調(diào)用的架構(gòu)：
Service A完成某個功能需要直接操作數(shù)據(jù)庫，同時需要調(diào)用Service B和Service C，而Service B又同時操作了2個數(shù)據(jù)庫，Service C也操作了一個庫。需要保證這些跨服務(wù)的對多個數(shù)據(jù)庫的操作要不都成功，要不都失敗，實際上這可能是最典型的分布式事務(wù)場景。小結(jié)：上述討論的分布式事務(wù)場景中，無一例外的都直接或者間接的操作了多個數(shù)據(jù)庫。如何保證事務(wù)的ACID特性，對于分布式事務(wù)實現(xiàn)方案而言，是非常大的挑戰(zhàn)。同時，分布式事務(wù)實現(xiàn)方案還必須要考慮性能的問題，如果為了嚴(yán)格保證ACID特性，導(dǎo)致性能嚴(yán)重下降，那么對于一些要求快速響應(yīng)的業(yè)務(wù)，是無法接受的。
4 X/Open DTP模型與XA規(guī)范
X/Open，即現(xiàn)在的open group，是一個獨立的組織，主要負責(zé)制定各種行業(yè)技術(shù)標(biāo)準(zhǔn)。官網(wǎng)地址：http://www.opengroup.org/。X/Open組織主要由各大知名公司或者廠商進行支持，這些組織不光遵循X/Open組織定義的行業(yè)技術(shù)標(biāo)準(zhǔn)，也參與到標(biāo)準(zhǔn)的制定。下圖展示了open group目前主要成員(官網(wǎng)截圖)：
就分布式事務(wù)處理(Distributed Transaction Processing,簡稱DTP)而言，X/Open主要提供了以下參考文檔：
DTP 參考模型： <>
DTP XA規(guī)范： << Distributed Transaction Processing: The XA Specification>>
4.1 DTP模型
1、模型元素
在<>第3版中，規(guī)定了構(gòu)成DTP模型的5個基本元素：
應(yīng)用程序(Application Program ，簡稱AP)：用于定義事務(wù)邊界(即定義事務(wù)的開始和結(jié)束)，并且在事務(wù)邊界內(nèi)對資源進行操作。
資源管理器(Resource Manager，簡稱RM)：如數(shù)據(jù)庫、文件系統(tǒng)等，并提供訪問資源的方式。
事務(wù)管理器(Transaction Manager ，簡稱TM)：負責(zé)分配事務(wù)唯一標(biāo)識，監(jiān)控事務(wù)的執(zhí)行進度，并負責(zé)事務(wù)的提交、回滾等。
通信資源管理器(Communication Resource Manager，簡稱CRM)：控制一個TM域(TM domain)內(nèi)或者跨TM域的分布式應(yīng)用之間的通信。
通信協(xié)議(Communication Protocol，簡稱CP)：提供CRM提供的分布式應(yīng)用節(jié)點之間的底層通信服務(wù)。
其中由于通信資源管理器(Communication Resource Manager)和通信協(xié)議(Communication Protocol)是一對好基友，從Communication Protocol的簡稱CP上就可以看出來，兩個元素的關(guān)系不一般，因此有的文章在介紹DTP模型元素時，只提到了通信資源管理器....
2、模型實例(Instance of the Model)
一個DTP模型實例，至少有3個組成部分：AP、RMs、TM。如下所示：
特別的，如果分布式事務(wù)需要跨多個應(yīng)用，類似于我們前面的提到的分布式事務(wù)場景中的服務(wù)化，那么每個模型實例中，還需要額外的加入一個通信資源管理器CRM。下圖中演示了2個模型實例，如何通過CRM來進行通信：
基本的通信能力：從這個角度，可以將CRM類比為RPC框架，模型實例之間通過RPC調(diào)用實現(xiàn)彼此的通信。這一點體現(xiàn)在AP、CRM之間的連線。
事務(wù)傳播能力：與傳統(tǒng)RPC框架不同的是，CRM底層采用OSI TP(Open Systems Interconnection — Distributed Transaction Processing)通信服務(wù)，因此CRM具備事務(wù)傳播能力。這一點體現(xiàn)TM、CRM之間的連線。
2、事務(wù)管理器作用域 （TM domain）
一個TM domain中由一個或者多個模型實例組成，這些模型實例使用的都是同一個TM，但是操作的RMs各不相同，由TM來統(tǒng)一協(xié)調(diào)這些模型實例共同參與形成的全局事務(wù)(global transaction)。
下圖展示了一個由四個模型實例組成的TM Domain，這四個模型實例使用的都是同一個事務(wù)管理器TM1。
不過顯然的，當(dāng)一個TM domain中存在多個模型實例時，模型實例彼此之間存在一定的層級調(diào)用關(guān)系。這就是全局事務(wù)的樹形結(jié)構(gòu)。
3 全局事務(wù)樹形結(jié)構(gòu)(Global Transaction Tree Structure)
當(dāng)一個TM domain中，存在多個模型實例時，會形成一種樹形條用關(guān)系，如下圖所示：
其中：
發(fā)起分布式事務(wù)的模型實例稱之為root節(jié)點，或者稱之為事務(wù)的發(fā)起者，其他的模型實例可以統(tǒng)稱為事務(wù)的參與者。事務(wù)發(fā)起者負責(zé)開啟整個全局事務(wù)，事務(wù)參與者各自負責(zé)執(zhí)行自己的事務(wù)分支。而從模型實例之間的相互調(diào)用關(guān)系來說，調(diào)用方稱之為上游節(jié)點(Superior Node)，被調(diào)用方稱之為下游節(jié)點(Subordinate Node)。
小結(jié)：通過對DTP模型的介紹，我們可以看出來，之前提到的分布式事務(wù)的幾種典型場景實際上在DTP模型中都包含了，甚至比我們考慮的還復(fù)雜。DTP模型從最早提出到現(xiàn)在已經(jīng)有接近30年，到如今依然適用，不得不佩服模型的設(shè)計者是很有遠見的。
4.2 XA規(guī)范
在DTP本地模型實例中，由AP、RMs和TM組成，不需要其他元素。AP、RM和TM之間，彼此都需要進行交互，如下圖所示：
The subject of this X/Open specification is interface (3) in the diagram above, the XA interface by which TMs and RMs interact.
For more details on this model and diagram, including detailed definitions of each component, see the referenced DTP guide.
也就是說XA規(guī)范的最主要的作用是，就是定義了RM-TM的交互接口，下圖更加清晰了演示了XA規(guī)范在DTP模型中發(fā)揮作用的位置，從下圖中可以看出來，XA僅僅出現(xiàn)在RM和TM的連線上。
XA規(guī)范除了定義的RM-TM交互的接口(XA Interface)之外，還對兩階段提交協(xié)議進行了優(yōu)化。 一些讀者可能會誤認為兩階段提交協(xié)議是在XA規(guī)范中提出來的。事實上： 兩階段協(xié)議(two-phase commit)是在OSI TP標(biāo)準(zhǔn)中提出的；在DTP參考模型(<<Distributed Transaction Processing: Reference Model>>)中，指定了全局事務(wù)的提交要使用two-phase commit協(xié)議；而XA規(guī)范(<< Distributed Transaction Processing: The XA Specification>>)只是定義了兩階段提交協(xié)議中需要使用到的接口，也就是上述提到的RM-TM交互的接口，因為兩階段提交過程中的參與方，只有TM和RMs。參見<<Distributed Transaction Processing: Reference Model>> 第3版 2.1節(jié)，原文如下：
Commitment Protocol
A commitment protocol is the synchronisation that occurs at transaction completion. The X/Open DTP Model follows the two-phase commit with presumed rollback1 protocol defined in the referenced OSI TP standards. A description of the basic protocol is given in Section 3.4.3 on page 13. In certain cases, a global transaction may be completed heuristically. Heuristic transaction completion is described in Section 3.4.5 on page 14.
4.2.1 XA Interface
XA規(guī)范中定義的RM 和 TM交互的接口如下圖所示：
關(guān)于這些接口的詳細解釋，可以直接參考XA規(guī)范。后面在講解到mysql對XA事務(wù)的支持時，我們也會使用到部分命令。
4.2.2 兩階段提交協(xié)議(2PC)
兩階段提交協(xié)議（Two Phase Commit）不是在XA規(guī)范中提出，但是XA規(guī)范對其進行了優(yōu)化，因此統(tǒng)一放到這里進行講解。而從字面意思來理解，Two Phase Commit，就是將提交(commit)過程劃分為2個階段(Phase)：
In Phase 1, the TM asks all RMs to prepare to commit (or prepare) transaction branches. This asks whether the RM can guarantee its ability to commit the transaction branch. An RM may have to query other entities internal to that RM.
If an RM can commit its work, it records stably the information it needs to do so, then replies affirmatively. A negative reply reports failure for any reason. After making a negative reply and rolling back its work, the RM can discard any knowledge it has of the transaction branch.
In Phase 2, the TM issues all RMs an actual request to commit or roll back the transaction branch, as the case may be. (Before issuing requests to commit, the TM stably records the fact that it decided to commit, as well as a list of all involved RMs.) All RMs commit or roll back changes to shared resources and then return status to the TM. The TM can then discard its knowledge of the global transaction.
階段1：
TM通知各個RM準(zhǔn)備提交它們的事務(wù)分支。如果RM判斷自己進行的工作可以被提交，那就就對工作內(nèi)容進行持久化，再給TM肯定答復(fù)；要是發(fā)生了其他情況，那給TM的都是否定答復(fù)。在發(fā)送了否定答復(fù)并回滾了已經(jīng)的工作后，RM就可以丟棄這個事務(wù)分支信息。以mysql數(shù)據(jù)庫為例，在第一階段，事務(wù)管理器向所有涉及到的數(shù)據(jù)庫服務(wù)器發(fā)出prepare"準(zhǔn)備提交"請求，數(shù)據(jù)庫收到請求后執(zhí)行數(shù)據(jù)修改和日志記錄等處理，處理完成后只是把事務(wù)的狀態(tài)改成"可以提交",然后把結(jié)果返回給事務(wù)管理器。
階段2
TM根據(jù)階段1各個RM prepare的結(jié)果，決定是提交還是回滾事務(wù)。如果所有的RM都prepare成功，那么TM通知所有的RM進行提交；如果有RM prepare失敗的話，則TM通知所有RM回滾自己的事務(wù)分支。 以mysql數(shù)據(jù)庫為例，如果第一階段中所有數(shù)據(jù)庫都prepare成功，那么事務(wù)管理器向數(shù)據(jù)庫服務(wù)器發(fā)出"確認提交"請求，數(shù)據(jù)庫服務(wù)器把事務(wù)的"可以提交"狀態(tài)改為"提交完成"狀態(tài)，然后返回應(yīng)答。如果在第一階段內(nèi)有任何一個數(shù)據(jù)庫的操作發(fā)生了錯誤，或者事務(wù)管理器收不到某個數(shù)據(jù)庫的回應(yīng)，則認為事務(wù)失敗，回撤所有數(shù)據(jù)庫的事務(wù)。數(shù)據(jù)庫服務(wù)器收不到第二階段的確認提交請求，也會把"可以提交"的事務(wù)回撤。
XA規(guī)范對兩階段提交協(xié)議有2點優(yōu)化：
Protocol Optimisations
· Read-only
An RM can respond to the TM’s prepare request by asserting that the RM was not asked to update shared resources in this transaction branch. This response concludes the RM’s involvement in the transaction; the Phase 2 dialogue between the TM and this RM does not occur. The TM need not stably record, in its list of participating RMs, an RM that asserts a read-only role in the global transaction.
However, if the RM returns the read-only optimisation before all work on the global transaction is prepared, global serialisability1 cannot be guaranteed. This is because the RM may release transaction context, such as read locks, before all application activity for that global transaction is finished.
One-phase Commit
A TM can use one-phase commit if it knows that there is only one RM anywhere in the DTP system that is making changes to shared resources. In this optimisation, the TM makes its Phase 2 commit request without having made a Phase 1 prepare request. Since the RM decides the outcome of the transaction branch and forgets about the transaction branch before returning to the TM, there is no need for the TM to record stably these global transactions and, in some failure cases, the TM may not know the outcome.
只讀斷言
在Phase 1中，RM可以斷言“我這邊不涉及數(shù)據(jù)增刪改”來答復(fù)TM的prepare請求，從而讓這個RM脫離當(dāng)前的全局事務(wù)，從而免去了Phase 2。
這種優(yōu)化發(fā)生在其他RM都完成prepare之前的話，使用了只讀斷言的RM早于AP其他動作（比如說這個RM返回那些只讀數(shù)據(jù)給AP）前，就釋放了相關(guān)數(shù)據(jù)的上下文（比如讀鎖之類的），這時候其他全局事務(wù)或者本地事務(wù)就有機會去改變這些數(shù)據(jù)，結(jié)果就是無法保障整個系統(tǒng)的可序列化特性——通俗點說那就會有臟讀的風(fēng)險。
一階段提交
如果需要增刪改的數(shù)據(jù)都在同一個RM上，TM可以使用一階段提交——跳過兩階段提交中的Phase 1，直接執(zhí)行Phase 2。
這種優(yōu)化的本質(zhì)是跳過Phase 1，RM自行決定了事務(wù)分支的結(jié)果，并且在答復(fù)TM前就清除掉事務(wù)分支信息。對于這種優(yōu)化的情況，TM實際上也沒有必要去可靠的記錄全局事務(wù)的信息，在一些異常的場景下，此時TM可能不知道事務(wù)分支的執(zhí)行結(jié)果。
4.2.3 兩階段提交協(xié)議(2PC)存在的問題
二階段提交看起來確實能夠提供原子性的操作，但是不幸的是，二階段提交還是有幾個缺點的：
1、同步阻塞問題。兩階段提交方案下全局事務(wù)的ACID特性，是依賴于RM的。例如mysql5.7官方文檔關(guān)于對XA分布式事務(wù)的支持有以下介紹：
https://dev.mysql.com/doc/refman/5.7/en/xa.html
A global transaction involves several actions that are transactional in themselves, but that all must either complete successfully as a group, or all be rolled back as a group. In essence, this extends ACID properties “up a level” so that multiple ACID transactions can be executed in concert as components of a global operation that also has ACID properties. (As with nondistributed transactions, SERIALIZABLE may be preferred if your applications are sensitive to read phenomena. REPEATABLE READ may not be sufficient for distributed transactions.)
大致含義是說，一個全局事務(wù)內(nèi)部包含了多個獨立的事務(wù)分支，這一組事務(wù)分支要不都成功，要不都失敗。各個事務(wù)分支的ACID特性共同構(gòu)成了全局事務(wù)的ACID特性。也就是將單個事務(wù)分支的支持的ACID特性提升一個層次(up a level)到分布式事務(wù)的范疇。括號中的內(nèi)容的意思是： 即使在非分布事務(wù)中(即本地事務(wù))，如果對操作讀很敏感，我們也需要將事務(wù)隔離級別設(shè)置為SERIALIZABLE。而對于分布式事務(wù)來說，更是如此，可重復(fù)讀隔離級別不足以保證分布式事務(wù)一致性。也就是說，如果我們使用mysql來支持XA分布式事務(wù)的話，那么最好將事務(wù)隔離級別設(shè)置為SERIALIZABLE。 地球人都知道，SERIALIZABLE(串行化)是四個事務(wù)隔離級別中最高的一個級別，也是執(zhí)行效率最低的一個級別。
2、單點故障。由于協(xié)調(diào)者的重要性，一旦協(xié)調(diào)者TM發(fā)生故障。參與者RM會一直阻塞下去。尤其在第二階段，協(xié)調(diào)者發(fā)生故障，那么所有的參與者還都處于鎖定事務(wù)資源的狀態(tài)中，而無法繼續(xù)完成事務(wù)操作。（如果是協(xié)調(diào)者掛掉，可以重新選舉一個協(xié)調(diào)者，但是無法解決因為協(xié)調(diào)者宕機導(dǎo)致的參與者處于阻塞狀態(tài)的問題）
3、數(shù)據(jù)不一致。在二階段提交的階段二中，當(dāng)協(xié)調(diào)者向參與者發(fā)送commit請求之后，發(fā)生了局部網(wǎng)絡(luò)異?；蛘咴诎l(fā)送commit請求過程中協(xié)調(diào)者發(fā)生了故障，這回導(dǎo)致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之后就會執(zhí)行commit操作。但是其他部分未接到commit請求的機器則無法執(zhí)行事務(wù)提交。于是整個分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)不一致性的現(xiàn)象。
由于二階段提交存在著諸如同步阻塞、單點問題等缺陷，所以，研究者們在二階段提交的基礎(chǔ)上做了改進，提出了三階段提交。
5 三階段提交協(xié)議(Three-phase commit)
三階段提交（3PC)，是二階段提交（2PC）的改進版本。參考維基百科：https://en.wikipedia.org/wiki/Three-phase_commit_protocol
與兩階段提交不同的是，三階段提交有兩個改動點。
1、引入超時機制。同時在協(xié)調(diào)者和參與者中都引入超時機制。2、在第一階段和第二階段中插入一個準(zhǔn)備階段。保證了在最后提交階段之前各參與節(jié)點的狀態(tài)是一致的。也就是說，除了引入超時機制之外，3PC把2PC的準(zhǔn)備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。
CanCommit階段
3PC的CanCommit階段其實和2PC的準(zhǔn)備階段很像。協(xié)調(diào)者向參與者發(fā)送commit請求，參與者如果可以提交就返回Yes響應(yīng)，否則返回No響應(yīng)。1.事務(wù)詢問 協(xié)調(diào)者向參與者發(fā)送CanCommit請求。詢問是否可以執(zhí)行事務(wù)提交操作。然后開始等待參與者的響應(yīng)。2.響應(yīng)反饋 參與者接到CanCommit請求之后，正常情況下，如果其自身認為可以順利執(zhí)行事務(wù)，則返回Yes響應(yīng)，并進入預(yù)備狀態(tài)。否則反饋No
PreCommit階段
協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來決定是否可以記性事務(wù)的PreCommit操作。根據(jù)響應(yīng)情況，有以下兩種可能。假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes響應(yīng)，那么就會執(zhí)行事務(wù)的預(yù)執(zhí)行。1.發(fā)送預(yù)提交請求 協(xié)調(diào)者向參與者發(fā)送PreCommit請求，并進入Prepared階段。 2.事務(wù)預(yù)提交 參與者接收到PreCommit請求后，會執(zhí)行事務(wù)操作，并將undo和redo信息記錄到事務(wù)日志中。3.響應(yīng)反饋 如果參與者成功的執(zhí)行了事務(wù)操作，則返回ACK響應(yīng)，同時開始等待最終指令。
假如有任何一個參與者向協(xié)調(diào)者發(fā)送了No響應(yīng)，或者等待超時之后，協(xié)調(diào)者都沒有接到參與者的響應(yīng)，那么就執(zhí)行事務(wù)的中斷。
1.發(fā)送中斷請求 協(xié)調(diào)者向所有參與者發(fā)送abort請求。2.中斷事務(wù) 參與者收到來自協(xié)調(diào)者的abort請求之后（或超時之后，仍未收到協(xié)調(diào)者的請求），執(zhí)行事務(wù)的中斷。
doCommit階段
該階段進行真正的事務(wù)提交，也可以分為以下兩種情況。Case 1：執(zhí)行提交1.發(fā)送提交請求 協(xié)調(diào)接收到參與者發(fā)送的ACK響應(yīng)，那么他將從預(yù)提交狀態(tài)進入到提交狀態(tài)。并向所有參與者發(fā)送doCommit請求。2.事務(wù)提交 參與者接收到doCommit請求之后，執(zhí)行正式的事務(wù)提交。并在完成事務(wù)提交之后釋放所有事務(wù)資源。3.響應(yīng)反饋 事務(wù)提交完之后，向協(xié)調(diào)者發(fā)送Ack響應(yīng)。4.完成事務(wù) 協(xié)調(diào)者接收到所有參與者的ack響應(yīng)之后，完成事務(wù)。
Case 2：中斷事務(wù) 協(xié)調(diào)者沒有接收到參與者發(fā)送的ACK響應(yīng)（可能是接受者發(fā)送的不是ACK響應(yīng)，也可能響應(yīng)超時），那么就會執(zhí)行中斷事務(wù)。
1.發(fā)送中斷請求 協(xié)調(diào)者向所有參與者發(fā)送abort請求2.事務(wù)回滾 參與者接收到abort請求之后，利用其在階段二記錄的undo信息來執(zhí)行事務(wù)的回滾操作，并在完成回滾之后釋放所有的事務(wù)資源。3.反饋結(jié)果 參與者完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ACK消息4.中斷事務(wù) 協(xié)調(diào)者接收到參與者反饋的ACK消息之后，執(zhí)行事務(wù)的中斷。 在doCommit階段，如果參與者無法及時接收到來自協(xié)調(diào)者的doCommit或者rebort請求時，會在等待超時之后，會繼續(xù)進行事務(wù)的提交。（其實這個應(yīng)該是基于概率來決定的，當(dāng)進入第三階段時，說明參與者在第二階段已經(jīng)收到了PreCommit請求，那么協(xié)調(diào)者產(chǎn)生PreCommit請求的前提條件是他在第二階段開始之前，收到所有參與者的CanCommit響應(yīng)都是Yes。（一旦參與者收到了PreCommit，意味他知道大家其實都同意修改了）所以，一句話概括就是，當(dāng)進入第三階段時，由于網(wǎng)絡(luò)超時等原因，雖然參與者沒有收到commit或者abort響應(yīng)，但是他有理由相信：成功提交的幾率很大。 ）
小結(jié)：2PC與3PC的區(qū)別
相對于2PC，3PC主要解決的單點故障問題，并減少阻塞，因為一旦參與者無法及時收到來自協(xié)調(diào)者的信息之后，他會默認執(zhí)行commit。而不會一直持有事務(wù)資源并處于阻塞狀態(tài)。但是這種機制也會導(dǎo)致數(shù)據(jù)一致性問題，因為，由于網(wǎng)絡(luò)原因，協(xié)調(diào)者發(fā)送的abort響應(yīng)沒有及時被參與者接收到，那么參與者在等待超時之后執(zhí)行了commit操作。這樣就和其他接到abort命令并執(zhí)行回滾的參與者之間存在數(shù)據(jù)不一致的情況。了解了2PC和3PC之后，我們可以發(fā)現(xiàn)，無論是二階段提交還是三階段提交都無法徹底解決分布式的一致性問題。Google Chubby的作者Mike Burrows說過， there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. 意即世上只有一種一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。后面的文章會介紹這個公認為難于理解但是行之有效的Paxos算法。
6 BASE理論與柔性事務(wù)
6.1 經(jīng)典的分布式系統(tǒng)理論-CAP
2000年7月，加州大學(xué)伯克利分校的Eric Brewer教授在ACM PODC會議上提出CAP猜想。Brewer認為在設(shè)計一個大規(guī)模的分布式系統(tǒng)時會遇到三個特性：一致性（consistency）、可用性（Availability）、分區(qū)容錯（partition-tolerance），而一個分布式系統(tǒng)最多只能滿足其中的2項。2年后，麻省理工學(xué)院的Seth Gilbert和Nancy Lynch從理論上證明了CAP。之后，CAP理論正式成為分布式計算領(lǐng)域的公認定理。
一致性
一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客戶端完成后，所有節(jié)點在同一時間的數(shù)據(jù)完全一致，不能存在中間狀態(tài)。例如對于電商系統(tǒng)用戶下單操作，庫存減少、用戶資金賬戶扣減、積分增加等操作必須在用戶下單操作完成后必須是一致的。不能出現(xiàn)類似于庫存已經(jīng)減少，而用戶資金賬戶尚未扣減，積分也未增加的情況。如果出現(xiàn)了這種情況，那么就認為是不一致的。
關(guān)于一致性，如果的確能像上面描述的那樣時刻保證客戶端看到的數(shù)據(jù)都是一致的，那么稱之為強一致性。如果允許存在中間狀態(tài)，只要求經(jīng)過一段時間后，數(shù)據(jù)最終是一致的，則稱之為最終一致性。此外，如果允許存在部分?jǐn)?shù)據(jù)不一致，那么就稱之為弱一致性。
可用性
可用性是指系統(tǒng)提供的服務(wù)必須一直處于可用的狀態(tài)，對于用戶的每一個操作請求總是能夠在有限的時間內(nèi)返回結(jié)果?！坝邢薜臅r間內(nèi)”是指，對于用戶的一個操作請求，系統(tǒng)必須能夠在指定的時間內(nèi)返回對應(yīng)的處理結(jié)果，如果超過了這個時間范圍，那么系統(tǒng)就被認為是不可用的。試想，如果一個下單操作，為了保證分布式事務(wù)的一致性，需要10分鐘才能處理完，那么用戶顯然是無法忍受的?！胺祷亟Y(jié)果”是可用性的另一個非常重要的指標(biāo)，它要求系統(tǒng)在完成對用戶請求的處理后，返回一個正常的響應(yīng)結(jié)果，不論這個結(jié)果是成功還是失敗。
分區(qū)容錯性
分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務(wù)，除非是整個網(wǎng)絡(luò)環(huán)境都發(fā)生了故障。
小結(jié)： 既然一個分布式系統(tǒng)無法同時滿足一致性、可用性、分區(qū)容錯性三個特點，我們就需要拋棄一個，需要明確的一點是，對于一個分布式系統(tǒng)而言，分區(qū)容錯性是一個最基本的要求。因為既然是一個分布式系統(tǒng)，那么分布式系統(tǒng)中的組件必然需要被部署到不同的節(jié)點，否則也就無所謂分布式系統(tǒng)了。而對于分布式系統(tǒng)而言，網(wǎng)絡(luò)問題又是一個必定會出現(xiàn)的異常情況，因此分區(qū)容錯性也就成為了一個分布式系統(tǒng)必然需要面對和解決的問題。因此系統(tǒng)架構(gòu)師往往需要把精力花在如何根據(jù)業(yè)務(wù)特點在C（一致性）和A（可用性）之間尋求平衡。而前面我們提到的X/Open XA 兩階段提交協(xié)議的分布式事務(wù)方案，強調(diào)的就是一致性；由于可用性較低，實際應(yīng)用的并不多。而基于BASE理論的柔性事務(wù)，強調(diào)的是可用性，目前大行其道，大部分互聯(lián)網(wǎng)公司采可能會優(yōu)先采用這種方案。
6.2 BASE理論
eBay的架構(gòu)師Dan Pritchett源于對大規(guī)模分布式系統(tǒng)的實踐總結(jié)，在ACM上發(fā)表文章提出BASE理論。文章鏈接：https://queue.acm.org/detail.cfm?id=1394128BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency，CAP的一致性就是強一致性），但應(yīng)用可以采用適合的方式達到最終一致性（Eventual Consitency）。
BASE是Basically Available（基本可用）、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）三個短語的縮寫。
1. 基本可用（Basically Available） 指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時候，允許損失部分可用性。2. 軟狀態(tài)（ Soft State） 指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性。3. 最終一致（ Eventual Consistency） 強調(diào)的是所有的數(shù)據(jù)更新操作，在經(jīng)過一段時間的同步之后，最終都能夠達到一個一致的狀態(tài)。因此，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達到一致，而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性。BASE理論面向的是大型高可用可擴展的分布式系統(tǒng)，和傳統(tǒng)的事物ACID特性是相反的。它完全不同于ACID的強一致性模型，而是通過犧牲強一致性來獲得可用性，并允許數(shù)據(jù)在一段時間內(nèi)是不一致的，但最終達到一致狀態(tài)。但同時，在實際的分布式場景中，不同業(yè)務(wù)單元和組件對數(shù)據(jù)一致性的要求是不同的，因此在具體的分布式系統(tǒng)架構(gòu)設(shè)計過程中，ACID特性和BASE理論往往又會結(jié)合在一起。
6.3 典型的柔性事務(wù)方案
最大努力通知（非可靠消息、定期校對） 可靠消息最終一致性（異步確保型） TCC（兩階段型、補償型）
來源：http://www.tianshouzhi.com/api/tutorials/distributed_transaction
