mysql分布式事务

储引擎实现事务的通用方式是基于 redo log 和 undo log。

 

简单来说，redo log 记录事务修改后的数据, undo log 记录事务前的原始数据。

所以当一个事务执行时实际发生过程简化描述如下：

 

先记录 undo/redo log，确保日志刷到磁盘上持久存储。

 

更新数据记录，缓存操作并异步刷盘。

 

提交事务，在 redo log 中写入 commit 记录。

 

在 MySQL 执行事务过程中如果因故障中断，可以通过 redo log 来重做事务或通过 undo log 来回滚，确保了数据的一致性。

 

这些都是由事务性存储引擎来完成的，但 binlog 不在事务存储引擎范围内，而是由 MySQL Server 来记录的。

 

那么就必须保证 binlog 数据和 redo log 之间的一致性，所以开启了 binlog 后实际的事务执行就多了一步，如下：

 

先记录 undo/redo log，确保日志刷到磁盘上持久存储。

 

更新数据记录，缓存操作并异步刷盘。

 

将事务日志持久化到 binlog。

 

提交事务，在 redo log 中写入提交记录。

 

这样的话，只要 binlog 没写成功，整个事务是需要回滚的，而 binlog 写成功后即使 MySQL Crash 了都可以恢复事务并完成提交。

 

要做到这点，就需要把 binlog 和事务关联起来，而只有保证了 binlog 和事务数据的一致性，才能保证主从数据的一致性。

 

所以 binlog 的写入过程不得不嵌入到纯粹的事务存储引擎执行过程中，并以内部分布式事务（xa 事务）的方式完成两阶段提交。