看到很多MySql事务的两阶段提交的文章，感觉大部分还是八股文，这里记录一下自己心得。

redolog和binlog是什么

具体是什么，以及区别这里不再赘述，可以参见这个：为什么写入redo log和bin log要用两个阶段提交呢
注意，redolog记录的是数据修改（如set count = 18），binlog记录的是sql（如update count = count +1）
显然，从redolog中是恢复不了binlog（sql) 的（只有数据的前后状态，不知中间具体操作）
但是，理论上，从binlog中可以恢复redolog，但是要结合之前的数据状态，这个过程其实就是重现redolog prepare阶段的计算。

两阶段步骤过程

image.png

为什么要两阶段

其实这个问题更准确的说法应该是——为什么redolog要分两阶段标记？
回答这个问题之前，我们有几个前提要了解一下：
1）我们要保证binlog的完整性
binlog要用于宕机后恢复，和主从复制在slave机上复现master机记录，前文已经提到：从redolog中是恢复不了binlog（sql)，这要求“宕机之前的binlog记录要完整”
2）第一步就crash的情况，不用考虑宕机恢复
binlog和redolog都还没开始记录，crash了，不用管。
因为二者都没记录，那么恢复时此次事务没有留下任何记录，满足原子性——要么做完，要么没做，此时这次事务是对应于没做的情况，不影响。
这提示我们，无论是用多少阶段提交，第一步就crash的情况，不用考虑宕机恢复，因为事务完全没有执行

一阶段真的无法保持一致吗

知道了这些前提，让我们再来假设一下如果redolog只用一次标记——直接commit，中间发生crash（宕机/线程挂了）会发生什么。
显然，根据binlog和redolog的操作顺序，有两种情况：

• 先redolog commit，再写binlog
  如果写binlog过程中发生crash，因为redolog中恢复不了binlog（前面已经说过这种情况），宕机后二者内容不一致，恢复时binlog记录也找不回。
  那么是否意味着二者无法保持一致性了呢？
  并不是，可以考虑这么干：redolog现在就是比binlog多了最新的事务内容而已，删掉对应的不就行了：
  对比redolog和binlog的记录，发现redolog的最新txid比binlog大，说明binlog写一半停机了，所以删掉redolog中这个txid对应的记录，二者又保持了一致性，只是是恢复到该事务之前的状态。
• 先写binlog，再redolog commit
  如果redolog commit过程中发生crash，理论上是可以从binlog中恢复redolog内容的，然后提交，这就保持了一致性。
  或者对比对比redolog和binlog的记录，将binlog存在但redolog不存在的记录删除，也能恢复一致性。
  前者的一致性是事务执行之后的状态，后者是事务执行之前的状态。

可以看到，无论是哪种方式，都是可以保持二者一致性的，只是恢复时，抹去or填平不一致需要较重的成本——回滚or追加binlog redolog内容。

两阶段提交以极低成本实现了crash-safe

那么两阶段在应对crash情况时的恢复成本如何呢？
redolog prepare——binlog——redolog commit
1）如果在写binlog过程中宕机，重启时发现binlog不完整，直接将redolog prepare的记录删除，恢复了事务执行之前的数据一致性
2）如果在标记redolog commit过程中宕机，重启时发现binlog完整且redolog prepare，那么继续宕机前的工作——标记redolog commit即可。
可以看到，两阶段的策略，“恢复一致性成本”很低，不涉及binlog和真正的redolog（非prepare commit标记）的添加or删除（回滚），仅仅是重新处理redolog flag而已。

总结

一阶段同样可以实现crash-safe，但是成本高昂——要去写binlog/redolog记录，两阶段以极低成本实现了crash-safe，所以是更好的方案。