xa-2pc (two phase commit, 兩階段提交 )
第一階段：為prepare階段，tm向rm發出prepare指令，rm進行操作，然後返回成功與否的資訊給tm；
第二階段：為事務提交或者回滾階段，如果tm收到所有rm的成功訊息，則tm向rm發出提交指令；不然則發出回滾指令；
mysql通過兩階段提交很好地解決了binlog和redo log的一致性問題
第一階段：innodb prepare，持有prepare_commit_mutex，並且write/sync redo log； 將回滾段設定為prepared狀態，binlog不作任何操作；
第二階段：包含兩步
1、write/sync binlog；
2、innodb commit (寫入commit標記後釋放prepare_commit_mutex)；
以 binlog 的寫入與否作為事務提交成功與否的標誌，innodb commit標誌並不是事務成功與否的標誌。因為此時的事務崩潰恢復過程如下：
1、崩潰恢復時，掃瞄最後乙個binlog檔案，提取其中的xid；
2、innodb維持了狀態為prepare的事務鍊錶，將這些事務的xid和binlog中記錄的xid做比較，如果在binlog中存在，則提交，否則回滾事務。
通過這種方式，可以讓innodb和binlog中的事務狀態保持一致。如果在寫入innodb commit標誌時崩潰，則恢復時，會重新對commit標誌進行寫入；
在prepare階段崩潰，則會回滾，在write/sync binlog階段崩潰，也會回滾。這種事務提交的實現是mysql5.6之前的實現。
mysql5.6中的binlog 組提交
將binlog group commit的過程拆分成了三個階段
flush stage 將各個執行緒的binlog從cache寫到檔案中;
sync stage 對binlog做fsync操作（如果需要的話；最重要的就是這一步，對多個執行緒的binlog合併寫入磁碟）；
commit stage 為各個執行緒做引擎層的事務commit(這裡不用寫redo log，在prepare階段已寫)。
每個stage同時只有乙個執行緒在操作。(分成三個階段，每個階段的任務分配給乙個專門的執行緒，這是典型的併發優化)
這種實現的優勢在於三個階段可以併發執行，從而提公升效率。注意prepare階段沒有變，還是write/sync redo log.
mysql5.7中的binlog組提交
從xa恢復的邏輯我們可以知道，只要保證innodb prepare的redo日誌在寫binlog前完成write/sync即可
innodb prepare，記錄當前的lsn到thd中；
進入group commit的flush stage；leader蒐集佇列，同時算出佇列中最大的lsn。
將innodb的redo log write/fsync到指定的lsn
寫binlog並進行隨後的工作(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的競爭。
commit命令為例mysql提交**框架如下
sql_parse.cc mysql_execute_command
sql_parse.cc sqlcom_commit
transaction.cc trans_commit()
handler.cc ha_commit_trans()
handler.cc tc_log->prepare()
binlog.cc mysql_bin_log::prepare() //prepare 入口
handler.cc tc_log->commit()
binlog.cc mysql_bin_log::commit() //commit入口
if (total_ha_2pc > 1 || (1 == total_ha_2pc && opt_bin_log))
else
tc_log= &tc_log_dummy;
分布式事務2PC協議
two phase commit protocol 在事務處理，資料庫，計算機網路中，兩階段提交 2pc 是一種原子提交協議。它是一種分布式演算法，協調參與分布式原子事務的所有程序，決定是提交事務還是中止 回滾 事務 它是一種協商一致性協議 該協議即使在許多臨時系統故障 包括程序 網路節點 通訊等故...
分布式場景之剛性事務 2PC詳解
分布式一致性 分布式場景下，多個服務同時對服務乙個流程，比如電商下單場景，需要支付服務進行支付 庫存服務扣減庫存 訂單服務進行訂單生成 物流服務更新物流資訊等。如果某乙個服務執行失敗，或者網路不通引起的請求丟失，那麼整個系統可能出現資料不一致的原因。上述場景就是分布式一致性問題，追根到底，分布式一致...
分布式場景之剛性事務 2PC詳解
分布式一致性 分布式場景下，多個服務同時對服務乙個流程，比如電商下單場景，需要支付服務進行支付 庫存服務扣減庫存 訂單服務進行訂單生成 物流服務更新物流資訊等。如果某乙個服務執行失敗，或者網路不通引起的請求丟失，那麼整個系統可能出現資料不一致的原因。上述場景就是分布式一致性問題，追根到底，分布式一致...