一、问题起源
mysql的主从同步一直有从库延迟的问题，背景资料网上很多，原因简单描述如下：
1、 mysql从库上有一个io线程负责从主库取binlog到写到本地。另外有一个sql线程负责执行这些本地日志，实现命令重放；
2、 正常网络状况下io线程没有性能问题（这个待会会用到），问题是sql线程只有一个，更新速度跟不上。所以经常会看到从库的cpu idle很高，但同步性能就是上不去。
二、方案雏形
单线程的sql线程是造成这个问题的主要原因。比较直接的想法是把它改成多线程版本，这个据说官方版本开发中，其实我们也有一个这样的patch，但是直接写大片代码在线上提供服务的slave机器上这种事儿，都会因为担心稳定性而很难推动（写patch的和运维的同学，你们懂的）。
所以打算用一个“第三方”工具中转，来实现多线程同步。基本结构如下：
说明：
1、这些transefer从master上各自同步一部分的数据，分别独立更新slave。多进程还是多线程均可。
2、transfer与master之间异步更新日志，transfer与slve之间同步更新数据
3、从这可以看出这个方案的缺点之一：更新能够被独立分开。比较直观的想法是，按照表分。
三、关于transfer
作为这个关键的转发工具transfer，需要提供如下功能：
1、能够指定同步master中的哪部分数据，并且能够方便地修改这个配置以应对master的加表需求；
2、支持stop slave、start slave。支持快速切换到新主库的change master命令。
3、能够记录读取点，transfer自己重启或master重启后能够按照记录点继续读后面的binlog；
4、能够记录分发点，transfer自己重启或slave重启后能够按照记录点继续同步给slave
用起来就会发现还有好多要求。。。
四、方案实现
transfer的这么多功能，自己造轮子就累了。这里直接用mysql来充当此角色。为了方便描述，下文还将之称为transfer。transfer更新slave在功能上可以使用federated引擎，但由于其纠结的实现导致性能上达不到要求，因此在mysql框架层中作了一点修改