mysql主从复制，数据量大， 高并发时，出现数据不一致

mysql5.7的并行复制就可以解决数据延迟的问题。

MySQL 5.7并行复制时代

众所周知，MySQL的复制延迟是一直被诟病的问题之一，然而在Inside君之前的两篇博客中（1，2）中都已经提到了MySQL 5.7版本已经支持“真正”的并行复制功能，官方称为为enhanced multi-threaded slave（简称MTS），因此复制延迟问题已经得到了极大的改进，甚至在Inside君所在的网易电商应用中已经完全消除了之前延迟长达几小时的问题。然而，Inside君发现还是有很部分小伙伴不了解这个足以载入史册的“伟大”的特性，故作分享。总之， 5.7版本后，复制延迟问题永不存在 。

MySQL 5.6并行复制架构

诚然，MySQL 5.6版本也支持所谓的并行复制，但是其并行只是基于schema的，也就是基于库的。如果用户的MySQL数据库实例中存在多个schema，对于从机复制的速度的确可以有比较大的帮助。MySQL 5.6并行复制的架构如下所示：

在上图的红色框框部分就是实现并行复制的关键所在。在MySQL 5.6版本之前，Slave服务器上有两个线程I/O线程和SQL线程。I/O线程负责接收二进制日志（更准确的说是二进制日志的event），SQL线程进行回放二进制日志。如果在MySQL 5.6版本开启并行复制功能，那么SQL线程就变为了coordinator线程，coordinator线程主要负责以前两部分的内容：

• 若判断可以并行执行，那么选择worker线程执行事务的二进制日志
• 若判断不可以并行执行，如该操作是DDL，亦或者是事务跨schema操作，则等待所有的worker线程执行完成之后，再执行当前的日志

这意味着 coordinator线程并不是仅将日志发送给worker线程，自己也可以回放日志 ，但是所有可以并行的操作交付由worker线程完成。coordinator线程与worker是典型的生产者与消费者模型。

上述机制实现了基于schema的并行复制存在两个问题，首先是crash safe功能不好做，因为可能之后执行的事务由于并行复制的关系先完成执行，那么当发生crash的时候，这部分的处理逻辑是比较复杂的。从代码上看，5.6这里引入了Low-Water-Mark标记来解决该问题，从设计上看（ WL#5569 ），其是希望借助于日志的幂等性来解决该问题，不过5.6的二进制日志回放还不能实现幂等性。另一个最为关键的问题是这样设计的并行复制效果并不高，如果用户实例仅有一个库，那么就无法实现并行回放，甚至性能会比原来的单线程更差。而 单库多表是比多库多表更为常见的一种情形 。

MySQL 5.7并行复制原理

MySQL 5.7基于组提交的并行复制

MySQL 5.7才可称为真正的并行复制，这其中最为主要的原因就是slave服务器的回放与主机是一致的即master服务器上是怎么并行执行的slave上就怎样进行并行回放。不再有库的并行复制限制，对于二进制日志格式也无特殊的要求（基于库的并行复制也没有要求）。