1.主从复制延迟产生的主要原因
主要是第3、第4和第6点，第3点我们所能做的就是避免大事务(通俗的讲执行时间久的事务)的执行，那么接下来我们就针对第4和第6点来解决延迟问题
2.从根本上解决主从复制的延迟问题
我上篇博客主从复制原理及延迟原因说到，里面的I/O thread和SQL thread都是单线程的，所以我们要解决这延迟问题，我们可以把SQL thread单线程变为多线程，于是MSYQL5.6版本之后就引入了并行复制的概念，就是从读取replay到操作真实数据过程中加了一个多线程和协调器coordinator，当日志来了之后，协调器负责读取日志信息以及分发事务，真正的日志执行的过程是放在了worker线程上，由多个线程并行的去执行
2.1 此时我们要思考两个问题
1.在并发操作的时候，可能会有并发的事务问题，我们备库在执行的时候可以按照轮训的方式发送给各个worker吗?
2.同一个事务的不同sql语句，可不可以分发给不同的worker执行？
这就涉及到协调器的分发规则了。
我们来举两个例子来说明
上面产生了2个日志，如果协调器把a日志分发给work1，把b日志分发给work2，此时如果work2比work1先执行，那么就会发现数据的逻辑错乱，这是不行的
第二个例子
事务A对不同表不同行进行更新操作，假设第一条语句分发给worker1，第二条语句分发给worker2,因为分发是随机的，work1执行成功，work2还没执行成功，此时来个查询语句，查询到的是“更新一半”的数据，就破坏了对隔离性的基本要求
所以我们要制定规则
1.更新同一行的多个事务，必须要分发到同一个worker中执行
2.同一个事务不能被拆开，必须要放到同一个worker
2.2 上面的规则是必须遵循的，那么给你设计这个并行复制呢，你认为要怎么设计呢？
我们要考虑并行粒度的问题，这里有库级别、表级别和行级别
那么是多表事务怎么办？
2.3慢慢的演变就提供另外的一种方式，GTID,这里简单描述一下它的组成(有兴趣的可以去了解一下)**
