MYSQL 分布式中的XA協議指的是什么

這期內容當中小編將會給大家帶來有關MYSQL 分布式中的XA協議指的是什么，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

有的人認為MYSQL分布式中間件并沒有那么復雜，就是一個通過設置分區鍵進行數據下發的軟件而已，實際上呵呵

首先要說明的是，什么是XA 協議，XA是一種兩階段提交協議，很多數據庫和事務監視器都支持，它通過協調訪問多個關系數據庫的單個事務來確保數據完整性。XA保證在所有參與的數據庫中提交事務更新，或者從所有數據庫中完全回滾，恢復到事務開始之前的狀態。

為了參與XA事務，XA資源必須讓事務管理器知道其自身。一旦登記了XA資源，事務管理器將確保XA資源參與事務，并在事務的生存期內對XA資源進行適當的方法調用。要完成XA事務，所有資源管理器都參與一個兩階段提交(2pc)。XA事務中的提交稱為兩階段提交，因為在提交過程中有兩次傳遞。

在第一輪中，事務管理器詢問每個資源管理器是否在提交事務時遇到任何問題。如果任何資源管理器反對提交事務，則任何一方對XA事務中涉及的任何資源所做的所有工作都必須全部回滾。

事務管理器對每個已征募的XA資源調用rollback()方法。如果沒有資源管理器反對提交，那么第二輪將涉及事務管理器對每個已征募的XA資源實際調用commit()。這個過程保證了可以跨多個資源的事務的ACID(原子性、一致性、隔離性和持久性)屬性。

到這里不拉不拉，你說了老半天，到底這些有什么關系，DBLE 分布式中間數據庫的中間件，就是利用MYSQL 通用的 XA 協議來做的，如果不知道DBLE，那請百度一下。

所以XA 協議對于分庫分庫分表是很重要的一個協議。

下面是XA 協議的一些步驟

1  XA START

2  Some SQL statement

3   XA END 

4   XA Prepare

5   XA Commit or Rollback

下面我們看一下

舉例，如果三個物理數據中的一個數據庫，在中間件下發數據的時候，其中一個進行了重啟，回怎么樣，如果是在 MYSQL 5.6 版本的時候，那很可能就丟數據的情況，上面的話如果不理解的話我們還是捋一捋

1. 中間件已經向分庫1和分庫2，分庫3，上發送完了 xa prepare ‘xid1’語句，并得到了成功的回復

2. 中間件向分庫1，3上發送了 ‘xa commit ‘xid1’語句，并已經成功返回

3. 當 中間件向分庫2上發送 ‘xa commit ‘xid1’時，網絡斷開了，或者分庫2的數據庫實例被kill了

4. 當網絡恢復（這時相關的Session已經退出了）或數據庫實例再啟動后（或切換到備庫），XA prepare了的事務已經回滾了， 當中間件 XA commit ‘xid1’發過來后數據庫實例根本找不到xid1這個xa事務

上面的流程就導致了分布式事務的不一致：分庫1，3提交了事務，分庫2回滾了事務，整個事務提交了一半，回滾了一半。

所以使用MYSQL5.6的同學你要注意了，MYSQL5.6中是沒有 xa prepare 的嚴格的持久化的，當Session斷開，數據庫CRASH等情況下這些事務會被回滾掉，并且一個主庫配了SemiSync的情況下xa prepare了的事務也不會被發送的SLAVE庫，當主庫切換到備庫這些事務也就丟失。

所以安全的使用中間件的情況一定是你使用了MYSQL.5.7 的情況下，分布式的MYSQL 才能有安全的保證。

我們來做一個實驗

然后，機器突然就崩潰了。如果是一般的事務，那一定就消失了。下圖是機器已經重啟了，同時數據也沒有插入。

然后我們在commit 

數據就回來了。通過這樣的方式分布式中間件是可以保證某個物理庫出現問題后，在變得正常后的數據是可以進行恢復的。

XA RECOVER;

xa recover; 是可以看到在prepare 狀態的事務，參見上圖

同時在BINLOG 中也是有相關的XA的記錄，所以就算是切換，也不會導致分布式事務的丟失。

所以，說分布式中間件就是一個通過數據分片鍵進行數據分發誰都可以做的這樣的說法，我只能表達 呵呵 二字。

上述就是小編為大家分享的MYSQL 分布式中的XA協議指的是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。