分散式事務(二)之兩階段提交

御狐神發表於2021-10-21

前面的文章中,我們介紹了分散式系統中的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第一階段

2PC第二階段:正常提交

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

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

2PC正常提交

2PC第二階段:異常回滾

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

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

2PC正常提交

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的支援。

mysql-support-xa-2021-10-21-18-11-43

需要注意的是, 在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事務

J他的實現

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實現

下面介紹一下在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規範中各個模型元件之間是如何互動的:

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

qrcode_for_gh_83670e17bbd7_344-2021-09-04-10-55-16

本文最先發布至微信公眾號,版權所有,禁止轉載!

相關文章