如何提升replication的性能：
延迟 ：
对于mysql replication来说，在没有发生故障的情况下，出现master与slave数据不同步，延迟分为以下两种情况：
经常性延迟 ： 异步同步的数据差距比较大 ，周期性的，循环。
暂时性延迟 ： 突发情况，导致延迟
其主要原因就是：
网络带宽
I/O
如何减少replication延迟？？
1，最好使用内网或者专线链路传输binlog数据 （千兆网卡、还不够的话，bounding 技术，扩展带宽） 在my.cnf中强制使用内网ip传输数据bind-address=ip
2，将二进制保存在独立的存储介质上（提升I/O）
3，买多核CPU，使用多线程方式传输二进制日志 （）
4，如果二进制日志不是row格式，则尽可能不要再insert 或者update的时候使用select ，statement模式会给master传输二进制时候造成大的压力
5，想尽办法减少master的写I/O（memcached）（既要写自己的二进制日志，也要负责读自己的二进制日志写给slave服务器），master上的I.O越低，越能快的将binlog传输给slave、
加memcached 缓存层，数据库上次做个缓冲池放到内存中，由memcached管理，周期性的将数据同步给数据库，把大并发的写操作，合并成小量的写操作。以此减少master写I/O
架构设计1：
主从服务器可以使用不同的存储引擎，master上使用innodb，利用事务，行锁等高级锁特性，slave上使用MYISAM，读性能更好，节省内存，容易备份。还可以使用不同的数据类型，例如
master上用varchar,slave上用char。不仅节省空间，还可以使用myisam的静态表特性。
M-S--Muti SLAVE方案中，中继slave还可以使用blackhole存储引擎，blackhole存储引擎值记录日志，不写数据，此特性可以让中继日志性能提升很多，但是，这种方案不支持GTIDs模式下的
replication，因为blackhole只能搭配statement格式的二进制日志使用，row和mixed格式都不支持。
在读写分离中，主存服务器采用不同索引采用不同方案，master可以只保留主键或者唯一索引等保证数据关系的索引，而slave针对查询做索引优化、
架构设计2：
让更新频繁，且需要实时的数据查询放到master上，再通过持久化session，让发生修改的用户先看到结果，其他人等待同步完后同步replication，
如果开发做不到，用下面的memcached，在数据之前加上memcached
让用户对数据库的更改先保存到memcached中，memcached是一种内存中的存储引擎（独立第三方技术），由于内存的读写性能很高 ，可以把读写特别频繁的更新数据保存到这里，每隔5分钟
，再把数据同步到master，对于另一个客户端来说，让他优先到master找数据，即在master上的memcached中读数据，在读slave。这样可以优先将更改的数据由内存返回给用户，这样降低了
降低硬盘IO，对于那些已经同步后数据把他分离到slave，这样master就可以转们做有关于的数据更新的写操作，完全分离了master的读。
动态缓存是讲用户请求比较频繁的动态数据缓存到memcached中，使得后续的访问用户可以直接从memcached中取数据
replication容量：
是指：replication延迟程度、
将replication暂停一段时间（M），再重新开启，并观察slave多久可以达到于master一致（N）
replication容量=N：M
建议保持容量在3倍以上，即1:3 （1小时的M，20分钟的N）
多线程传输二进制日志：
mysql5.6开始支持多线程方式传输二进制日志
只能工作在GTIDs 模式下
只有对不同的库执行的操作才能采用多线程传输。同一个库不同表的操作只能单独用单进程传输。
my.cnf
[mysqld]
slave-parallel-workers=N 默认是0 表示不开启 线程数
N 根据CPU的核数来决定，几核就写几，和数据库的数量一一对应，几个库就是几个线程来传输二进制日志 ，qps上万的话，多线程传输会有很明显的性能提升
