前面的文章中，我們介紹了分布式系統中的CAP理論和BASE理論，本文會就分布式事務的實作方案之一：兩階段提交(2PC)進行介紹，2PC是一個非常經典的強一致、中心化的原子提交協議，中心化是指協議中有兩類節點：一個是中心化協調者節點（coordinator）和N個參與者節點（partcipant），

2PC

一致性概念

一致性，是指對每個節點一個資料的更新，整個集群都知道更新，并且是一致的，假設一個具有N個節點的分布式系統，當其滿足以下條件時，我們說這個系統滿足一致性：

• 全認同: 所有N個節點都認同一個結果；
• 值合法: 該結果必須由N個節點中的過半節點提出；
• 可結束: 決議程序在一定時間內結束，不會無休止地進行下去；

一致性的挑戰

訊息傳遞異步無序: 現實網路不是一個可靠的信道，存在訊息延時、丟失，節點間訊息傳遞做不到同步有序：

• 節點宕機: 節點持續宕機，不會恢復；
• 節點宕機恢復: 節點宕機一段時間后恢復，在分布式系統中最常見；
• 網路分化: 網路鏈路出現問題，將N個節點隔離成多個部分；
• 拜占庭將軍問題: 節點或宕機或邏輯失敗，甚至不按套路出牌拋出干擾決議的資訊，

2PC原理

2PC(tow phase commit)兩階段提交，所謂的兩個階段是指：

1. 第一階段：準備階段(投票階段)
2. 第二階段：提交階段（執行階段），

我們將提議的節點稱為協調者(coordinator)，其他參與決議節點稱為參與者(participants, 或cohorts)，

2PC第一階段

2PC的第一階段是投票環節，投票由協調者節點發起，可以進一步細分為以下步驟：

1. 事務詢問：協調者向所有的參與者發送事務預處理請求，稱之為Prepare，并開始等待各參與者的回應，
2. 執行本地事務：各個參與者節點執行本地事務操作,但在執行完成后并不會真正提交資料庫本地事務，而是先向協調者報告說：“我這邊可以處理了/我這邊不能處理”，
3. 各參與者向協調者反饋事務詢問的回應：如果參與者成功執行了事務操作，那么就反饋給協調者Yes回應，表示事務可以執行，如果沒有參與者成功執行事務，那么就反饋給協調者No回應，表示事務不可以執行，

第一階段執行完后，會有兩種可能，1、所有都回傳Yes. 2、有一個或者多個回傳No，

2PC第二階段：正常提交

如果第一階段所有的參與者都回傳Yes，那么我們就可以繼續執行2PC第二階段的正常提交步驟：

1. 協調者節點通知所有的參與者Commit事務請求；
2. 參與者收到Commit請求之后，就會正式執行本地事務Commit操作，并在完成提交之后釋放整個事務執行期間占用的事務資源，

2PC第二階段：例外回滾

如果任何一個參與者向協調者反饋了No回應，或者等待超時之后，協調者尚未收到所有參與者的反饋回應，那么我們就需要執行2PC第二階段的回滾操作：

1. 協調者節點通知所有的參與者Rollback請求；
2. 參與者收到Rollback請求之后，就會正式執行本地事務Rollback操作，并在完成提交之后釋放整個事務執行期間占用的事務資源，

2PC存在的問題

通過上面的演示，很容易想到2pc所帶來的缺陷：

• 性能問題：無論是在第一階段的程序中,還是在第二階段,所有的參與者資源和協調者資源都是被鎖住的,只有當所有節點準備完畢，事務 協調者 才會通知進行全域提交，參與者進行本地事務提交后才會釋放資源，這樣的程序會比較漫長，對性能影響比較大，
• 單節點故障：由于協調者的重要性，一旦協調者發生故障，參與者會一直阻塞下去，尤其在第二階段，協調者發生故障，那么所有的參與者還都處于鎖定事務資源的狀態中，而無法繼續完成事務操作，（雖然協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者宕機導致的參與者處于阻塞狀態的問題），

