Question

一、缘起

mysql 主从复制，读写分离 是互联网用的非常多的 mysql 架构，主从复制最令人 诟病 的地方就是，在数据量较大并发量较大的场景下，主从延时会比较严重。

为什么 mysql 主从延时这么大？

回答：从库使用【单线程】重放 relaylog。

优化思路是什么？

回答：使用单线程重放 relaylog 使得同步时间会比较久，导致主从延时很长，优化思路不难想到，可以【多线程并行】重放 relaylog 来缩短同步时间。

mysql 如何“多线程并行”来重放 relaylog，是本文要分享的主要内容。

二、如何多线程并行重放 relaylog

通过多个线程来并行重放 relaylog 是一个很好缩短同步时间的思路，但实施之前要解决这样一个问题：

如何来分割 relaylog，才能够让多个 work-thread 并行操作数据 data 时，使得 data 保证一致性？

首先，【随机的分配 relaylog 肯定是不行的】，假设 relaylog 中有这样三条串行的修改记录：
update account set money=100 where uid=58;
update account set money=150 where uid=58;

update account set money=200 where uid=58;

串行执行 ：肯定能保证与主库的执行序列一致，最后得到 money=200

随机分配并行执行 ：3 个工作线程并发执行这 3 个语句，谁最后执行成功是不确定的，故得到的数据可能与主库不同

好，对于这个问题，可以用什么样的思路来解决呢（大伙怎么想，mysql 团队其实也就是这么想的）

【方法一：相同库上的写操作，用相同的 work-thread 来重放 relaylog；不同库上的写操作，可以用多个 work-thread 并发来重放 relaylog】

如何做到呢？

回答 ：不难，hash(db-name) % thread-num，库名 hash 之后再模上线程数，就能够做到。

存在的不足？

很多公司对 mysql 的使用是“单库多表”，如果是这样的话，仍然是同一个 work-thread 在串行执行，还是不能提高 relaylog 的重放速度。

优化方案 ：将“单库多表”的模式升级为“多库多表”的模式。

其实，数据量大并发量大的互联网业务场景，“多库”模式还具备着其他很多优势，例如：

（1）非常方便的实例扩展：dba 很容易将不同的库扩展到不同的实例上

（2）按照业务进行库隔离：业务解耦，进行业务隔离，减少耦合与相互影响

（3）…

对于架构师进行架构设计的启示是： 使用多库的方式设计 db 架构，能够降低主从同步的延时 。

新的想法：“单库多表”的场景，还有并行执行优化余地么？

仔细回顾和思考，即使只有一个库，数据的修改和事务的执行在主库上也是并行操作的，既然在主库上可以并行操作，在从库上为啥就不能并行操作，而要按照库来串行执行呢（表示不服）？

新的思路 ：将主库上同时并行执行的事务，分为一组，编一个号，这些事务在从库上的回放可以并行执行（事务在主库上的执行都进入到 prepare 阶段，说明事务之间没有冲突，否则就不可能提交），没错，mysql 正是这么做的。

【方法二：基于 GTID 的并行复制】

新版的 mysql，将组提交的信息存放在 GTID 中，使用 mysqlbinlog 工具，可以看到组提交内部的信息：

20160607 23:22 server_id 58 XXX GTID last_committed=0 sequence_numer=1
20160607 23:22 server_id 58 XXX GTID last_committed=0 sequence_numer=2
20160607 23:22 server_id 58 XXX GTID last_committed=0 sequence_numer=3
20160607 23:22 server_id 58 XXX GTID last_committed=0 sequence_numer=4

和原来的日志相比，多了 last_committed 和 sequence_number。

last_committed 表示事务提交时，上次事务提交的编号，如果具备相同的 last_committed，说明它们在一个组内，可以并发回放执行。

三、结尾

从 mysql 并行复制缩短主从同步时延的思想可以看到，架构的思路是相同的：

（1） 多线程 是一种常见的缩短执行时间的方法

（2）多线程并发分派任务时必须保证 幂等性 ：mysql 的演进思路，提供了“按照库幂等”，“按照 commit_id 幂等”两种方式，思路大伙可以借鉴

另，mysql 在并行复制上的逐步优化演进：

mysql5.5 -> 不支持并行复制，对大伙的启示：升级 mysql 吧

mysql5.6 -> 按照库并行复制，对大伙的启示：使用“多库”架构吧

mysql5.7 -> 按照 GTID 并行复制

我不是 mysql 的开发人员，也不是专业的 dba，本文仅为一个思路的分享，希望大伙有收获，如果不对也欢迎随时指出。