一. 两阶段提交
1.1 利用 binlog 和redolog 做到两阶段提交
从上图中看出：最后提交事务的三个步骤：
- 写入redo log ，处于prepare状态
- 写binlog
- 修改redo log 状态变为commit
由于redo log 的提交分为prepare 和commit两个阶段，所以我们称之为两阶段提交。
1.2 为什么要两阶段提交
假设我们不适用两阶段提交，那么binlog和redolog的提交就两种形式：
- 先写binlog 再写redolog
- 先写redolog 再写binlog
当我们要向表中DDL，插入一条记录R的时候。
情况一：
如果我们先写binlog再写redolog，那么假设binlog写完后崩溃了，此时redolog还没写。那么重启恢复的时候就会出现问题：
binlog中已经有R的记录了，当从主机同步数据的时候，或者我们使用binlog恢复数据的时候，就会同步R这条记录。但是redolog中没有关于R的记录，所以恢复崩溃之后，插入R记录的这个事务是无效的，即数据库中没有该行的记录，而这就造成了数据不一致的情况。
情况二：
如果我们是先写redolog再写 binlog，那么假设redolog写完后崩溃了，此时binlog还没写。那么重启恢复的时候也会出现问题：
redolog中已经有R的记录了，所以崩溃恢复之后，插入R记录的这个事务是有效的，通过该记录可以将数据恢复到数据库中；但是binlog中还没有关于R的记录，所以当从机从主机同步数据的时候，或者我们使用binlog恢复数据的时候，就不会同步到R这条记录，这就造成了数据不一致。
两阶段提交如何保证数据一致性：
情况一：一阶段提交之后崩溃了，即 写入 redo log，处于 prepare 状态 的时候崩溃了，此时：由于 binlog 还没写，redo log 处于 prepare 状态还没提交，所以崩溃恢复的时候，这个事务会回滚，此时 binlog 还没写，所以也不会传到备库。
情况二：假设写完 binlog 之后崩溃了，此时：
redolog 中的日志是不完整的，处于 prepare 状态，还没有提交，那么恢复的时候，首先检查 binlog 中的事务是否存在并且完整，如果存在且完整，则直接提交
事务，如果不存在或者不完整，则回滚事务。
情况三：假设 redolog 处于 commit 状态的时候崩溃了，那么重启后的处理方案同情况二。
由此可见，两阶段提交能够确保数据的一致性。