2PC節點故障的情況

協調者正常,參與者宕機

由于協調者無法收集到所有參與者的反饋，會陷入阻塞情況，解決方案:引入超時機制,如果協調者在超過指定的時間還沒有收到參與者的反饋,事務就失敗,向所有節點發送終止事務請求，

協調者宕機,參與者正常

?無論處于哪個階段，由于協調者宕機，無法發送提交請求，所有處于執行了操作但是未提交狀態的參與者都會陷入阻塞情況，解決方案:引入協調者備份,同時協調者需記錄操作日志.當檢測到協調者宕機一段時間后，協調者備份取代協調者，并讀取操作日志，向所有參與者詢問狀態，

協調者和參與者都宕機

如果發生在第一階段： 因為第一階段，所有參與者都沒有真正執行commit，所以只需重新在剩余的參與者中重新選出一個協調者，新的協調者在重新執行第一階段和第二階段就可以了，

發生在第二階段并且掛了的參與者在掛掉之前沒有收到協調者的指令：也就是上面的第2步掛了，這是可能協調者還沒有發送第2步就掛了，這種情形下，新的協調者重新執行第一階段和第二階段操作，

發生在第二階段并且有部分參與者已經執行完commit操作：就好比這里訂單服務A和支付服務B都收到協調者發送的commit資訊，開始真正執行本地事務commit,但突發情況，A commit成功，B掛了，這個時候目前來講資料是不一致的，雖然這個時候可以再通過手段讓他和協調者通信，再想辦法把資料搞成一致的，但是，這段時間內他的資料狀態已經是不一致的了！ 2PC無法解決這個問題，

mysql對XA事務的支持

MySQL 從5.0.3開始支持XA分布式事務，且只有InnoDB存盤引擎支持，MySQL Connector/J 從5.0.0版本之后開始直接提供對XA的支持，

需要注意的是， 在DTP模型中，mysql屬于資源管理器(RM)，而一個完整的分布式事務中，一般會存在多個RM，由事務管理器TM來統一進行協調，因此，這里所說的mysql對XA分布式事務的支持，一般指的是單臺mysql實體如何執行自己的事務分支，

XA {START|BEGIN} xid [JOIN|RESUME]   //開啟XA事務，如果使用的是XA START而不是XA BEGIN，那么不支持[JOIN|RESUME]，xid是一個唯一值，表示事務分支識別符號
XA END xid [SUSPEND [FOR MIGRATE]]   //結束一個XA事務，不支持[SUSPEND [FOR MIGRATE]]
XA PREPARE xid 準備提交
XA COMMIT xid [ONE PHASE] //提交，如果使用了ONE PHASE，則表示使用一階段提交，兩階段提交協議中，如果只有一個RM參與，那么可以優化為一階段提交
XA ROLLBACK xid  //回滾
XA RECOVER [CONVERT XID]  //列出所有處于PREPARE階段的XA事務

JTA的實作

Java事務API（JTA：Java Transaction API）和它的同胞Java事務服務（JTS：Java Transaction Service），為J2EE平臺提供了分布式事務服務（distributed transaction）的能力， 某種程度上，可以認為JTA規范是XA規范的Java版，其把XA規范中規定的DTP模型互動介面抽象成Java介面中的方法，并規定每個方法要實作什么樣的功能，在DTP模型中，規定了模型的五個組成元素：應用程式(Application)、資源管理器(Resource Manager)、事務管理器(Transaction Manager)、通信資源管理器(Communication Resource Manager)、 通信協議(Communication Protocol)，而在JTA規范中，模型中又多了一個元素Application Server，如下所示：

下面介紹一下在JTA規范中，模型中各個組件的作用：

事務管理器(transaction manager)：

處于圖中最為核心的位置，其他的事務參與者都是與事務管理器進行互動，事務了管理器提供事務宣告，事務資源管理，同步，事務背景關系傳播等功能，JTA規范定義了事務管理器與其他事務參與者互動的介面，而JTS規范定義了事務管理器的實作要求，因此我們看到事務管理器底層是基于JTS的，

