高并发下 Mysql 主从延迟处理方案
治标方案
一、针对网上的很多方案不外乎就是什么更改优化数据库配置，提升从库数据库服务器的配置。这两种方式都可以适当的降低主从延迟的时间。但是都没办法从根本上解决这个问题，当用户的量达到服务器配置的瓶颈的时候，主从延迟还是会出现，治标不治本。
二、在 mysql5.6 之前，主从复制采用的都是单线程的复制。mysql 官方在 5.6 之后加入了并行复制的功能，如果您采用的数据库版本是 5.6 之前的，也可以采用升级 mysql 数据库版本的方法。
三、另外如果上述方案都采用了之后仍然出现主从延迟，那么可以我们从主从延迟的原因产生上面可以知道，既然一个从库无法抗住压力，那么我们可以增加多个从库，比如 2 个 3 个从库，这样分摊一个从库的压力，也可以处理主从延迟的问题。
治本方案
上述方案都可以有效的处理主从延迟的问题。但是处理问题的根本思路都是减少主从延迟的时间，来达到不影响业务处理时间的目的，从而消除主从延迟的影响。那么现在我们考虑一个情况，就是不论您如何处理优化，当用户请求量达到您的数据库处理瓶颈的时候，主从延迟是必然出现的。这是数据库本身的设计决定的。除非您可以修改数据库的源码，更改数据库主从同步的实现方式。比如加入同步中间件，或者采用某些机制，确保主从同步完成才给用户返回处理成功等，当然这样显然也会导致一些性能的损耗。那么在目前的这种我们无法去修改数据库源码，或者说大多数公司都没有这个实力去做这个事情的情况下，我的解决方案是：
一、首先，假如你的业务时间允许，你可以在写入主库的时候，确保数据都同步到从库了之后才返回这条数据写入成功，当然如果有多个从库，你也必须确保每个从库都写入成功。显然，这个方案对性能和时间的消耗是极大的，不推荐。
二、另外一种就是，可以引入 redis 或者其他 nosql 数据库来存储我们经常会产生主从延迟的业务数据。当我在写入数据库的同时，我再写入一份到 redis 中。然后用户去读取数据的时候发现没有读取到这个数据，那么我们就可以再去查看 redis 中是否有这个数据，如果有我们就可以直接从 redis 中读取这个数据。当数据真正同步到数据库中的时候，再从 redis 中把数据删除
。
三、任何的服务器都是有吞吐量的限制的，没有任何一个方案可以无限制的承载用户的大量流量。所以我们必须估算好我们的服务器能够承载的流量上限是多少。达到这个上限之后，就要采取缓存，限流，降级的这三大杀招来应对我们的流量。这也是应对主从延迟的根本处理办法。
四、既然主从延迟是由于从库写库不及时引起的，那我们也可以在有主从延迟的地方改变读库方式，由原来的读从库改为读主库。当然这也会增加代码的一些逻辑复杂性。
评论