一次redis缓存不均衡优化经验

这篇具有很好参考价值的文章主要介绍了一次redis缓存不均衡优化经验。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

背景

高并发接口,引入redis作为缓存之后,运行一段时间发现redis各个节点在高峰时段的访问量严重不均衡,有的节点访问量7000次/s,有的节点访问量500次/s

此种现象虽然暂时不影响系统使用,但是始终是个安全隐患,随着业务量逐年上涨,风险留给未来,并非一个合格码农的职业操守。必须得看看究竟是何种情况。

思考

想要优化,得现有一番思考,先得想想究竟有哪些情况会产生这种现象,才能去逐步排查,而不能盲目就去动手。

可能的原因:

  1. 数据倾斜:如果某些键的访问频率较高,而这些键又恰好分布在某几个节点上,就会导致节点的访问不均衡。这可能是因为数据分布不均匀,或者业务逻辑导致某些键的访问频率较高。
  2. 网络问题:网络延迟或带宽限制可能导致某些节点的访问速度较慢,从而使访问不均衡。
  3. 客户端连接问题:如果某些客户端连接到了某个特定节点,而其他节点上的客户端较少,就会导致节点的访问不均衡.
  4. 业务逻辑问题:是否是因为业务逻辑原因导致的频繁访问同一批数据
  5. 是否存在热key

验证

有了上述思考,就要开始去逐一排查可能的原因

1.数据倾斜排查:检查数据在节点之间的分布情况,通过查看Redis的CPU、内存指标,并未发现某个节点的负载明显高于其他节点

2.网络问题:通过监测网络延迟或带宽限制相关情况,并未发现有此种情况

3.客户端连接问题:检查客户端连接到Redis节点的方式,如果发现某些节点受到过多的请求压力,可以考虑采用负载均衡策略,将请求均匀分散到不同的节点上;通过相关检查,并未发现此类问题

4.业务逻辑问题:分析Redis访问相关业务代码及定时任务,并未发现有重复访问的逻辑存在

5.是否存在热key:通过运维获取高峰时段的访问日志,进行统计分析,

(1) 热key有两类:网点映射+以业务账号维度的数据

(2)redis访问不均衡的原因:不同客户下单高峰分布在一天不同时间段,高频访问在不同时间分布在不同节点上

方案

通过三种策略来确保redis各节点的访问均衡

1.本地缓存策略

将将要缓存的数据根据业务形态分为两类:

(1)网点类的常用数据直接缓存在本地

(2)对于高峰时期高频访问的数据,引入缓存组件Caffeine,设置相关的策略

设置大小为1M

EXPIRE_AFTER_WRITE_TIME(60s)

EXPIRE_AFTER_ACCESS_TIME(10s)

2.节点一致性策略

使用发布-订阅模式(Pub-Sub)来实现更新通知机制; 当 Redis 中的数据更新时,Redis 可以发布一个更新通知,各节点的本地缓存订阅这个通知,并根据通知更新本地缓存

3.异常解决方案

(1)异常日志记录

(2)间隔2min重试机制

(3)重试后异常告警机制

(4)数据定时同步(兜底): DB->redis、redis->本地缓存

下图为存储与访问缓存的逻辑图:

一次redis缓存不均衡优化经验,缓存,redis,数据库

 效果

经过上述方案的实施,最终实现了:

1.redis各节点的访问量在全时段实现了均衡态

2.redis的各节点的整体QPS也下降了10%

3.像双十一双十二高峰时段接口也是稳稳的

本地缓存原理及方案选取原因

本地缓存是指将数据存储在应用程序的本地内存中,以提高数据的读取速度和访问效率。本地缓存的本质是通过将常用或热点数据保存在内存中,避免了每次访问都需要从远程或磁盘存储中读取数据的开销。

