gpt4 book ai didi

【性能优化】优雅地优化慢查询:缓存+SQL修改组合拳

转载 作者:我是一只小鸟 更新时间:2023-04-07 06:31:15 34 4
gpt4 key购买 nike

问题描述

单例数据库模式中,后端高并发请求多(读多写少),导致数据库压力过大,关键接口响应变慢,严重影响体验.

需求

减少接口的响应时间.

寻找解决方案

由于问题主要处在数据库压力过大的情况,采用两种优化思路优化查询过程:

  1. 使用缓存分担数据库压力
  2. 对查询数据库过程做优化

缓存方案

更新策略

使用Redis,虽然可以很好地减少数据库的压力,但是同时在高并发的情况下,容易出现数据不一致的情况,尤其是在更新数据的时候.

最常见的导致不一致的原因是双写操作,即高并发情况下短时间内对数据库进行两次写操作。为了最小程度地出现这种情况,缓存在更新策略上采用先更新数据库后删除缓存的方式.

对于双写问题,在最坏情况下,写请求A在更新数据库后,被写请求B先一步更新数据库+删除缓存,然后A请求才删除缓存,也不会导致后续请求读取到错误的值.

对于先写后读,在最坏情况下,写请求A在更新数据库后,被读请求C先一步在缓存读取到旧值,然后A请求才删除缓存,也只会影响这段时间的读请求,删除后的读请求不影响.

对比其他方案(先更新缓存后更新数据库、先删除缓存后更新数据库、先更新数据库后更新缓存)在最坏情况下会导致的错误(更新数据库失败导致缓存是未知值、双写后数据库变成旧值、更新缓存失败导致缓存保存旧值)要好得多.

但是先更新数据库后删除缓存也不是完全安全的,除了上文提到的高并发下先写后读可能读到旧值外,若删除缓存失败,也有可能导致读到旧值。处理方法见下文.

缓存架构

添加缓存,势必要修改业务代码,如何配置架构才能把对代码的入侵性讲到最低,这里使用监听数据库binlog的方法,使用中间件监听mysql的日志,当出现操作时,通知专门的模块来修改缓存,做到修改缓存和业务逻辑解耦.

同时为了解决缓存删除失败的问题,当发生失败时,发送消息至消息队列传递给专门的模块进行重试删除.

中间件选择:

  • 缓存使用Redis
  • 监听binlog使用canal
  • 消息队列使用RocketMQ

架构如下所示:

SQL优化

查询优化可以从两个方面进行:

  1. 根据高频的查询case,遵循最左匹配原则,设置对应的索引或联合索引
  2. 通过了解业务场景,看看能否将一些小SQL合并成大SQL

最后此篇关于【性能优化】优雅地优化慢查询:缓存+SQL修改组合拳的文章就讲到这里了,如果你想了解更多关于【性能优化】优雅地优化慢查询:缓存+SQL修改组合拳的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

34 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com