二階段提交在MySQL中的廣義應用是怎樣的

本篇文章給大家分享的是有關二階段提交在MySQL中的廣義應用是怎樣的，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

二階段提交介紹 

• 事務發起者(AP)：定義事務邊界（開始、結束），并操作事務邊界內的資源。

• 事務協調者(TM)：負責管理事務（提交、回滾），監控事務執行進度，分為事務唯一標識

• 事務參與者(RM)：根據“事務協調者”命令進行操作，管理本地共享資源，記錄執行日志

• TM：對RM發送Prepare指令，等待RM的回執（ACK）

• RM：接收TM發送的指令，鎖定資源，執行事務操作，但不提交。記錄撤銷日志和重做日志，如果事務執行成功，回復“是”；如失敗，回復“否”

• TM：如果接收到了所有RM的“是”回執，發送Commit給RM；如果在超時時間內有RM沒有任何回執，或者有RM回復了“否”,發送Rollback給RM。

• RM：根絕TM發送的指令執行Commit或者Rollback操作,針對Rollback操作，RM使用表決階段記錄的撤銷日志。操作完成后給TM發送回執“OK”。如果收不到指令，一直等待。

-    二階段提交的應用     -

-    MySQL中binlog和redo log的二階段提交廣義應用     -

MySQL的雙日志（binlog 和 redo log）記錄采用二階段提交保證數據的強一致性。

binlog是由MySQL Server層記錄，與任何存儲引擎無關。binlog主要記錄的是操作日志，有三種格式：Statement、Row、Mixedlevel。binlog的主要用途是故障恢復、主從同步。

• 如果是先寫binlog 再寫 redo log。當binlog寫入成功后,redo log未寫入成功，主節點宕機，此時分兩個狀態：
  

1. 事務執行中，由于Innodb存儲引擎的恢復是基于redo log的，此時master和slave都沒有該數據，數據是一致的。

2. 事務已提交，master基于redo log的恢復后的數據和slave中的數據會出現不一致問題。

• 如果先寫redo log再寫binlog。當redo log寫入成功后，主節點宕機，此時分兩種狀態：
  

1. 事務執行中，由于當前事務沒有提交，基于redo log恢復，未提交的時候不會寫入，slave和master都沒有該數據，數據是一致的。

2. 事務已提交，redo log的事務已提交，binlog 記錄的事務沒有提交，master節點重啟后，該數據會寫入master節點，而slave節點沒有，數據不一致。

綜上所述，只有事務處于已提交狀態的情況下，才會出現數據不一致問題。為了保證數據一致性。事務提交時，redo log和binlog的Commit操作需要在同一個事務里，由于binlog和redo log由不同的層記錄，需要分布式事務，為了保證數據一致性，二階段提交滿足這樣的需求場景。

-    MySQL二階段提交特殊性     -

• 常規二階段提交協議中，TM發個Prepare信息給RM是串行有序的。

• MySQL中，Server 先發給redo log 進行Prepare fsync操作（數據寫入磁盤）
  

• 常規二階段提交協議中，TM發個Commit信息給RM是無序的，不用關注RM發送的先后順序。

• MySQL的二階段，Server 先發給binLog 進行write +  fsync進行合并操作，然后在通知redo log進行Commit。

• 少一次交互(對于分布式事務來說就少一次網絡io)

• 少一次持久化操作(少一次磁盤io)
  

以上就是二階段提交在MySQL中的廣義應用是怎樣的，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。