本地缓存的工作原理如下:
1.数据加载:当应用程序第一次访问某个数据时,如果该数据还未被缓存,则从远程或磁盘存储中加载数据,并将其保存在本地缓存中。
2.数据访问:当应用程序再次访问同样的数据时,首先从本地缓存中查找数据。如果数据存在于缓存中,则直接返回缓存的数据,避免了从远程或磁盘存储中读取的开销。
3.缓存更新:当数据发生变化时,需要更新缓存中的数据,以保持缓存和存储中的数据一致性。可以通过手动或自动的方式更新缓存,例如定时刷新缓存、监听数据变更事件等。
本地缓存的优势包括快速访问、低延迟、减轻了远程或磁盘存储的负载等。它适用于那些访问频率较高、数据相对稳定的场景,可以大大提高应用程序的性能和响应速度。

但是需要注意的是,本地缓存也存在一些问题,如缓存过期、缓存一致性、内存管理等。开发者需要根据具体的应用场景和需求,合理配置和管理本地缓存,以充分发挥其优势同时避免潜在的问题。

传统缓存组件方案:

FIFO:按照数据最早进入缓存的顺序进行替换。即,先进入缓存的数据先被替换掉。FIFO策略简单直观,但可能导致缓存命中率较低,因为最早进入缓存的数据可能不一定是最常用的数据。
LRU:根据数据最近被访问的时间进行替换。即,最长时间未被访问的数据会被替换掉。LRU策略基于“时间局部性”原理,认为最近被访问的数据更有可能在将来被访问,因此替换最久未被访问的数据。但实现LRU策略需要维护访问数据的顺序,可能带来一定的开销。
LFU:根据数据被访问的频率进行替换。即,最不经常被访问的数据会被替换掉。LFU策略基于“访问局部性”原理,认为最常被访问的数据更有可能在将来继续被访问,因此替换最不经常被访问的数据。但实现LFU策略需要维护数据的访问频率,可能带来更大的开销。

Caffeine 一个高性能、高命中率、接近最优的本地缓存,被称为”新一代缓存“或”现代缓存之王。

脱胎于Guava Cache , 结合LRU+LFU的优势,使用一种W-TinyLFU的算法结构

从Spring5开始,Caffeine将取代Guava Cache成为Spring默认的缓存组件

Caffeine是一个基于Java的内存缓存库,与其他缓存组件相比,它具有以下几个优势:

  1. 高性能:Caffeine被设计成高性能的缓存库,它使用了多种优化技术来提供快速的缓存访问,包括使用本地内存和原生数据结构,避免了不必要的开销。
  2. 低延迟:Caffeine的设计目标之一是提供低延迟的缓存访问。它采用了基于时间戳的缓存失效策略和预先加载机制,以减少对外部资源的依赖和等待时间。
  3. 强大的功能:Caffeine提供了丰富的功能,包括缓存过期、缓存加载、缓存刷新、缓存移除等。它支持异步加载和自定义缓存策略,可以根据具体需求进行灵活配置。
  4. 内存管理:Caffeine提供了细粒度的内存管理功能,可以设置缓存的最大大小、最大条目数、过期时间等。它还支持缓存的自动回收和大小基于权重的淘汰策略,可以有效地管理内存。
  5. 易于使用:Caffeine提供了简单易用的API,可以方便地创建和管理缓存。它还提供了详细的文档和示例代码,以帮助开发者快速上手和集成。

Caffeine在性能、延迟、功能和内存管理等方面都具有优势,适用于对缓存性能要求较高的场景。它可以作为Java应用程序的缓存解决方案,提供快速、可靠和灵活的缓存支持。

 文章来源地址https://www.toymoban.com/news/detail-626665.html

