轉(zhuǎn)載：https://www.cnblogs.com/DataArt/p/10083617.html
1. XA-2PC (two phase commit, 兩階段提交 )
XA是由X/Open組織提出的分布式事務(wù)的規(guī)范(X代表transaction; A代表accordant？)。XA規(guī)范主要定義了(全局)事務(wù)管理器(TM: Transaction Manager)和(局部)資源管理器(RM: Resource Manager)之間的接口。XA為了實(shí)現(xiàn)分布式事務(wù)，將事務(wù)的提交分成了兩個(gè)階段：也就是2PC (tow phase commit)，XA協(xié)議就是通過將事務(wù)的提交分為兩個(gè)階段來實(shí)現(xiàn)分布式事務(wù)。
1.1 prepare 階段：
第一階段，事務(wù)管理器向所有涉及到的數(shù)據(jù)庫服務(wù)器發(fā)出prepare"準(zhǔn)備提交"請(qǐng)求，數(shù)據(jù)庫收到請(qǐng)求后執(zhí)行數(shù)據(jù)修改和日志記錄等處理，處理完成后只是把事務(wù)的狀態(tài)改成"可以提交",然后把結(jié)果返回給事務(wù)管理器。
1.2 commit 階段：
事務(wù)管理器收到回應(yīng)后進(jìn)入第二階段，如果在第一階段內(nèi)有任何一個(gè)數(shù)據(jù)庫的操作發(fā)生了錯(cuò)誤，或者事務(wù)管理器收不到某個(gè)數(shù)據(jù)庫的回應(yīng)，則認(rèn)為事務(wù)失敗，回撤所有數(shù)據(jù)庫的事務(wù)。數(shù)據(jù)庫服務(wù)器收不到第二階段的確認(rèn)提交請(qǐng)求，也會(huì)把"可以提交"的事務(wù)回撤。如果第一階段中所有數(shù)據(jù)庫都提交成功，那么事務(wù)管理器向數(shù)據(jù)庫服務(wù)器發(fā)出"確認(rèn)提交"請(qǐng)求，數(shù)據(jù)庫服務(wù)器把事務(wù)的"可以提交"狀態(tài)改為"提交完成"狀態(tài)，然后返回應(yīng)答。
2. MySQL 中的XA實(shí)現(xiàn)
Support for XA transactions is available for the InnoDB storage engine. The MySQL XA implementation is based on the X/Open CAE document Distributed Transaction Processing: The XA Specification.
Currently, among the MySQL Connectors, MySQL Connector/J 5.0.0 and higher supports XA directly, by means of a class interface that handles the XA SQL statement interface for you.
XA supports distributed transactions, that is, the ability to permit multiple separate transactional resources to participate in a global transaction. Transactional resources often are RDBMSs but may be other kinds of resources.
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. (However, for a distributed transaction, you must use the SERIALIZABLE isolation level to achieve ACID properties. It is enough to use REPEATABLE READ for a nondistributed transaction, but not for a distributed transaction.)
最重要的一點(diǎn)：使用MySQL中的XA實(shí)現(xiàn)分布式事務(wù)時(shí)必須使用serializable隔離級(jí)別。
The MySQL implementation of XA MySQL enables a MySQL server to act as a Resource Manager that handles XA transactions within a global transaction. A client program that connects to the MySQL server acts as the Transaction Manager.
The process for executing a global transaction uses two-phase commit (2PC). This takes place after the actions performed by the branches of the global transaction have been executed.
In the first phase, all branches are prepared. That is, they are told by the TM to get ready to commit. Typically, this means each RM that manages a branch records the actions for the branch in stable storage. The branches indicate whether they are able to do this, and these results are used for the second phase.
In the second phase, the TM tells the RMs whether to commit or roll back. If all branches indicated when they were prepared that they will be able to commit, all branches are told to commit. If any branch indicated when it was prepared that it will not be able to commit, all branches are told to roll back.
第一階段：為prepare階段，TM向RM發(fā)出prepare指令，RM進(jìn)行操作，然后返回成功與否的信息給TM；
第二階段：為事務(wù)提交或者回滾階段，如果TM收到所有RM的成功消息，則TM向RM發(fā)出提交指令；不然則發(fā)出回滾指令；
XA transaction support is limited to the InnoDB storage engine.(只有innodb支持XA分布式事務(wù))
For "external XA" a MySQL server acts as a Resource Manager and client programs act as Transaction Managers. For "Internal XA", storage engines within a MySQL server act as RMs, and the server itself acts as a TM. Internal XA support is limited by the capabilities of individual storage engines. Internal XA is required for handling XA transactions that involve more than one storage engine. The implementation of internal XA requires that a storage engine support two-phase commit at the table handler level, and currently this is true only for InnoDB.
MySQL中的XA實(shí)現(xiàn)分為：外部XA和內(nèi)部XA；前者是指我們通常意義上的分布式事務(wù)實(shí)現(xiàn)；后者是指單臺(tái)MySQL服務(wù)器中，Server層作為TM(事務(wù)協(xié)調(diào)者)，而服務(wù)器中的多個(gè)數(shù)據(jù)庫實(shí)例作為RM，而進(jìn)行的一種分布式事務(wù)，也就是MySQL跨庫事務(wù)；也就是一個(gè)事務(wù)涉及到同一條MySQL服務(wù)器中的兩個(gè)innodb數(shù)據(jù)庫(因?yàn)槠渌娌恢С諼A)。
3. 內(nèi)部XA的額外功能
XA 將事務(wù)的提交分為兩個(gè)階段，而這種實(shí)現(xiàn)，解決了 binlog 和 redo log的一致性問題，這就是MySQL內(nèi)部XA的第三種功能。
MySQL為了兼容其它非事物引擎的復(fù)制，在server層面引入了 binlog, 它可以記錄所有引擎中的修改操作，因而可以對(duì)所有的引擎使用復(fù)制功能；MySQL在4.x 的時(shí)候放棄redo的復(fù)制策略而引入binlog的復(fù)制(淘寶丁奇)。
但是引入了binlog，會(huì)導(dǎo)致一個(gè)問題——binlog和redo log的一致性問題：一個(gè)事務(wù)的提交必須寫redo log和binlog，那么二者如何協(xié)調(diào)一致呢？事務(wù)的提交以哪一個(gè)log為標(biāo)準(zhǔn)？如何判斷事務(wù)提交？事務(wù)崩潰恢復(fù)如何進(jìn)行？
MySQL通過兩階段提交(內(nèi)部XA的兩階段提交)很好地解決了這一問題：
第一階段：InnoDB prepare，持有prepare_commit_mutex，并且write/sync redo log； 將回滾段設(shè)置為Prepared狀態(tài)，binlog不作任何操作；
第二階段：包含兩步，1> write/sync Binlog； 2> InnoDB commit (寫入COMMIT標(biāo)記后釋放prepare_commit_mutex)；
以 binlog 的寫入與否作為事務(wù)提交成功與否的標(biāo)志，innodb commit標(biāo)志并不是事務(wù)成功與否的標(biāo)志。因?yàn)榇藭r(shí)的事務(wù)崩潰恢復(fù)過程如下：
1> 崩潰恢復(fù)時(shí)，掃描最后一個(gè)Binlog文件，提取其中的xid；
2> InnoDB維持了狀態(tài)為Prepare的事務(wù)鏈表，將這些事務(wù)的xid和Binlog中記錄的xid做比較，如果在Binlog中存在，則提交，否則回滾事務(wù)。
通過這種方式，可以讓InnoDB和Binlog中的事務(wù)狀態(tài)保持一致。如果在寫入innodb commit標(biāo)志時(shí)崩潰，則恢復(fù)時(shí)，會(huì)重新對(duì)commit標(biāo)志進(jìn)行寫入；
在prepare階段崩潰，則會(huì)回滾，在write/sync binlog階段崩潰，也會(huì)回滾。這種事務(wù)提交的實(shí)現(xiàn)是MySQL5.6之前的實(shí)現(xiàn)。
4. binlog 組提交
上面的事務(wù)的兩階段提交過程是5.6之前版本中的實(shí)現(xiàn)，有嚴(yán)重的缺陷。當(dāng)sync_binlog=1時(shí)，很明顯上述的第二階段中的 write/sync binlog會(huì)成為瓶頸，而且還是持有全局大鎖(prepare_commit_mutex: prepare 和 commit共用一把鎖)，這會(huì)導(dǎo)致性能急劇下降。解決辦法就是MySQL5.6中的 binlog組提交。
4.1 MySQL5.6中的binlog group commit:
將Binlog Group Commit的過程拆分成了三個(gè)階段：
1> flush stage 將各個(gè)線程的binlog從cache寫到文件中;
2> sync stage 對(duì)binlog做fsync操作（如果需要的話；最重要的就是這一步，對(duì)多個(gè)線程的binlog合并寫入磁盤）；
3> commit stage**** 為各個(gè)線程做引擎層的事務(wù)commit(這里不用寫redo log，在prepare階段已寫)。每個(gè)stage同時(shí)只有一個(gè)線程在操作。(分成三個(gè)階段，每個(gè)階段的任務(wù)分配給一個(gè)專門的線程，這是典型的并發(fā)優(yōu)化**)
這種實(shí)現(xiàn)的優(yōu)勢(shì)在于三個(gè)階段可以并發(fā)執(zhí)行，從而提升效率。注意prepare階段沒有變，還是write/sync redo log.
(另外：5.7中引入了MTS：多線程slave復(fù)制，也是通過binlog組提交實(shí)現(xiàn)的，在binlog組提交時(shí)，給每一個(gè)組提交打上一個(gè)seqno，然后在slave中就可以按照master中一樣按照seqno的大小順序，進(jìn)行事務(wù)組提交了。)
4.2 MySQL5.7中的binlog group commit:
淘寶對(duì)binlog group commit進(jìn)行了進(jìn)一步的優(yōu)化，其原理如下：
從XA恢復(fù)的邏輯我們可以知道，只要保證InnoDB Prepare的redo日志在寫B(tài)inlog前完成write/sync即可。因此我們對(duì)Group Commit的第一個(gè)stage的邏輯做了些許修改，大概描述如下：
Step1. InnoDB Prepare，記錄當(dāng)前的LSN到thd中；
Step2. 進(jìn)入Group Commit的flush stage；Leader搜集隊(duì)列，同時(shí)算出隊(duì)列中最大的LSN。
Step3. 將InnoDB的redo log write/fsync到指定的LSN (注：這一步就是redo log的組寫入。因?yàn)樾∮诘扔贚SN的redo log被一次性寫入到ib_logfile[0|1])
Step4. 寫B(tài)inlog并進(jìn)行隨后的工作(sync Binlog, InnoDB commit , etc)
也就是將 redo log的write/sync延遲到了 binlog group commit的 flush stage 之后，sync binlog之前。
通過延遲寫redo log的方式，顯式的為redo log做了一次組寫入(redo log group write)，并減少了(redo log) log_sys->mutex的競(jìng)爭(zhēng)。
也就是將 binlog group commit 對(duì)應(yīng)的redo log也進(jìn)行了 group write. 這樣binlog 和 redo log都進(jìn)行了優(yōu)化。
官方MySQL在5.7.6的代碼中引入了淘寶的優(yōu)化，對(duì)應(yīng)的Release Note如下：
When using InnoDB with binary logging enabled, concurrent transactions written in the InnoDB redo log are now grouped together before synchronizing to disk when innodb_flush_log_at_trx_commit is set to 1, which reduces the amount of synchronization operations. This can lead to improved performance.
5. XA參數(shù) innodb_support_xa
http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_support_xa
| Command-Line Format | --innodb_support_xa |
| System Variable | Name | [innodb_support_xa](http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_support_xa) |
| Variable Scope | Global, Session |
| Dynamic Variable | Yes |
| Permitted Values | Type | boolean |
| Default | TRUE |
Enables InnoDB support for two-phase commit(2PC) in XA transactions, causing an extra disk flush for transaction preparation. This setting is the default. The XA mechanism is used internally and is essential for any server that has its binary log turned on and is accepting changes to its data from more than one thread. If you turn it off, transactions can be written to the binary log in a different order from the one in which the live database is committing them. This can produce different data when the binary log is replayed in disaster recovery or on a replication slave. Do not turn it off on a replication master server unless you have an unusual setup where only one thread is able to change data.
For a server that is accepting data changes from only one thread, it is safe and recommended to turn off this option to improve performance forInnoDB tables. For example, you can turn it off on replication slaves where only the replication SQL thread is changing data.
You can also turn off this option if you do not need it for safe binary logging or replication, and you also do not use an external XA transaction manager.
參數(shù)innodb_support_xa默認(rèn)為true，表示啟用XA，雖然它會(huì)導(dǎo)致一次額外的磁盤flush(prepare階段flush redo log). 但是我們必須啟用，而不能關(guān)閉它。因?yàn)殛P(guān)閉會(huì)導(dǎo)致binlog寫入的順序和實(shí)際的事務(wù)提交順序不一致，會(huì)導(dǎo)致崩潰恢復(fù)和slave復(fù)制時(shí)發(fā)生數(shù)據(jù)錯(cuò)誤。如果啟用了log-bin參數(shù)，并且不止一個(gè)線程對(duì)數(shù)據(jù)庫進(jìn)行修改，那么就必須啟用innodb_support_xa參數(shù)。
掃描redo，對(duì)于checkpoint位置點(diǎn)之前的，這部分?jǐn)?shù)據(jù)已經(jīng)落盤了，就不用管了，就看處于prepare狀態(tài)的事物，拿到這些事物的Xid，如果都有{Xid--binlog filename position的對(duì)應(yīng)關(guān)系}就說明這部分事物是成功的，如果只有xid，沒有binlog filename，position，就去掃描最后一個(gè)binlog文件，看這個(gè)xid在這個(gè)文件里面有沒有，有的話，就說明這個(gè)事物寫binlog是寫成功的，只是還沒來得及回寫binlog filename以及position到redo log里面，數(shù)據(jù)庫就掛了，所以會(huì)重新將其提交，如果沒有xid，就說明該事物寫binlog沒寫成功，再利用undo log將其回滾。
參考：
1. http://www.csdn.net/article/2015-01-16/2823591 (淘寶丁奇：怎么跳出MySQL的10個(gè)大坑)
3. http://dev.mysql.com/doc/refman/5.7/en/xa.html
4. http://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html
