什么是事务的2阶段提交 ？

一、什么是事务的2阶段提交 ？

所谓的MySQL事务的2阶段提交，其实是在更新过程中，保证binlog 和 redolog一致性的一种手段。

上图中右侧部分即为2阶段提交。他的过程是：

• Prepare 准备阶段

  • 这个阶段 SQL 已经成功执行并生成 redolog，处于prepare阶段

• BinLog 持久化

  • binlog 提交，通过 write() 将 binlog 内存日志数据写入文件缓冲区；

  • 通过fsync() 将 binlog 从文件缓冲区永久写入磁盘；

• Commit

  • 在执行引擎内部执行事务操作，更新redolog，处于Commit阶段。

write 和 fsync 是与文件系统和磁盘IO相关的两个不同的操作。

write 操作将数据写入文件的缓冲区，这意味着 write 操作完成后，并不一定立即将数据持久化到磁盘上，而是将数据暂时存储在内存中。

fsync 用于强制将文件的修改持久化到磁盘上。它通常与 write 配合使用，以确保文件的修改在 fsync 操作完成后被写入磁盘。

二、那么，为什么这个过程需要用2阶段提交的方式呢 ？

假设我们执行一条SQL语句，修改他的name为Hollis ： update user set name = 'hollis' where id = 10 。

假设先写入redo log 成功，但是没来得及写入bin log ，系统崩了。在MySQL重启后，可以根据redolog把记录更新成'hollis'，但是，binlog由于没写成功，

所以他是没有记录下来这次变更的，那么也就意味着，主备同步的时候，是缺了一条SQL的，导致主备库之间数据不一致。

那么，如果换个顺序，先写入binlog成功，但是没来及的写入redolog，系统崩了。在MySQL重启之后，崩溃恢复的时候由于redo log还没写，所以什么都不用做，

数据库记录还是旧值。但是因为binlog已经写入成功了，所以在做主备同步的时候，就会把新值同步到备库，就导致了主备库之间数据不一致。

如上面的例子，如果不引入二阶段提交的话，在bin log 和redo log没办法保证一致性的情况下，就会导致主备库之间的数据不一致。

而为了解决这个问题，那就引入了2阶段提交，来整体的控制redo log 和 bin log的一致性写入。

三、2阶段如何保证一致性的 ？

引入2阶段提交之后，事务的提交过程就可能有以下三种情况：

情况1：一阶段提交之后崩溃了，即写入 redo log，处于 prepare 状态 的时候崩溃了

此时已经写了redolog，处于prepare状态，binlog还没写。这时候如果崩溃恢复，直接回滚事务即可，这样主从是一致的，就都没有执行这个事务。

情况2：一阶段提交成功，写完 binlog 之后崩溃了

此时，redolog处于prepare状态，binlog已写入，这时候检查 binlog 中的事务是否存在并且完整，如果存在且完整，则直接提交事务，如果不存在或者不完整，则回滚事务

情况3：假设 redolog 处于 commit 状态的时候崩溃了，那么重启后的处理方案同情况二

由此可见，两阶段提交能够确保数据的一致性。

四、如何判断binlog和redolog达成一致了 ？

当MySQL写完 redolog日志 并将它标记为 prepare 状态时，并且会在 redolog中记录一个XID，它全局唯一的标识着这个事务。

而当你设置sync_binlog=1时，做完了上面第一阶段写redolog后，mysql就会对应 binlog 并且会直接将其刷新到磁盘中。

下图就是磁盘上的row格式的binlog记录。binlog结束的位置上也有一个XID。

只要这个 XID 和 redolog 中记录的XID是一致的，MySQL就会认为binlog和redolog逻辑上是一致的。