MySQL中的两阶段(2PC)提交
介绍MySQL两阶段提交之前，先介绍一下Redo Log 和 Binlog
redo log：
在MySQL中如果每次更新都需要写进磁盘，然后磁盘也要找到那条记录，然后在更新，整个过程IO成本、查找成本都很高，因此引入了redo log。这里用到了MySQL中的WAL技术，Write-Ahead Logging，它的关键点是先写日志，再写磁盘。
具体来说就是，当需要更新一条数据时，InnoDB引擎会先把记录写进redo log中，并更新内存，这个时候就算完成。同时InnoDB会在空闲的时候将这个记录写进磁盘。
redo log是固定大小，从头开始写入，写到尾部就又回到开头循环写。指针write pos记录当前位置，checkpoint是要擦出的位置，当两者之间有空余位置，即可继续更新，当满了后，就需要checkpoint擦除数据后继续更新。
有了redo log，InnoDB就可以保证数据库即使发生异常重启，之前提交的记录也不会丢失。
binlog:
MySQL有两块组成：server层，主要负责MySQL功能层面的事情；引擎层，负责存储相关的事情，redo log 就是InnoDB特有的日志。而server层也有自己的日志，就是binlog。
redo log 和 binlog的区别：
- redo log是InnoDB特有的，binlog是MySQL的server层实现的，所有引擎都有
- redo log是物理日志，记录的是“在某个数据页上做了什么操作”；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1”。
- redo log是循环写的，空间固定会用完；binlog是可以追加写入的，“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
在更新一条数据时，会先执行，然后写入redo log中，redo log进入prepare状态，执行器执行完成。然后执行器生成这个操作的binlog，并写入磁盘。然后提交commit，更新完成。
两阶段提交：
redo log 和binlog是两个独立的逻辑，如果不用两阶段提交，那么就会先写redo log，后写binlog，或者反过来的顺序写。看看会有什么问题。把数据0更新到1
- 先写redo log，后binlog：假设redo log在写完后，系统崩溃了，binlog还未完成，因为redo log写完了，数据依然可以恢复到之前的状态。但是当我们需要使用binlog来恢复临时库时，binlog中并没有这条记录，那么恢复后的值就会和之前的不同，本应该是1，但是结果是0。
- 先binlog，后redo log：同样的假设，binlog写完，系统崩溃，redo log未完成。这个时候系统崩溃，由于没有完成redo log，那么就不能恢复到执行结果后的数据，依然是没有执行这条语句前的数，但是binlog已经写入，那么同样使用binlog恢复临时表时，数据就会之前的不同。本应该是0，但是结果是1.
因此两阶段提交保证了两个日志的一致性，要么都成功，要么都失败。可以对照zookeeper的2PC理解。
