MySQL分布式事务之两阶段提交学习

在MySQL中，两阶段提交（Two-Phase Commit, 2PC） 是确保事务在多个存储引擎（如InnoDB）和二进制日志（binlog）之间保持一致性的关键机制。特别是在使用InnoDB存储引擎时，两阶段提交用于协调redo log和binlog的提交顺序，确保数据的持久性和一致性。

redo log 和 binlog 的作用

• redo log
  InnoDB存储引擎使用redo log来确保事务的持久性。redo log记录了事务对数据页的修改，即使在系统崩溃后，也可以通过redo log恢复未写入磁盘的数据。

• binlog
  MySQL的二进制日志（binlog）记录了所有对数据库的更改操作（如INSERT、UPDATE、DELETE等），主要用于数据复制和恢复。

二阶段提交的过程

两阶段提交分为两个阶段：准备阶段（Prepare Phase） 和 提交阶段（Commit Phase）。

准备阶段（Prepare Phase）

1. 写入redo log
   事务开始时，InnoDB会先将事务的修改写入redo log，并将redo log标记为“prepare”状态。此时，redo log已经记录了事务的所有修改，但事务还没有最终提交。（innodb_flush_log_at_trx_commit = 1 的作用）

2. 写入binlog
   接着，MySQL会将事务的修改写入binlog。binlog的写入是事务提交的关键步骤，因为binlog记录了所有对数据库的更改操作。

提交阶段（Commit Phase）

1. 提交redo log
   在binlog成功写入后，InnoDB会将redo log的状态从“prepare”改为“commit”。这表示事务已经成功提交，并且redo log中的修改可以被应用到数据页中。

2. 完成提交
   此时，事务已经成功提交，数据修改在redo log和binlog中都得到了记录，可以返回请求成功。

崩溃恢复处理

在系统崩溃后，MySQL会根据redo log和binlog的状态来决定如何恢复数据。如果redo log处于“prepare”状态，而binlog中存在对应的事务记录，MySQL会提交该事务。如果binlog中没有对应的事务记录，MySQL会回滚该事务。

为什么要必须使用binlog作为协调日志

两阶段提交是为了协调多个存储引擎的事务，可能存在其它非innodb的存储引擎。只有binlog记录了所有操作变化，因此必须使用binlog作为协调日志，binlog必须先提交。

总结

MySQL中的两阶段提交机制确保了redo log和binlog的一致性。通过先写入binlog，再提交redo log，MySQL能够在系统崩溃后正确地恢复数据，保证事务的持久性和一致性。这种机制在高可用性和数据一致性要求较高的场景中尤为重要。