如何解决主从数据库同步延迟问题？

如何解决主从数据库同步延迟问题？

前言

• 最近，系统上频繁出现主从延迟的问题，因此针对主从架构、主从同步以及主从延迟问题进行了一次学习。

主从架构浅析

• 在了解主从延迟之前，我们有必要对主从架构有一些简单的认识。在如今的互联网架构中，单点数据库架构往往不能满足日常的访问请求。为了增大系统的吞吐量、实现高可用架构，系统数据库往往会采用集群搭建。而集群架构中，最常见的就是主从架构。

常见主从架构介绍

• 主从架构作为最常见的集群搭建模式，通过将读写分离，来避免所有的请求都请求到同一个数据库上，从而减少单个数据库的压力。其次，通过对从库进行水平的扩展，也会使得系统的伸缩性及负载能力得到提升。常见的主从架构主要有以下几种：

• 一主一从式

• 一主一从为最常见的主从架构模式，由一个主节点+一个从节点组合而成，当主节点宕机时，从节点可以快速接替主节点的工作。

• 

• 一主多从式

• 该架构有一个主节点+多个从节点组成，适合读较多的场景，可以将读命令分摊到多个从节点。

• 

• 在一主多从的基础上，为了减轻主库向从库同步数据的压力，还出现了树状主从/级连复制的架构：

• 

• 多主一从

• 在一些需要汇总数据进行分析，或写入压力较大的情况，会采用多主一从的架构模式。该架构由多个主节点+一个从节点组成。

• 

• 主主互 备式

• 主主互备的架构模式，主要由两个或多个的主节点构成，每个主节点的更新操作都需要向其余的主节点进行同步。优点是读写的压力均可以通过负载均衡进行分摊，提升系统的吞吐量，且其中一个节点宕机，也不会影响整个系统，实现高可用。

• 

• 但是这种模式也存在缺陷。在实现数据双向同步的过程中，双向复制可能会带来延迟问题，极端情况下有可能数据丢失。另外，数据库数量增加会导致数据同步问题变得极为复杂

主从同步

• 聊完了常见的主从架构，那么这些架构，都是如何实现的主从数据库数据的同步的呢？以下就以mysql数据库为例子进行学习、了解。在mysql中，实现主从同步有两个比较重要的日志文件：binLog和relayLog。

binlog

• binlog，又称为二进制日志文件。简要来说，binLog主要记录当前数据库发生了什么。其主要日志格式有三种：statement、row 和 mixed，
• statement：statement又被称为基于SQL语句的复制。在该格式下，binlog内会记录执行的SQL原文。但在一些极端的情况下，可能会因为主从数据库的配置、索引等，同一句SQL可能执行出来的结果是不一致的。
• row：row又被称为基于行的复制，故名思义，row模式下记录的不是SQL的原文，而是记录的SQL语句影响的数据。例如哪一行数据被删除了、哪一行数据从a更新成了b等等。这样可以避免因为执行SQL的环境不同导致的数据不一致，但是缺陷就是会产生大量的日志文件。
• mixed：从5.1.8版本开始，MySQL提供了Mixed格式，实际上就是statement与row的结合。在该模式下，一般的语句修改使用statement保存binlog，但是一些函数statement无法完成主从复制，那么此时就会使用row格式进行保存。
• 具体的，我们可以使用语句show binary logs来查看当前数据库的binlog。

relayLog

• relayLog，又被称为中继日志。简单来说，relayLog中主要保存了从主节点中查询出来的binlog数据，供从节点在同步的过程中使用。

同步原理分析

• 

• 在了解了binLog及relayLog之后，我们就可以开始了解mysql是如何进行数据同步的了。如图所示，mysql的同步过程主要有以下几个步骤：

• 主节点产生数据变更，此时会将变更内容写入binLog，同时会开启binlog dump线程将更新的数据信息同步给从库。

• 从节点的I/O线程读取到变更的数据后，会将数据写入relayLog。

• 从节点的SQL线程检测到relayLog中添加了数据后，会将新增的数据写入到从库中，从而实现主从数据的同步。

主从延迟

