MySQL并行复制策略详解

  之前提到过，当备库执行大事务的时候可能会造成主从延迟，除此之外，当从库的binlog执行能力小于主库的时候，也会造成延迟。所以我们需要尽可能的让从库的执行采用并发的方式。
  在主库上，事务之间通过各种锁来控制并发执行的过程，在从库上，官方5.6版本之前，MySQL只支持单线程复制。由此在主库并发高、TPS高时就会出现严重的主备延迟问题。如果需要采用多线程进行复制，则要最重要的是解决如何分发任务的问题。采用轮询方式无法严格控制worker的执行次序（也就是被CPU调度的顺序），可能会发生数据不一致的问题。此外，同一个事务的更新语句也应在同一个worker上执行，否则会发生不同worker的commit时机不一致造成的破坏事务原子性的问题。
  为此，有两种策略可以使用
  1. 按表分发策略
  1.如果跟所有worker都不冲突，coordinator线程就会把这个事务分配给最空闲的woker;

  2.如果跟多于一个worker冲突，coordinator线程就进入等待状态，直到和这个事务存在冲突关系的worker只剩下1个；
  3. 如果只跟一个worker冲突，coordinator线程就会把这个事务分配给这个存在冲突关系的worker。
  这个机制的问题在于：如果碰到热点表，比如所有的更新事务都会涉及到某一个表的时候，所有事务都会被分配到同一个worker中，就变成单线程复制了。
  2. 按行分发策略
  通过hash的方式来计算并标识唯一访问的行：库名+表名+索引a的名字+a的值。
  这个计算过程需要解析binlog，耗费资源较多。当更新行数过多时，会退化成单线程模式。
  MySQL5.6中支持了按库的并发复制，而5.7中进一步提供了用slave-parallel-type来控制并行复制策略。