本篇文章给大家谈谈如何解决主从延迟，以及对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。

创建产品后立即跳转到详情页面。更新列表页面上用户的权限。立即刷新。如果这样操作后立即获取，就会出现问题。

为什么要有主从

MySQL数据库的主从架构主要是为了实现数据高可用性（High Availability）和读写分离。具体原因如下：

数据备份：主从架构可实现数据实时备份。从数据库可以作为主数据库的镜像存在。当主库出现问题时，可以快速切换到从库，保证数据安全。读写分离：主从架构中，主库主要负责写操作，从库主要负责读操作。这样可以分担主库的压力，提高系统的处理能力。故障切换：当主库出现故障时，可以快速切换到从库，保证服务连续性，提高系统可用性。负载均衡：通过主从架构，可以将读请求分发到多个从库，实现负载均衡，提高系统性能。

主从如何同步

下面是在主节点A上执行更新语句，然后同步到从节点B的完整流程图。

从库B和主库A之间保持长连接，主库A内部有一个线程，专门为从库B的长连接服务。事务日志同步的完整流程如下：

在从库B上使用change master命令设置主库A的IP、端口、用户名、密码以及开始请求binlog的位置。该位置包括文件名和日志偏移量。在从库B上执行start Slave命令，此时从库会启动两个线程，即图中的io_thread和sql_thread。其中io_thread负责与主库建立连接。主库A验证用户名和密码后，开始根据B库传过来的位置在本地读取binlog并发送给B。从B库拿到binlog后，写入本地文件，称为中继日志。 sql_thread读取传输日志，解析日志中的命令并执行它们。

为什么会主从延迟

什么是主从延迟？

主库A完成一笔事务，写入binlog。我们把这个时间记为T1；然后传给从库B，我们记下从库B收到binlog的时间为T2；从库B执行该事务，我们将该时刻记为T3。所谓主从延迟，就是同一事务从库执行完成的时间与主库执行完成的时间之差，即T3-T1。

可以在从库上执行show Slave Status命令，其返回结果会显示Seconds_Behind_Master，用于表示当前从库延迟了多少秒。

在某些部署情况下，从库所在机器的性能比主库所在机器差。来自图书馆的压力很大。例如，对从库的查询会消耗大量CPU资源，影响同步速度，造成主从延迟。大生意。因为主库必须等到事务执行完成后才写入binlog，然后传给从库。因此，如果主库上的一条语句需要10分钟才能执行，那么这个事务很可能会导致从库出现10分钟的延迟。大表DDL也是典型的大事务场景。

如何解决

一般主从结构如下：

一旦出现主从延迟问题，解决办法有以下几种

强制走主库方案 – 有点可行

对查询请求进行分类，如果必须获取最新结果，则强制请求到主数据库。优点：场景可区分，压力可控。缺点：前后端都需要修改。前端决定是否使用主库，服务端决定指定场景。主库的后续维护也比较麻烦。有时前端无法确定场景。例如，进入详情页时，前端无法判断跳转是刚刚创建的还是打开的跳转是否已经创建。全部使用主库。优点：简单方便。缺点：没有区分具体场景。主库压力很大。先读取从库，从库不读取主库。优点：比较简单。缺点：无法处理所有场景，比如列表场景，因为必须有数据。但不知道是否准确

sleep 方案 – 有点可行

前端延迟请求优点：简单方便缺点：用户体验不好编写相关接口，服务器返回结果详细信息，前端显示细节。例如，创建一个商品界面，服务器返回商品的详细信息，前端直接显示详细信息，而不需要请求该接口。优点：逻辑比较流畅、清晰。缺点：前端需要实现多套逻辑。比如，虽然是细节，但至少可能来自于创建和细节界面；会员从会员列表中删除成功后，不会直接显示，也不再调用列表接口。维护成本高。例如，对于详情页，如果后续的详情也发生了变化，那么创建和详情界面如何保持一致就无法处理所有场景，比如创建空间后获取会员列表（至少是自己）。

判断主从延迟方案 – 有的可行

写操作写入redis（过期时间1~2s）。读取时判断是否有redis，如果有则读取主库。如果您创建产品，请在redis中记录产品ID。获取详情时，首先判断redis中是否存在该商品ID。如果存在，则读取主数据库。优点：前端不需要改动，服务器端改动相对可控，而且设置为弱依赖，所以应该不能解决大部分问题。缺点：服务器需要根据场景记录和读取redis，有一定概率增加主库压力，但总体可控主从无延迟方案——不可行。每个从库执行查询请求之前，首先判断seconds_behind_master是否等于0，如果不等于0，则必须等到该参数变为0后才能执行查询请求。您可以使用显示从属状态。比较站点以确保主从之间没有延迟。比较GTID 集以确保主从之间没有延迟似乎不现实。

实施成本较高，且仍存在过期阅读问题。因为上面判断master和slave之间没有延迟的逻辑是“所有从从库收到的日志都已经执行完毕”。但从master和slave之间的binlog状态分析不难看出，仍然有部分日志处于客户端已收到提交确认，但从库尚未收到日志的状态。如果在业务更新的高峰期，主库的位置或者GTID集合更新得非常快，那么上述两个位置等价性判断永远不会成立，很可能会导致从库无法响应查询请求时间较长。无延迟方案+半同步方案可以解决过期读的问题。

semi-sync 有这样的设计：

当事务提交时，主库将binlog发送到从库；从库收到binlog后，向主库发送ack表示收到；主库收到ack后才可以向客户端返回“交易完成”。确认。这样半同步结合之前对位置的判断，就可以确定在从库上执行的查询请求，避免过期读。

但这个方案也是不现实的，并不能彻底解决问题。

semi-sync+位置判断方案仅适用于一主一从的场景。如果落在其他从库上，仍然会出现过期读等主库位置解决方案——不可行select master_pos_wait(file, pos[, timeout]);该命令的逻辑如下：

从从库执行；参数文件和pos指的是主库上的文件名和位置； timeout 是可选的，设置为正整数N，表示该函数最多等待N 秒。返回结果如下：

如果从同步线程执行过程中出现异常，将返回NULL；如果等待超过N秒，则返回-1；如果开始执行时，发现该位置已被执行，则返回0。正常返回的结果是一个正整数M，表示从命令开始执行到申请后的file和pos表示的binlog位置，已经执行了多少笔事务。如何使用

主库更新中trx1事务完成后，立即执行show master status，获取当前主库执行的File和Position；选择从库执行查询语句；在从库上执行select master_pos_wait(File, Position, 1)； if 返回值为正整数=0，那么在这个从库中执行查询语句不太现实。考虑一下实现的复杂性。

等待GTID解决方案-不可行select wait_for_execulated_gtid_set(gtid_set, 1);该命令的逻辑是：

等待传入的gtid_set包含在本库执行的事务中，返回0；超时返回1。等待GTID的执行流程为：

trx1交易更新完成后，直接从返回包中获取该交易的GTID，记为gtid1；选择一个从库执行查询语句；在从库上执行select wait_for_execulated_gtid_set(gtid1, 1)；如果返回值为0，则该从库执行查询语句；否则，到主库执行查询语句。