• 了解了主从同步的原理，我们就来了解下什么是主从延迟。主从延迟简单来说，是因为在一定时间内，主节点此时已经完成了数据的写入，但是此时从库还没有将主库的数据同步更新完成。
• 结合上述的主从同步原理，不难推断造成主从延迟主要是源于以下几个方面之一：
• 主节点binLog数据未及时同步
• 从节点I/O线程未及时将数据写入RelayLog
• 从节点SQL线程未及时将RelayLog写入数据库
• 针对这三个方面，我们逐一分析可能导致主从延迟的原因。

主从延迟的原因

主节点binLog数据未及时同步

• 针对主库binLog数据没及时同步造成主从延迟的情况，可能性主要有如下几个：
• 主库存在高并发，某一时刻，大量的写请求到主库上，意味着binLog需要进行频繁的写入及同步，此时就可能导致主节点binlog dump线程、从节点I/O线程没法及时同步，从而造成主从延迟。
• 网络IO存在问题，某一时刻如果网络IO挂掉了，数据没法发送到从库，那么此时也会导致从库的数据无法更新，造成主从延迟。
• 执行大事务，一旦执行大事务，主库必须等到事务执行完成之后才能写入binLog，进而也会影响后续的binLog的同步及写入，造成主从延迟。

I/O线程未及时写RelayLog

• 针对从节点I/O线程未及时写入RelayLog情况，其主要的可能性是
• 存在高并发，I/O线程未能及时将数据刷入到relayLog中。但I/O线程通常为磁盘读写，效率较快，一般不会成为主要的问题。
• 机器性能较差，导致relayLog同步速度较慢。

SQL线程未及时写数据库

• 针对这最后一种情况，产生主从延迟的原因可能更多一些：
• relayLog随机重放。在主库中写binlog及从库中写relayLog都是顺序进行的磁盘读写，效率较高。但是SQL数据对relayLog进行数据重放的时候是随机写盘的，执行效率相对较慢，从而出现主从延迟。
• 锁等待，从库除了同步以外还会需要支持正常的业务查询操作，而如果当前需要修改的数据被访问了，那么此时SQL线程就会先进行等待，直到锁被释放以后，再获取锁进行修改。而这一段时间，就有可能导致主从延迟。
• 高并发，高并发情况下产生的DML数量超过了SQL Thread所能处理的速度时，那么此时就会产生主从延迟。
• 出现慢SQL，慢SQL会导致relayLog较久才能写入到数据库中，进而造成主从延迟。

如何解决主从延迟

• 了解了出现主从延迟的原因，那么如何对主从延迟进行解决呢？可行的方案我这里简单总结了三个：

强一致性方案

• 最简单粗暴的方案，其实就是针对一些实时性要求比较高的操作，通过代码指定的方式，强行让查询语句走主库进行查询。这样可以保证数据的绝对准确，带来的问题是会加大主库的并发数量，增加宕机的风险。

并行复制

• 这种方案主要针对高并发情况下从库SQL单线程出现瓶颈的时候使用，将SQL线程转化成多个线程来进行重放，加快对DML数据的处理速度，从而减缓主从延迟。mySql自5.7版本后就已经支持并行复制了。可以在从服务上设置 slave_parallel_workers为一个大于0的数，然后把slave_parallel_type参数设置为LOGICAL_CLOCK即可。

降低并发

• 针对过高的并发，其实会导致同步过程的三个阶段都会出现问题，为此，在接口设计时，要充分考虑接口的请求量，并适当采用如令牌桶、漏桶算法等进行限流。或采用分布式锁等对关键数据进行加锁，控制并发量，减少主从延迟对业务的影响。

增加NOSQL层

• 通过在从库前增加NOSQL层来缓解，主库写入SQL的时候，按照一定策略将关键数据放入到缓存中，查询时优先查询缓存中的数据。可以在一定程度上减少主从延迟所带来的问题。

总结

• 归根结底来说，在主从架构下，主从延迟其实是不可避免的（只是延迟的时间长短）。但是通对主从延迟原因的合理分析以及的合适方案选择，可以最大程度上缩短主从同步时间，最大程度减少主从延迟给系统、服务带来的影响的。