資料來自於 阿里 數據庫內核月報
兩階段提交
爲什麼需要兩階段提交即爲什麼binlog要在redolog之間？先使用redolog或者binlog爲什麼不行？
MySQL故障恢復流程
MySQL故障恢復啓動時，會初始化儲存引擎，這裏討InnoDB，InnoDB會讀取redolog進行InnoDB的故障恢復，回滾prepare(同時肯定沒有commit) 的事務，但是對於已經prepare的事務，但是未commit事務，會暫時掛起，保存到鏈表中，然後等待讀取binlog，讀取binlog後，由於已經prepare的事務但是沒commit的事務，這裏只有兩種情況，一個是binlog寫入完成，此時就可以根據已經寫入的binlog來執行commit，另一種情況是binlog未寫入，此時直接丟棄這條數據，不進行commit。
所以現在就很容易看出爲什麼要進行兩階段提交：
如果先寫binlog 後寫 redolog： 在寫完binlog後崩潰，在事務進行恢復的時候，將無法掃描到這行，即redolog裏沒有關於這行的任何信息，自然也就不可能根據redolog去進行恢復，但是行後續如果根據binlog去恢復數據，此時就會造成恢復出來的數據（根據binlog）和被恢復的數據不同（根據redolog），此時將會造成數據不一致。
**如果先寫redolog後寫binlog：**此時redolog寫完，崩潰，此時binloglog裏沒有，而後續恢復是按照redolog來的，此時將無法恢復這條數據，而使用binlog進行數據庫的備份或者恢復，也會造成數據不一致。
使用兩階段提交解決了上面兩個方法的數據不同步的問題：
上面兩種情況問題都是崩潰後redolog和binlog數據不一致，而通過兩階段提交和基於binlog與redolo對比恢復解決了數據不一致的問題。
對於的可能出現的故障問題爲：
redolog prepare後故障：此時binlog無記錄，redolog prepare，恢復時按照redolog爲prepare狀態對比binlog，此時binlog無記錄，該redolog記錄被撤銷，不執行。
binlog commit後故障：此時binlog有記錄，redolog prepare，恢復時檢測到binlog有，就直接繼續執行commit。
即：通過兩階段提交來保證binlog、redolog數據恢復一致性