久违地写了技术报道。 因为我一直在想“后端分布式”这个系列怎么写比较合适。 最近，我们发现“后端分布式”有两个类别：“分布式存储”和“分布式计算”。 结合实际工作中遇到的问题，以寻找答案的形式对技术进行剖分，我们往往不是在创造新技术，而是在应用技术。 为了更高效、更有效地使用好的技术，我们需要了解一些技术的原理和工作原理。 提问从使用者的角度分析技术原理，将开源技术产品和框架作为技术的参考实现进行说明。 以说明原理为主要目的，具体实现的技术细节如无特殊之处，尽可能及时中止。
事务最近加入了一个与数据库MySQL数据分布相关的数据分布项目。 简而言之，您需要在异地数据中心提供多个可写性，以确保分布式数据的最终完整性。 以前，将数据分布在MySQL中的只是读写分离，数据库本身的主从复制可以写入主库，读取从库。 现在，需要双重编写主库，经过较短的延迟达到最终的一致性。 这个问题乍一看似乎很复杂，但最终还是数据的最终完整性问题。
首先，让我们回到最简单的案例。 如果只有一个MySQL数据库，该如何保证数据的一致性？ 了解数据库的人，这由数据库的事务特性保证，事务具有以下四个特性：
原子一致性隔离持久性Durability持久性事务的ACID的四个特性不是本文的重点，因此不展开学术解说。 不懂的可以在以后的参考文献中去看[3]相关文章。 这里只提出一个问题，如果单个数据库事务能够确保数据完整性，那么MySQL作为主从体系结构引入时如何确保主从之间的数据完整性？
为了提供主从复制功能，MySQL引入了一个名为binlog的新日志文件，其中包含会引起数据更改的事件日志集合。 将binlog从库发送到主库，要求从日志事件中恢复数据并将其写入从库。 因此，从库的数据源是binlog。 这样，MySQL主库只需确保binlog与本地数据相匹配，就能确保主从机的数据相匹配。 忽略网络传输引起的主站不一致。 你知道如何确保本地数据的完整性是通过数据库事务的特性来实现的吗？ 请先看下图：
MySQL本身不提供事务支持，而是通过开放存储引擎接口和特定的存储引擎实现的。 更具体地说，支持MySQL事务的存储引擎是InnoDB。 存储引擎实现事务的常见方法基于重做日志和还原日志。 简单来说，重做日志记录事务已修改的数据，而还原日志记录事务前的原始数据。 因此，以下是执行一个事务时实际发生过程的简化。
首先记录还原/重做日志，以便日志永久保存在磁盘上。 更新数据记录，缓存操作，异步更新磁盘。 提交事务，并将提交记录写入重做日志。 如果在MySQL事务处理期间由于故障而中断，则可以使用重做日志重试事务处理，也可以使用还原日志回滚事务处理，以确保数据完整性。 它们由事务存储引擎完成，但binlog不在事务存储引擎范围内，而是由MySQL Server记录。 在中，必须确保binlog数据与重做日志的一致性，因此打开binlog后，实际事务的执行将增加一个步骤，如下所示：
首先记录还原/重做日志，以便日志永久保存在磁盘上。 更新数据记录，缓存操作，异步更新磁盘。 将事务日志持久化为binlog。 提交事务，并将提交记录写入重做日志。 这样，除非成功写入了binlog，否则必须回滚整个事务，但如果成功写入了binlog，则即使MySQL Crash成功，也可以恢复事务并完成提交。 为此，必须将binlog与事务相关联，但要保证主从数据的完整性，必须确保binlog与事务数据的完整性。 因此，binlog的写入过程必须包含在纯事务存储引擎的执行过程中，并作为内部分布式事务(xa事务)完成两个阶段的提交。 因为不会展开更多的详细内容，所以请参考后面的参考文献[5]。
总结我们之前提出了问题，然后从数据完整性的角度考虑，参考了MySQL的实现方式。 明确分析了MySQL独立环境如何保证复制机制的数据一致性，即binlog和事务数据的一致性。 然后，可以基于binlog机制实现复制，以确保主从复制的一致性。 主从复制还引入了网络元件，进一步增加了保证主从数据完整性的复杂性，文章将在以后进一步分析这一问题。
[1]参见mysqlinternalsmanual.replication。
[2] mysqlinternalsmanual.thebinarylog。
[3] in355hz .数据库ACID的实现。
[4] jb51. MySQL对binlog的处理说明。
[5]浅析repls.innodb _ support _ xa和innodb_flush_log_at_trx_commit。
[6] 68idc. MySQL 5.6的DBA和开发人员指南。
以下是我微信的公众号“每时每刻”，不仅有科技文章，还有产品、行业和人生的思考。 希望能和走在这条路上的很多同行交流。