一、背景
1.1传统主从复制存在的问题
众所周知，MySQL的从库可以做业务的线性扩展、实现读写分离、数据备份等功能。但是当主库压力比较大的时候，就会产生一个让人头疼的问题，那就是主从复制延迟。主从复制延迟会导致从库数据落后于主库，产生诸多问题。
1.2降低复制延迟的方法
·增大从库innodb_buffer_pool_size的值,使从库可以缓存更多数据，降低IO压力。
·增大innodb_log_file_size、innodb_log_files_in_group的值，降低刷盘IO，提升写入性能。
·将innodb_flush_method设置为O_DIRECT，提升写入性能。
·如果没有特殊需求，关闭从库binlog。
·将参数master_info_repository和relay_log_info_repository设置为TABLE，降低IO压力。
上文这些方法虽然可以降低复制延迟，但是这始终无法真正解决复制延迟问题。
二、MySQL5.6的多线程复制
除了上文的优化方法，其实MySQL还有一种自带的手段，就是开启MySQL的多线程复制。
2.1MySQL5.6多线程复制的实现
对于某一个库来说，它会被绑定到第一个执行它的线程上，这里的绑定不是说以后该数据库的事件都会由该线程执行，还受制于另一个条件：coordinator线程分配事件时以事务为单位，一个事务会分配给该事务中第一个库所绑定worker线程，不会被拆分。如果遇到一个新的库，不能按照上面的规则决定执行的数据库的（即没有绑定线程，而且是该事务中第一个库）则会寻找绑定库最少的worker线程来执行它。
涉及多库操作的语句，在分配这个语句时，coordinator线程会等待这些库的绑定线程都执行完毕，然后再分配这个语句。而如何涉及到的库太多（大于254）或者是一个ddl语句，则会触发一次同步操作，即等待所有线程执行完毕，然后将它分配给0号worker线程。
2.2MySQL5.6的多线程复制的缺点
MySQL5.6的多线程复制要求数据库数量比较多，并且各个库的数据要分布均匀。换句话说，MySQL5.6的多线程复制是基于库级别的，如果binlog row event操作的是不同的schema的对象，在没有DDL的情况下，就可以实现多线程复制。
但是在实际业务场景中，一库多表很常见，多库少表却很少见。这个原因导致MySQL5.6的多线程复制并不适合在实际环境应用，但是不得不承认这的确一个解决复制延迟问题很好的手段。
三、MySQL5.7的多线程复制
MySQL5.6的多线程复制在实际应用起到的作用却很小。直到MySQL5.7版本，MySQL才“真正”支持多线程复制功能，官方称为为enhanced multi-threaded slave（简称MTS）。
3.1MySQL的组提交
在介绍MySQL5.7的多线程复制前，我要先介绍一下组提交。MySQL5.7相对于MySQL5.6在GTID中增加了两个事件（last_committed和sequence_number），根据这两个事件就可以明白什么是组提交：
#190528 9:50:18 server id 330601 end_log_pos 971 CRC32 0x0d6b7893 GTID last_committed=2 sequence_number=3 rbr_only=yes
#190528 9:50:23 server id 330601 end_log_pos 1288 CRC32 0x02f70237 GTID last_committed=3 sequence_number=4 rbr_only=yes
#190528 9:50:24 server id 330601 end_log_pos 1605 CRC32 0xd613b4bf GTID last_committed=4 sequence_number=5 rbr_only=yes 可以看到以往binlog中下一个事务的last_committed永远都和上一个事务的sequence_number是相等的。
#190629 21:21:07 server id 330601 end_log_pos 1420595 CRC32 0xee9fca87 GTID last_committed=3460 sequence_number=3506 rbr_only=yes
#190629 21:21:07 server id 330601 end_log_pos 1420998 CRC32 0x64a67854 GTID last_committed=3460 sequence_number=3507 rbr_only=yes
#190629 21:21:07 server id 330601 end_log_pos 1421401 CRC32 0x89930386 GTID last_committed=3460 sequence_number=3508 rbr_only=yes 在MySQL5.7开启组提交的binlog中各事务的last_committed是相同的，这意味着多个事务是作为一个组提交的，这些事务在perpare阶段获取相同的last_committed而且相互不影响，最终是会作为一个组进行提交。这就是所谓的组提交。
MySQL5.7的组提交通过参数group_commit设置。
mysql> show variables like '%group_commit%';
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+
2 rows in set (0.00 sec)
binlog_group_commit_sync_delay控制着日志在刷盘前日志提交要等待的时间，0代表提交后立即刷盘，当设置为N（大于0）的时候，就允许多个事务的日志同时间一起提交刷盘，也就是我们说的组提交。组提交是多线程复制的基础。
binlog_group_commit_sync_no_delay_count ，这个参数优先于binlog_group_commit_sync_delay，在等待时间内，如果事务数达到binlog_group_commit_sync_no_delay_count的值，就会触动一次组提交。3.2MySQL5.7多线程复制的实现
MySQL期望最大化的还原主库的并行度，实现方式是在binlog event中增加必要的信息（last_committed和sequence_number），以便slave节点根据这些信息实现多线程复制。
MySQL5.7使用参数slave_parallel_type来兼容5.6的多线程复制；通过参数slave_parallel_workers指定多线程复制的线程数。
mysql> show variables like '%slave_parallel_type%';
+---------------------+---------------+
| Variable_name | Value |
+---------------------+---------------+
| slave_parallel_type | LOGICAL_CLOCK |
+---------------------+---------------+
1 row in set (0.01 sec)
mysql> show variables like '%slave_parallel_workers%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| slave_parallel_workers | 8 |
+------------------------+-------+
1 row in set (0.01 sec)
MySQL5.7的多线程复制建立在group commit的基础上，所有在主库上能够完成prepared的语句表示没有数据冲突，就可以在slave节点多线程复制。
四、MySQL事务提交方式及多线程复制分发
4.1MySQL5.7中事务提交方式
binlog的组提交是通过 Stage_manager 管理，其中比较核心内容如下：
class Stage_manager {
public:
enum StageID { // binlog的组提交包括了三个阶段
FLUSH_STAGE,
SYNC_STAGE,
COMMIT_STAGE,
STAGE_COUNTER
};
private:
Mutex_queue m_queue[STAGE_COUNTER];
};binlog的组提交的三个阶段主要执行的工作内容为：
InnoDB, Prepare
SQL已经成功执行并生成了相应的redo和undo内存日志；
Binlog, Flush Stage
所有已经注册线程都将写入binlog缓存；
Binlog, Sync Stage
binlog缓存将sync到磁盘，sync_binlog=1时该队列中所有事务的binlog将永久写入磁盘；
InnoDB, Commit stage
leader根据顺序调用存储引擎提交事务； 每个阶段都有各自的队列，从而使每个会话的事务进行排队，提高并发性能。如果当一个线程注册到一个空队列时，该线程就做为该队列的leader，后注册到该队列的线程均为follower，后续的操作都由leader控制队列中follower行为。
leader同时会带领当前队列的所有follower到下一个阶段 去执行，当遇到下一个阶段为非空队列时，leader会变成follower注册到此队列中。
4.2多线程复制分发原理
当slave_parallel_workers参数设置成n时，会有n个worker线程，由它来执行event，原来的sql线程变成coordinator线程，由它来读取relay log，并按照一定规则将读到的event分配给worker线程执行。从库是以事务为单位进行APPLY的，每一个事务有一个GTID事件，都有一个last_committed和sequence_number，多线程复制分发原理如下：
1、从库SQL线程读取一个新事务，拿出last_committed和sequence_number的值。
2、判断当前last_committed是否大于当前已经执行的sequence_number的最小值。如果大于，则说明上一组事务还没有完成，需要等待last_committed等于sequence_number后继续；否则说明当前事务和正在执行在同一组，直接继续。
3、SQL线程寻找worker线程，将当前事务交给worker，worker线程去APPLY这个事务。
五、总结
多线程复制从MySQL5.6到MySQL5.7的发展，真正地实现多线程复制，解决了复制延迟问题！
