MySQL——主从复制
以前对 MySQL 作数据分布仅仅是读写分离，通过数据库自身的主从复制即可实现写主库、读从库。现在则需要双写主库并在经历一个短暂的延时后达成最终一致性，这个问题乍一想比较复杂，但归根结底还是数据最终一致性的问题。
一个数据库数据一致性保证
数据库的事务特性来保证的，具体见blog中《事务》。
主从架构之间数据一致性
MySQL 为了提供主从复制功能引入了一个新的日志文件叫 binlog，它包含了引发数据变更的事件日志集合。从库请求主库发送 binlog 并通过日志事件还原数据写入从库，所以从库的数据来源为 binlog。这样 MySQL 主库只需做到 binlog 与本地数据一致就可以保证主从库数据一致（暂且忽略网络传输引发的主从不一致）。我们知道保证本地数据一致性是靠数据库事务特性来达成的，而数据库事务是如何实现的呢？先看下面这张图：
MySQL 本身不提供事务支持，而是开放了存储引擎接口，由具体的存储引擎来实现，具体来说支持 MySQL 事务的存储引擎就是 InnoDB。存储引擎实现事务的通用方式是基于 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 事务）的方式完成两阶段提交。
总结
我们前面先提出了一个问题，然后从数据一致性的角度去思考，参考了 MySQL 的实现方式。理清并分析了 MySQL 单机环境是如何保证复制机制的数据一致性，也就是 binlog 和事务数据的一致。后面我们才能基于 binlog 这个机制去实现复制并保证主从复制的一致性。主从复制又引入了网络因素，进一步增加了保证主从数据一致性的复杂度，后面还会撰文进一步分析这个问题。
参考资料
后端分布式系列：分布式存储－MySQL 数据库事务与复制
