本課時(shí)我們來(lái)討論 MySQL 的 XA 規(guī)范有哪些應(yīng)用相關(guān)的內(nèi)容。

MySQL 為我們提供了分布式事務(wù)解決方案，在前面的內(nèi)容中提到過 binlog 的同步，其實(shí)是 MySQL XA 規(guī)范的一個(gè)應(yīng)用，那么 XA 規(guī)范是如何定義的，具體又是如何應(yīng)用的呢？

今天我們一起來(lái)看一下 XA 規(guī)范相關(guān)的內(nèi)容。

MySQL 有哪些一致性日志

問你一個(gè)問題，如果 MySQL 數(shù)據(jù)庫(kù)斷電了，未提交的事務(wù)怎么辦？

答案是 依靠日志，因?yàn)樵趫?zhí)行一個(gè)操作之前，數(shù)據(jù)庫(kù)會(huì)首先把這個(gè)操作的內(nèi)容寫入到文件系統(tǒng)日志里記錄起來(lái)，然后再進(jìn)行操作。當(dāng)宕機(jī)或者斷電的時(shí)候，即使操作并沒有執(zhí)行完，但是日志在操作前就已經(jīng)寫好了，我們?nèi)匀豢梢愿鶕?jù)日志的內(nèi)容來(lái)進(jìn)行恢復(fù)。

MySQL InnoDB 引擎中和一致性相關(guān)的有 重做日志（redo log）、 回滾日志（undo log）和 二進(jìn)制日志（binlog）。

redo 日志，每當(dāng)有操作執(zhí)行前，在數(shù)據(jù)真正更改前，會(huì)先把相關(guān)操作寫入 redo 日志。這樣當(dāng)斷電，或者發(fā)生一些意外，導(dǎo)致后續(xù)任務(wù)無(wú)法完成時(shí)，待系統(tǒng)恢復(fù)后，可以繼續(xù)完成這些更改。

和 redo 日志對(duì)應(yīng)的 undo 日志，也叫 撤消日志，記錄事務(wù)開始前數(shù)據(jù)的狀態(tài)，當(dāng)一些更改在執(zhí)行一半時(shí)，發(fā)生意外而無(wú)法完成，就可以根據(jù)撤消日志恢復(fù)到更改之前的狀態(tài)。舉個(gè)例子，事務(wù) T1 更新數(shù)據(jù) X，對(duì) X 執(zhí)行 Update 操作，從 10 更新到 20，對(duì)應(yīng)的 Redo 日志為 <T1, X, 20>，Undo 日志為 <T1, X, 10>。

binlog 日志 是 MySQL sever 層維護(hù)的一種二進(jìn)制日志，是 MySQL 最重要的日志之一，它記錄了所有的 DDL 和 DML 語(yǔ)句，除了數(shù)據(jù)查詢語(yǔ)句 select、show 等，還包含語(yǔ)句所執(zhí)行的消耗時(shí)間。

binlog 與 InnoDB 引擎中的 redo/undo log 不同，binlog 的主要目的是 復(fù)制和恢復(fù)，用來(lái)記錄對(duì) MySQL 數(shù)據(jù)更新或潛在發(fā)生更新的 SQL 語(yǔ)句，并以事務(wù)日志的形式保存在磁盤中。binlog 主要應(yīng)用在 MySQL 的主從復(fù)制過程中，MySQL 集群在 Master 端開啟 binlog，Master 把它的二進(jìn)制日志傳遞給 slaves 節(jié)點(diǎn)，再?gòu)墓?jié)點(diǎn)回放來(lái)達(dá)到 master-slave 數(shù)據(jù)一致的目的。

你可以連接到 MySQL 服務(wù)器，使用下面的命令查看真實(shí)的 binlog 數(shù)據(jù)：

//查看binlog文件的內(nèi)容show binlog events;//查看指定binlog文件的內(nèi)容show binlog events in 'MySQL-bin.000001';//查看正在寫入的binlog文件show master status\G //獲取binlog文件列表show binary logs;

