架构与思维：高并发下解决主从延时的一些思路：《叶子楣喂奶》

作者：翁智华出处：回顾下MySQL主从复制主从复制，是指建立一个和主数据库完全一样的数据库环境（称为从数据库），并将主库的操作行为进行复制的过程：将主数据库的DDL和DML的操作日志同步到从数据库上，然后在从数据库上对这些日志进行重新执行，来保证从数据库和主数据库的数据的一致性。

1.1为什么要做主从复制1、在复杂的业务操作中，经常会有操作导致锁行甚至锁表的情况，如果读写不解耦，会很影响运行中的业务，使用主从复制，让主库负责写，从库负责读。

即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运行。

2、保证数据的热备份，主库宕机后能够及时替换主库，保障业务可用性。

3、架构的演进：业务量扩大，I/O访问频率增高，单机无法满足，主从复制可以做多库方案，降低磁盘I/O访问的频率，提高单机的I/O性能。

4、本质上也是分治理念，主从复制、读写分离即是压力分拆的过程。

5、读写比也影响整个拆分方式，读写比越高，主从库比例应越高，才能保证读写的均衡，才能保证较好的运行性能。

读写比下的主从分配方法下：读写比（大约）主库从库50：501166.6：33.31280：20234------------1.2主从复制的原理当在从库上启动复制时，首先创建I/O线程连接主库，主库随后创建BinlogDump线程读取数据库事件并发送给I/O线程，I/O线程获取到事件数据后更新到从库的中继日志RelayLog中去，之后从库上的SQL线程读取中继日志RelayLog中更新的数据库事件并应用，如下图所示：细化一下有如下几个步骤：1、MySQL主库在事务提交时把数据变更（insert、delet、update）作为事件日志记录在二进制日志表（binlog）里面。

2、主库上有一个工作线程binlogdumpthread，把binlog的内容发送到从库的中继日志relaylog中。

3、从库根据中继日志relaylog重做数据变更操作，通过逻辑复制来达到主库和从库的数据一致性。

4、MySQL通过三个线程来完成主从库间的数据复制，其中binlogdump线程跑在主库上，I/O线程和SQL线程跑在从库上。

拥有多个从库的主库会为每一个连接到主库的从库创建一个binlogdump线程。

1.3主从延迟的原因MySQL主从复制，读写分离是我们常用的数据库架构，但是在并发量较大、数据变化大的场景下，主从延时会比较严重。

延迟的本质原因是：系统TPS并发较高时，主库产生的DML（也包含一部分DDL）数量超过Slave一个Sql线程所能承受的范围，效率就降低了。

我们看到这个sqlthread是单个线程，所以他在重做RelayLog的时候，能力也是有限的。

2几种解决方案2.1最优的系统配置优化系统配置（系统级、链接层、存储引擎层），让数据库处在最优状态：最大连接数、允许错误数、允许超时时间、pool_size、log_size等，保证内存、CPU、存储空间的扩容（硬件部分）。

倒金字塔法则告诉我们，这一块往往是被忽略的，但是又是必不可少的。

如果MySQL部署在linux系统上，可以适当调整操作系统的参数来优化MySQL性能，下面是对Linux内核参数进行适当调整。

1#TIME_WAIT超时时间，默认是60s2net.ipv4.tcp_fin_timeout=30