一、并行复制的原理：

 

很多码友在自己线上的业务系统中都使用了mysql的主从复制，但是大家需要注意的是，并不是所有的场景都适合主从复制，一般情况下是读要远远多于写的应用，同时读的时效性要求不那么高的场景。如果真实场景中真的要求立马读取到更新之后的数据，那么就只能强制读取主库的数据，所以在进行实现的时候要考虑实际的应用场景，不要为了技术而技术，这是很严肃的事情。

 

在mysql5.6版本之后引入了一个概念，就是我们通常说的并行复制，如下图：

 

通过上图我们可以发现其实所谓的并行复制，就是在中间添加了一个分发的环节，也就是说原来的sql_thread变成了现在的coordinator组件，当日志来了之后，coordinator负责读取日志信息以及分发事务，真正的日志执行的过程是放在了worker线程上，由多个线程并行的去执行。

 

-- 查看并行的slave的线程的个数，默认是0.表示单线程

 

show global variables like 'slave_parallel_workers';

 

-- 根据实际情况保证开启多少线程

 

set global slave_parallel_workers = 4;

 

-- 设置并发复制的方式，默认是一个线程处理一个库，值为database

 

show global variables like '%slave_parallel_type%';

 

-- 停止slave

 

stop slave;

 

-- 设置属性值

 

set global slave_parallel_type='logical_check';

 

-- 开启slave

 

start slave

 

-- 查看线程数

 

show full processlist;

 

1、 通过上述的配置可以完成我们说的并行复制，但是此时你需要思考几个问题

 

1）、在并行操作的时候，可能会有并发的事务问题，我们的备库在执行的时候不可以按照轮训的方式发送给各个worker，原因如下：

 

因为事务被分发给worker以后，不同的worker就开始独立执行了，但是，由于CPU的不同调度策略，很可能第二个事务最终比第一个事务先执行，而如果刚刚好他们修改的是同一行数据，那么因为执行顺序的问题，可能导致主备的数据不一致。

 

2）、同一个事务的多个更新语句，不能分给不同的worker来执行，原因如下：

 

比如一个事务更新了表t1和表t2中的各一行，如果这两条更新语句被分到不同worker的话，虽然最终的结果是主备一致的，但如果表t1执行完成的瞬间，备库上有一个查询，就会看到这个事务更新了一半的结果，破坏了事务逻辑的隔离性。

 

2、我们通过讲解上述两个问题的最主要目的是为了说明一件事，就是coordinator在进行分发的时候，需要遵循特定的策略：

 

1）、不能造成更新覆盖。这就要求更新同一行的两个事务，必须被分发到同一个worker中。

 

2）、同一个事务不能被拆开，必须放到同一个worker中。

 

分析完上面的描述，我们来说一下具体实现的原理和过程：

 

如果让我们自己来设计的话，我们应该如何操作呢？这是一个值得思考的问题。其实如果按照实际的操作的话，我们可以按照粒度进行分类，分为按库分发，按表分发，按行分发。