XA 規(guī)范是如何定義的

XA 是由 X/Open 組織提出的分布式事務(wù)規(guī)范，XA 規(guī)范主要定義了事務(wù)協(xié)調(diào)者（Transaction Manager）和資源管理器（Resource Manager）之間的接口。

事務(wù)協(xié)調(diào)者（Transaction Manager），因?yàn)?XA 事務(wù)是基于兩階段提交協(xié)議的，所以需要有一個(gè)協(xié)調(diào)者，來(lái)保證所有的事務(wù)參與者都完成了準(zhǔn)備工作，也就是 2PC 的第一階段。如果事務(wù)協(xié)調(diào)者收到所有參與者都準(zhǔn)備好的消息，就會(huì)通知所有的事務(wù)都可以提交，也就是 2PC 的第二階段。

在前面的內(nèi)容中我們提到過，之所以需要引入事務(wù)協(xié)調(diào)者，是因?yàn)樵诜植际较到y(tǒng)中，兩臺(tái)機(jī)器理論上無(wú)法達(dá)到一致的狀態(tài)，需要引入一個(gè)單點(diǎn)進(jìn)行協(xié)調(diào)。協(xié)調(diào)者，也就是事務(wù)管理器控制著全局事務(wù)，管理事務(wù)生命周期，并協(xié)調(diào)資源。

資源管理器（Resource Manager），負(fù)責(zé)控制和管理實(shí)際資源，比如數(shù)據(jù)庫(kù)或 JMS 隊(duì)列。

目前，主流數(shù)據(jù)庫(kù)都提供了對(duì) XA 的支持，在 JMS 規(guī)范中，即 Java 消息服務(wù)（Java Message Service）中，也基于 XA 定義了對(duì)事務(wù)的支持。

XA 事務(wù)的執(zhí)行流程

XA 事務(wù)是兩階段提交的一種實(shí)現(xiàn)方式，根據(jù) 2PC 的規(guī)范，XA 將一次事務(wù)分割成了兩個(gè)階段，即 Prepare 和 Commit 階段。

Prepare 階段，TM 向所有 RM 發(fā)送 prepare 指令，RM 接受到指令后，執(zhí)行數(shù)據(jù)修改和日志記錄等操作，然后返回可以提交或者不提交的消息給 TM。如果事務(wù)協(xié)調(diào)者 TM 收到所有參與者都準(zhǔn)備好的消息，會(huì)通知所有的事務(wù)提交，然后進(jìn)入第二階段。

Commit 階段，TM 接受到所有 RM 的 prepare 結(jié)果，如果有 RM 返回是不可提交或者超時(shí)，那么向所有 RM 發(fā)送 Rollback 命令；如果所有 RM 都返回可以提交，那么向所有 RM 發(fā)送 Commit 命令，完成一次事務(wù)操作。

MySQL 如何實(shí)現(xiàn) XA 規(guī)范

MySQL 中 XA 事務(wù)有兩種情況，內(nèi)部 XA 和外部 XA，其區(qū)別是事務(wù)發(fā)生在 MySQL 服務(wù)器單機(jī)上，還是發(fā)生在多個(gè)外部節(jié)點(diǎn)間上。

內(nèi)部 XA

在 MySQL 的 InnoDB 存儲(chǔ)引擎中，開啟 binlog 的情況下，MySQL 會(huì)同時(shí)維護(hù) binlog 日志與 InnoDB 的 redo log，為了保證這兩個(gè)日志的一致性，MySQL 使用了 XA 事務(wù)，由于是在 MySQL 單機(jī)上工作，所以被稱為 內(nèi)部 XA。

內(nèi)部 XA 事務(wù)由 binlog 作為協(xié)調(diào)者，在事務(wù)提交時(shí)，則需要將提交信息寫入二進(jìn)制日志，也就是說(shuō)，binlog 的參與者是 MySQL 本身。

