mysql 查询 读写 延迟_MySQL读写分离后的延迟解决方案

本文介绍了在高并发场景下,MySQL读写分离的实践及延迟问题。通过分析不同分离策略,如完全分离、不完全分离等,探讨了延迟产生的原因、主从同步策略及其延迟,并提出了解决方案,包括监控主从延迟、优化SQL和业务逻辑等。
摘要由CSDN通过智能技术生成

数据库——MySQL读写分离后的延迟解决方案

背景:

根据上图可以看到QPS:10.73k,实际上真实的并发大量数据到达的时候,我这里最高的QPS是将近15k.而目前单个数据库分片(实例)4CPU8G内存的配置下,最高的性能是7k的QPS。

基于上篇我进行了分库分表是对于性能有很大的提高,分库分表实践和中间件的引申

我这里讲解的例子是目前4主8从库(12个实例),以下每个实例都会称为分片。单个分片配置mysql版本5.7.19(一会说明不同版本是读写分离的不同策略),12CPU16G内存,128G的磁盘,Raid:10。

读写分离实践

读写分离可以参考上篇文章的分库分表实践中的中间件的用法来实现。主流一般会使用mycat,但是每个中间件都有自己的优点可以择优和业务特点而用。接下来讲读写分离后的后遗症。

读写分离的延迟和实时insert/update和查询操作

比如我这里的一个场景:由于数据量大,以人维度的情况下,商品量20w~50w。然后需要分页查询未同步下游状态,进行数据同步后再更新该分页数据。我当时设定了如下的四种场景,最后选择了读写分离和不分离同时存在,针对于实时要求结果高的依然是master主库读写,变动需求量小的数据,全部转移slave从库。

如下是四种场景的方案:

1、 完全分离:全量读->从库,全量读写->主库

前提:第一页查询逻辑不变

特点:半同步复制,目前是1主2从库,利用半同步复制原理,1/2的可能性会重复查询,当然这个几率需要和延时性进行测试计算可得,也就是最坏的结果可能性是重复查询50%的可能

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值