主从复制？

主从复制即将主数据库的变化（DDL和DML）操作，将相同的操作在从数据库执行一次。

执行步骤

1. 主数据库的数据变化写入到binlog
2. 从库连接主库
3. 从库创建I/O线程获取主库更新的binlog日志
4. 主库创建binlog dump线程发送binlog，从库I/O线程负责接收
5. 从库的I/O线程将接收到的binlog写入到relay log中。
6. 从库的SQL线程读取relay log同步数据本地（执行sql）

// todo mysql中的几种log日志，及其作用以及区别

如何避免主从延迟？

1.强制将读请求路由到主库处理

使用较多的场景。在从库未更新前，将读操作交给主库处理，不过会瞬间提高主库的压力。

实现组件：sharding-JDBC

2.延迟读取

对于一些允许延迟的场景可以使用。当主库更新后，则从库的数据读取延迟，当从库更新后，在进行读取，不过需要设置合理的延迟时间或监控策略，但是主从之间的延迟原因是多种多样的。所以一般还是用于对数据准确性要求不高以及允许延迟读取的场景。

主从延迟的原因以及减少延迟时间

主从复制主要原因主要有以下三种可能：

1. 从库的binlog与主库的binlog不一致，例如从库IO线程接收binlog的速度低于主库写入binlog的速度
2. 从库的relay log的速度与从库的binlog不一致，例如从库写入relay log速度低于从库IO线程接收binlog的速度
3. 从库执行的速度低于relay log写入的速度。

可能会导致上面情况的发生几种常见的实际情况：

1. 从库性能低于主库：这样会导致从库无论是binlog、relaylog、执行SQL可能都比主库慢，自然会产生延迟。解决方案可以是增加从库的规格，优化从库性能
2. 从库处理的读请求过多：大多数情况，读的请求一般是远远大于写请求的，一旦从库需要处理读请求过多，达到性能瓶颈，则会导致主从延迟。解决方案可以是合理增加从库，减少单个从库压力。使用缓存中间件，对于热点数据不再连接数据库，减少读压力
3. 大事务或慢SQL：当执行事务或者SQL的时间需要较长时间，当执行完成前，自然这段时间都是延迟的。解决方案：尽量优化，不执行慢SQL和大事务的场景，不大批量修改数据。
4. 从库太多：也是受限性能瓶颈，从库越多，则主库就需要消耗更多的线程去同步binlog日志，当主库达到性能瓶颈，自然会存在从库长时间接收不到binlog的情况。解决方案可以是减少从库，或者优化从库结构，划分从库层级，先给一级从库，一级从库再划分给二级从库，减少主库压力。
5. 网络延迟：主库到从库之间需要传输数据，如果网络延迟，自然主从数据库之间的延迟就越大。解决方案可以是提高带宽，优化网络环境
6. 单线程复制：使用多线程进行复制，这个需要mysql的版本支持，低版本只支持单线程 5.5及以下
7. 复制模式：mysql默认是异步复制，全同步性能较差，半同步复制模式是一种更好的选择，同样受限mysql版本 5.5以下