應用服務器(application server)：

顧名思義，是應用程式運行的容器，JTA規范規定，事務管理器的功能應該由application server提供，如上圖中的EJB Server，一些常見的其他web容器，如：jboss、weblogic、websphere等，都可以作為application server，這些web容器都實作了JTA規范，特別需要注意的是，并不是所有的web容器都實作了JTA規范，如tomcat并沒有實作JTA規范，因此并不能提供事務管理器的功能，

應用程式(application)：

簡單來說，就是我們自己撰寫的應用，部署到了實作了JTA規范的application server中，之后我們就可以我們JTA規范中定義的UserTransaction類來宣告一個分布式事務，通常情況下，application server為了簡化開發者的作業量，并不一定要求開發者使用UserTransaction來宣告一個事務，開發者可以在需要使用分布式事務的方法上添加一個注解，就像spring的宣告式事務一樣，來宣告一個分布式事務，

特別需要注意的是，JTA規范規定事務管理器的功能由application server提供，但是如果我們的應用不是一個web應用，而是一個本地應用，不需要被部署到application server中，無法使用application server提供的事務管理器功能，又或者我們使用的web容器并沒有事務管理器的功能，如tomcat，對于這些情況，我們可以直接使用一些第三方的事務管理器類別庫，如JOTM和Atomikos，將事務管理器直接整合進應用中，不再依賴于application server，

資源管理器(resource manager)：

理論上任何可以存盤資料的軟體，都可以認為是資源管理器RM，最典型的RM就是關系型資料庫了，如mysql，另外一種比較常見的資源管理器是訊息中間件，如ActiveMQ、RabbitMQ等， 這些都是真正的資源管理器，

事實上，將資源管理器(resource manager)稱為資源配接器(resource adapter)似乎更為合適，因為在java程式中，我們都是通過client來于RM進行互動的，例如：我們通過mysql-connector-java-x.x.x.jar驅動包，獲取Conn、執行sql，與mysql服務端進行通信；通過ActiveMQ、RabbitMQ等的客戶端，來發送訊息等，

正常情況下，一個資料庫驅動供應商只需要實作JDBC規范即可，一個訊息中間件供應商只需要實作JMS規范即可， 而引入了分布式事務的概念后，DB、MQ等在DTP模型中的作用都是RM，二者是等價的，需要由TM統一進行協調，

為此，JTA規范定義了一個XAResource介面，其定義RM必須要提供給TM呼叫的一些方法，之后，不管這個RM是DB，還是MQ，TM并不關心，因為其操作的是XAResource介面，而其他規范(如JDBC、JMS)的實作者，同時也對此介面進行實作，如MysqlXAConnection，就實作了XAResource介面，

通信資源管理器(Communication Resource Manager)：

這個是DTP模型中就已經存在的概念，對于需要跨應用的分布式事務，事務管理器彼此之間需要通信，這是就是通過CRM這個組件來完成的，JTA規范中，規定CRM需要實作JTS規范定義的介面，

下圖更加直觀的演示了JTA規范中各個模型組件之間是如何互動的：

互動情況如下：

1. application運行在application server中；
2. application 需要訪問3個資源管理器(RM)上資源：1個MQ資源和2個DB資源；
3. 由于這些資源服務器是獨立部署的，如果需要同時進行更新資料的話并保證一致性的話，則需要使用到分布式事務，需要有一個事務管理器來統一協調；
4. Application Server提供了事務管理器的功能；
5. 作為資源管理器的DB和MQ的客戶端驅動包，都實作了XAResource介面，以供事務管理器呼叫，

參考文章

mysql 對XA事務的支持
3.0 JTA規范

我是御狐神，歡迎大家關注我的微信公眾號:wzm2zsd

本文最先發布至微信公眾號，著作權所有，禁止轉載！

標籤：Java

上一篇：jsoup教程

下一篇：Spring Boot 獲取 bean 的 3 種方式！還有誰不會？？