谈到两阶段提交先要知道什么是binlog与redolog
binlog
binlog中文一般称作归档日志，是MySQL Server层的日志，而不是存储引擎自带的日志，它记录了所有的DDL和DML（不包含数据查询语句），而且是以事件形式记录，还包含语句所执行的消耗的时间等，需要注意的是：
1.binlog是一种逻辑日志，它里面所记录的是一条SQL语句的原始逻辑，例如给某一个字段修改，注意这个区别于 redo log 的物理日志（在某个数据页上做了什么修改）
2.binlog文件写满以后，会自动切换到下一个日志文件继续写，而不会覆盖以前的日志，这个也区别于redo log，redo log是循环写入的，即后面写入的可能会覆盖前面写入的。
3.一般来说，我们在配置binlog时，可以指定binlog文件的有效期，这样到期后，日志文件会自动删除，这样避免占用较多的存储空间。
注：根据官方文档介绍，开启binlog之后，大概会有1%的性能损耗。
redo log
为什么要用redo log去实现事务的持久性，不直接写入磁盘，因为，Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，不仅效率低，也浪费资源，效率低是因为这些数据页在物理上并不连续，将数据页刷到磁盘的话会涉及随机IO。
所以，redo log来了，redo log是顺序IO，在一个固定的位置循环写入。MySQL每写一条DML语句，先将记录写入redo log buffer，后续在某一个时间点再一次性将多个操作记录写到redo log file，这种先写日志再写磁盘的技术就是MySQL里经常说到的WAL（Write-Ahead Logging）技术（预写日志）
redo log本身又分为：
1.日志缓冲（redo log buffer）：有易失性。
2.重做日志（redo log file）：这是磁盘上的日志文件，该部分的日志是持久的。
顺带一提，三种日志的使用场景
1.undo log(回滚日志):是Innodb存储引擎层生成的日志，实现了事务的原子性，主要用于事务回滚和MVCC。
2.redo log(重做日志):是Innodb存储引擎层生成的日志，实现了事务的持久性，主要用于恢复数据。
3.bin log(归档日志):是server层生成的日志，主要用于数据备份，恢复到某一时刻的数据和主从复制。
两阶段提交
可以看出最后事务提交的时候有三个步骤：
1.写入redo log,处于prepare状态。
2.写binlog。
3.修改redo log状态为commit。
由于redo log的提交分为prepare 和commit两个阶段，所以称作两阶段提交。
为什么需要两阶段提交
一句话：解决数据一致性。
