资料来自于 阿里 数据库内核月报
两阶段提交
为什么需要两阶段提交即为什么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数据恢复一致性