外部 XA

外部 XA 就是典型的分布式事務(wù)，MySQL 支持 XA START/END/PREPARE/Commit 這些 SQL 語(yǔ)句，通過使用這些命令，可以完成分布式事務(wù)。

你也可以查看 MySQL 官方文檔，了解更多的 XA 命令。

MySQL 外部 XA 主要應(yīng)用在數(shù)據(jù)庫(kù)代理層，實(shí)現(xiàn)對(duì) MySQL 數(shù)據(jù)庫(kù)的分布式事務(wù)支持，例如開源的數(shù)據(jù)庫(kù)中間層，比如淘寶的 TDDL、阿里巴巴 B2B 的 Cobar 等。外部 XA 一般是針對(duì)跨多 MySQL 實(shí)例的分布式事務(wù)，需要應(yīng)用層作為協(xié)調(diào)者，比如我們?cè)趯憳I(yè)務(wù)代碼，在代碼中決定提交還是回滾，并且在崩潰時(shí)進(jìn)行恢復(fù)。

Binlog 中的 Xid

當(dāng)事務(wù)提交時(shí)，在 binlog 依賴的內(nèi)部 XA 中，額外添加了 Xid 結(jié)構(gòu)，binlog 有多種數(shù)據(jù)類型，包括以下三種：

• statement 格式，記錄為基本語(yǔ)句，包含 Commit

• row 格式，記錄為基于行

• mixed 格式，日志記錄使用混合格式

不論是 statement 還是 row 格式，binlog 都會(huì)添加一個(gè) XID_EVENT 作為事務(wù)的結(jié)束，該事件記錄了事務(wù)的 ID 也就是 Xid，在 MySQL 進(jìn)行崩潰恢復(fù)時(shí)根據(jù) binlog 中提交的情況來(lái)決定如何恢復(fù)。

Binlog 同步過程

下面來(lái)看看 Binlog 下的事務(wù)提交過程，整體過程是先寫 redo log，再寫 binlog，并以 binlog 寫成功為事務(wù)提交成功的標(biāo)志。

當(dāng)有事務(wù)提交時(shí)：

• 第一步，InnoDB 進(jìn)入 Prepare 階段，并且 write/sync redo log，寫 redo log，將事務(wù)的 XID 寫入到 redo 日志中，binlog 不作任何操作；

• 第二步，進(jìn)行 write/sync Binlog，寫 binlog 日志，也會(huì)把 XID 寫入到 Binlog；

• 第三步，調(diào)用 InnoDB 引擎的 Commit 完成事務(wù)的提交，將 Commit 信息寫入到 redo 日志中。

如果是在第一步和第二步失敗，則整個(gè)事務(wù)回滾；如果是在第三步失敗，則 MySQL 在重啟后會(huì)檢查 XID 是否已經(jīng)提交，若沒有提交，也就是事務(wù)需要重新執(zhí)行，就會(huì)在存儲(chǔ)引擎中再執(zhí)行一次提交操作，保障 redo log 和 binlog 數(shù)據(jù)的一致性，防止數(shù)據(jù)丟失。

在實(shí)際執(zhí)行中，還牽扯到操作系統(tǒng)緩存 Buffer 何時(shí)同步到文件系統(tǒng)中，所以 MySQL 支持用戶自定義在 Commit 時(shí)如何將 log buffer 中的日志刷到 log file 中，通過變量 innodb_flush_log_at_trx_Commit 的值來(lái)決定。在 log buffer 中的內(nèi)容稱為 臟日志，感興趣的話可以查詢資料了解下。

總結(jié)

這一課時(shí)介紹了 MySQL 一致性相關(guān)的幾種日志，并分享了 MySQL 的 XA 規(guī)范相關(guān)內(nèi)容，以及內(nèi)外部 XA 事務(wù)如何實(shí)現(xiàn)。