到了这里,关于一次redis缓存不均衡优化经验的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 7个工程应用中数据库性能优化经验分享

    摘要: 此篇文章分别从sql执行过程、执行计划、索引数据结构、索引查询提速原理、聚焦索引、左前缀优化原则、自增主键索引这些角度谈一谈我们对数据库优化的理解。 本文分享自华为云社区《工程应用中数据库性能优化经验小结》,作者: 叶工 。 现阶段交付的算法产

    2024年02月06日
    浏览(52)
  • Redis缓存数据库(四)

    目录 一、概述 1、Redis Sentinel 1.1、docker配置Redis Sentinel环境 2、Redis存储方案 2.1、哈希链 2.2、哈希环 3、Redis分区(Partitioning)  4、Redis面试题 Redis Sentinel为Redis提供了 高可用解决方案 。实际上这意味着使用Sentinel可以部署一套Redis, 在没有人为干预的情况下去应付各种各样的失

    2024年02月05日
    浏览(55)
  • redis数据库缓存服务器

    redis比mysql访问数据快 非关系型数据库以键值对的方式存储数据 作用:加快访问速度,缓解数据库压力 redis最新版本7 特点 丰富的数据结构 list,set,hash等数据结构的存储 支持持久化 支持事务 “一个完整的动作,要么全部执行,要么什么也没有做” 支持主从支持高可用,支持

    2024年02月05日
    浏览(62)
  • Redis如何保证缓存和数据库一致性?

    现在我们在面向增删改查开发时,数据库数据量大时或者对响应要求较快,我们就需要用到Redis来拿取数据。 Redis:是一种高性能的内存数据库,它将数据以键值对的形式存储在内存中,具有读写速度快、支持多种数据类型、原子性操作、丰富的特性等优势。 优势: 性能极高

    2024年01月16日
    浏览(70)
  • Redis---数据库和缓存如何保证一致性?

    用「读 + 写」请求的并发的场景来分析: 假如某个用户数据在缓存中不存在,请求 A 读取数据时从数据库中查询到年龄为 20,在未写入缓存中时另一个请求 B 更新数据。它更新数据库中的年龄为 21,并且清空缓存。这时请求 A 把从数据库中读到的年龄为 20 的数据写入到缓存

    2024年01月24日
    浏览(57)
  • Redis如何保障缓存与数据库的数据一致性问题?

    目录 一.最经典的数据库加缓存的双写双删模式 二. 高并发场景下的缓存+数据库双写不一致问题分析与解决方案设计 三、上面高并发的场景下,该解决方案要注意的问题 1.1 Cache Aside Pattern概念以及读写逻辑 (1)读的时候,先读缓存,缓存没有的话,那么就读数据库,然后取

    2023年04月21日
    浏览(49)
  • redis的缓存更新策略以及如何保证redis与数据库的数据一致性

    redis的缓存更新策略有这么几种: 1、由应用直接和redis以及数据库相连接:         查询数据时,应用去redis中查询,查不到的话再由应用去数据库中查询,并将查询结果放在redis;         更新数据时,由应用去触发redis数据的删除以及数据库的update。 2、应用只跟redi

    2024年02月13日
    浏览(57)
  • Springboot+Redis:实现缓存 减少对数据库的压力

    🎉🎉欢迎光临,终于等到你啦🎉🎉 🏅我是苏泽,一位对技术充满热情的探索者和分享者。🚀🚀 🌟持续更新的专栏 Redis实战与进阶 本专栏讲解Redis从原理到实践 这是苏泽的个人主页可以看到我其他的内容哦👇👇 努力的苏泽 http://suzee.blog.csdn.net/   目录 缓存如何实现?

    2024年03月24日
    浏览(59)
  • Redis数据库 | 发布订阅、主从复制、哨兵模式、缓存雪崩

    💗wei_shuo的个人主页 💫wei_shuo的学习社区 🌐Hello World ! Redis 发布订阅 (pub/sub) 是一种消息通信模式:发送者 (pub) 发送消息,订阅者 (sub) 接收消息 Redis 客户端可以订阅任意数量的频道 Redis主从复制是指在Redis中设置一个主节点(Master)和一个或多个从节点(Slave),

    2024年02月15日
    浏览(57)
  • REDIS21_缓存双写一致方案、先更新数据库再删除缓存

    ①. 缓存双写一致性,谈谈你的理解 如果redis中有数据,需要和数据库中的值相同 如果redis中无数据,数据库中的值要是最新值 ②. 什么时候同步直写? 小数据,某条、某一小戳热点数据,要求立刻变更,可以前台服务降价一下,后台马上同步直写 ③. 什么时候异步缓写? 正常业务,马

    2023年04月08日
    浏览(47)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包