真·Redis缓存优化—97%的优化率你见过嘛?

redis,缓存,优化 · 浏览次数 : 10

小编点评

**2.1 根本原因** * 用户的日常业务需求可能导致缓存使用率过高。 * 在调整参数后,缓存使用率的下降速率明显变快。 * 在6.20号我们调整了参数后,在没有大批量数据添加后,r2m使用率的下降速率明显变快。 **2.2 优化率上线完成后的缓存使用情况** * 缓存优化率:改造前改造后(8.35-0.17)/8.35≈97.96%三。 * 总结本文主要通过一封告警邮件,由浅入深的将系统中存在的缓存问题与流程优化。 * 我们应该选择正确的中间件完成对应的功能。 * 不同中间件应该负责不同的事“韩信点兵,多多益善”,一名好的将军就是能将不同的士兵分配不同的职责,从而让士兵能够在自己擅长的领域内各尽其职。 **2.3 优化率上线完成后的缓存使用情况** * 在调整参数后,缓存使用率的下降速率明显变快。 * 在6.20号我们调整了参数后,在没有大批量数据添加后,r2m使用率的下降速率明显变快。 * 我们应该选择正确的中间件完成对应的功能。 * 不同中间件应该负责不同的事“韩信点兵,多多益善”,一名好的将军就是能将不同的士兵分配不同的职责,从而让士兵能够在自己擅长的领域内各尽其职。

正文

本文通过一封618前的R2M(公司内部缓存组件,可以认为等同于Redis)告警,由浅入深的分析了该告警的直接原因与根本原因,并根据原因提出相应的解决方法,希望能够给大家在排查类似问题时提供相应的思路。

一、问题排查

1.1 邮件告警

正值618值班前夕,某天收到了邮件告警,告警内容如下:

您好,R2M监控报警,请您及时追踪一下! 报警信息:告警ID:6825899, 应用:zr_credit_portal, 负责人:zhangsan, 告警类型:内存使用率, 时间:2023-06-15 16:00:04。实例:(10.0.0.0:5011-slave), 当前:9212MB 超过警戒值:8748MB 实例最大内存:10800 MB,内存使用率:85 % ;实例:(10.0.0.0:5023-master), 当前:9087MB 超过警戒值:8748MB 实例最大内存:10800 MB,内存使用率:84 % ;实例:(10.0.0.0:5017-master), 当前:9214MB 超过警戒值:8748MB 实例最大内存:10800 MB,内存使用率:85 % ;

大概内容是说,R2M集群使用率已经达到85%,需要紧急处理下。

我们的缓存集群配置如下,总共32400MB容量,三主三从,每个主节点10800M容量,目前使用最高的已经达到9087M。R2M使用集群模式进行部署。

image-20230713164727082

首先的思路就是使用大key统计,查看是哪些缓存占用了容量。因为大key统计是从节点进行扫描,所以不用担心会影响线上主流程。

image-20230713170916595

1.2 代码分析

大key主要分为两类,一类是xxx_data,一类是xxx_interfacecode_01,按照此规律去代码中寻找存放key的地方

String dataKey = task.getTaskNo() + "_data";
cacheClusterClient.setex(dataKey.getBytes(), EXPIRATION, DataUtil.objectToByte(paramList));

key = task.getTaskNo() + "_" + item.getInterfaceCode() + "_" + partCount;
cacheClusterClient.setex(key.getBytes(), EXPIRATION,DataUtil.objectToByte(dataList));


找到了代码位置后,分析其业务流程:

伏羲运营后台插入数据优化-第 3 页.drawio

1.3 告警原因

综合上图分析,此次占用率过高的原因可以分为直接原因与根本原因:

1.3.1 直接原因

查看运营后台确实发现有用户在此前三天创建了大量的跑批任务,导致缓存中样本与结果数量增加,从而导致缓存使用率过高。

1.3.2 根本原因

分析代码后,根据上文描述缓存中主要有两块数据:样本与结果

  • 首先是样本在缓存中存了一下随机又取出,本操作毫无意义,只会占用缓存容量。

  • 结果分批分片存储,此步骤有意义,主要是为了防止在多任务并行处理时,如果不将数据分片存入缓存,很有可能导致数据在JVM中占用大量空间,进而导致FULL GC的问题。(之前文章已分析)

  • 跑批结束后,中间数据正常来说已经无用,但是业务流程并没有主动删除无用数据,而是等待超时后自动删除,本操作会导致数据在缓存中额外存储较长时间。

至此,已经分析出了本次缓存使用率过高的原因(其实还没有,直接原因只分析出了表象,直接原因的“根本原因”还未有结论)。

二、问题解决

上文分析了本次告警的排查过程,以下是如何解决问题,也是分为如何解决直接原因与解决根本原因。

2.1 直接原因

2.1.1 原因分析

正值618前夕,最好不考虑操作会对系统产生的影响,因此只能先考虑让对应的用户暂时停止创建跑批,以免继续占用内存导致影响线上业务。

此时观察监控图又发现:
image.png

用户是从三天前就开始创建跑批任务的(对应缓存开始增长的时间点),但是缓存的有效期只有一天,按道理来说从第二天开始每天的缓存都应该下降不少才对(因为前一天的已经过期了),为什么看监控图这三天的缓存使用率近乎直线上升呢?

此处可以思考30s,与Redis特性有关。

根据之前刚系统的学完Redis的相关特性,关注到此问题点后,开始思考有没有可能是虽然我们设置了超时时间是一天,但是实际上数据并没有被物理删除呢(Redis的缓存淘汰策略)?

随后查看R2M相关文档:

image-20230907145129672

其中:

如果带有生存时间的键非常多的话, 那么在键的生存时间变为0, 直到键真正被删除这中间, 可能会有一段比较显著的时间间隔。

这不就是我们的特性吗,从刚刚的我们搜索大key的图中可以看到,我们有很多带超时的key并且size都很大,很有可能虽然已经超时了(即TTL变为0)但该数据并没有访问,并且由于R2M渐进式删除,某一个Key可能会在超时后很久才会被真正的物理删除

至此,直接原因的根本原因已经找到了。

2.1.2 解决

那么如何解决呢?根据一个Key过期时被物理删除的两种策略:

注意:

Redis 使用以下两种方式删除过期的键

  • 当一个键被访问时,程序会对这个键进行检查,如果键已经过期,那么该键将被删除。

  • 底层系统会在后台渐进地查找并删除那些过期的键,从而处理那些已经过期、但是不会被访问到的键。

首先通过访问的形式去删除数据肯定是愚蠢且没必要的(都能访问并且知道要过期了不如直接删除),那么可以选择提高渐进的查找速率。从而将那些超时的数据物理删除

于是我们联系了R2M对应运维:

image.png

根据上述聊天记录可知,确实有参数可以调整渐进式物理删除的频率,而我们的缓存集群则之前因为不知名原因(项目团队做过更换)被调整为了10,大约降低了六倍,此结果也符合我们的预期,从侧面印证了我们的猜想是正确的。

当时处于618前夕,我们没有并没有修改该参数,在618之后,我们随即提了工单修改该参数,将该参数从10提高到80:

image-20230713183643785

审批通过之后,我们观察r2m的下降速率:

image-20230713183917668

可以看到,在6.20号我们调整了参数后,在没有大批量数据添加后,r2m使用率的下降速率明显变快

至此,缓存使用率告警的直接原因已经解决完毕,真正的原因就是有大量的key过期后并没有被删除,观察后续缓存使用率都没有太高。此外,即时有大量的跑批任务,如果不是在同一天内直接添加,一般不会造成使用率过高的问题。

2.2 根本原因

上文在调整参数后,基本可以满足用户的日常业务需求,但是如果用户确实有一天之内有大量跑批任务的需求,那么此方案仍不能解决根本问题,还会造成使用率过高有可能影响线上业务的风险。

那么要从根本上解决此问题,就需要对跑批流程进行优化,按照1.2中流程示意以及原因分析:

  1. 样本就已经完全没有必要存储在缓存中,所以在代码中直接采用参数传递的方式传入给下一步流程。

  2. 结果分片肯定是有意义的,原因上文中也提到了,但是redis缓存的空间(即内存)是比较宝贵的,而oss的空间成本(硬盘)则是比较廉价的,并且考虑本身业务就是离线业务,时效性以及查询速率并不是最关键的因素,因此综合考虑将跑批的结果分片数据存储至oss

  3. 在跑批流程结束后,主动删除oss中的结果分片数据,避免数据无用后仍占用存储空间。此外在oss端设置7天自动删除,防止系统原因异常导致数据未删除而永久存在

综上,结合以上的优化思想,重新设计的流程图如下:

伏羲运营后台插入数据优化-第 4 页.drawio

至此,即时后续用户数据量再大,也无论是分一天创建还是多天创建,都不会导致缓存使用率告警而有可能带来的线上业务问题。

2.3 优化率

上线完成后的缓存使用情况:

image-20230911155108232

可以看到几乎是断崖式下降。

缓存优化率:

改造前

image-20230911155042608

改造后

image-20230911155540703

(8.35-0.17)/8.35≈97.96%

三、总结

本文主要通过一封告警邮件,由浅入深的将系统中存在的缓存问题与流程优化。在解决完实际问题后,我们应该都会有一些心得与总结,从而下次自己在开发过程中避免再犯这样的问题,也能够自己对自己再做一次总结与归档。要做到能够知其然更要知其所以然。以下总结是自己的由浅入深的一点点心得。

3.1 不同中间件应该负责不同的事

“韩信点兵,多多益善”,一名好的将军就是能将不同的士兵分配不同的职责,从而让士兵能够在自己擅长的领域内各尽其职。对我们研发来说,选择不同的中间件完成不同的功能则是能够反应我们研发的技术水平。

像本文来说,可供存储中间数据的有好多中间件,除了Redis、Oss,还有Mysql、Hive、ES、CK等,我们需要根据不同的业务需求选择不同的中间件完成对应的功能。本案例中很明显数据的特性为大量的、不要求速度的,而Redis的存储特性为少量的、快速的,很明显这两个是背道而驰的需求与业务,因此我们在选用时应该选择正确的中间件。

3.2 学习技术细节有没有用

其实之前也有学了很多的技术、框架的实现细节,但是绝大多数都是学完就学完了,并没有太多实践的环节。而这次案例分析正好处于之前刚刚学完Redis的相关细节,没隔多久就能够应用到本次的实践环节,算是理论与实践结合。此外这次案例也能够很大程度上提升自己的学习兴趣。

作者:京东科技 韩国凯

来源:京东云开发者社区 转载请注明来源

与真·Redis缓存优化—97%的优化率你见过嘛?相似的内容:

真·Redis缓存优化—97%的优化率你见过嘛?

本文通过一封618前的R2M(公司内部缓存组件,可以认为等同于Redis)告警,由浅入深的分析了该告警的直接原因与根本原因,并根据原因提出相应的解决方法,希望能够给大家在排查类似问题时提供相应的思路。

真·生产力「GitHub 热点速览」

这些工具真的能极大提高生产力,节约你的时间来自(摸)我(鱼)增(划)值(水)。先别提 style2paints,你给它随意画个草图,就能给你一个能交付给甲方爸爸的成品插画。如果提升 30%-40% 传输速度的 kcp 不够惊艳,还有想象力匮乏程序员的福音——rerun,直接让你带入计算机视角看待那些

川普真会说中文?连嘴型都同步,VideoReTalking AI数字人下载介绍

你能想到这种画面吗?霉霉在节目中用普通话接受采访,特朗普在老家用中文脱口秀,蔡明老师操着一口流利的英文调侃潘长江老师.. 这听起来似乎很魔幻,可如今全部由VideoReTalking实现了 你只需要传入一个视频文件和音频文件,它会生成一个新的视频,在这个视频里,不仅人物的嘴型会与音频同步,就连表情也

雷电模拟器改真机保姆级教程,游戏搬砖党必备!

游戏工作室今天分享最新防封电脑模拟器改真机技术,适用于所有模拟器搬砖游戏,有效防止电脑模拟器封禁问题。 游戏搬砖玩家可以像使用真机一样流畅地操作游戏,电脑模拟器可以模拟真机的运行环境,让游戏服务器难以察觉到运行设备的差异,从而起到防封的作用更加安全。 重要提示:要多开模拟器,每个模拟器,都新建,并用

AI 画图真刺激,手把手教你如何用 ComfyUI 来画出刺激的图

目前 AI 绘画领域的产品非常多,比如 Midjourney、Dalle3、Stability AI 等等,这些产品大体上可以分为两类: 模型与产品深度融合:比如 Midjourney、Dalle3 等等。 模型与产品分离:比如 SD Web UI、ComfyUI 等等。 对于绝大多数普通用户而言,

记录freeswitch的一个2833问题

概述 freeswitch是一款简单好用的VOIP开源软交换平台。 运营商内部新老系统混用,互联互通的问题较多,其中以DTMF码的问题最多,花样也多。 环境 CentOS 7.9 freeswitch 1.10.7 问题描述 问题现象 正常的fs业务服务器,呼叫正常,部分呼叫报错DTMF收码失败。

MySQL索引

索引的概述 索引是一种用于快速查询和检索数据的数据结构,其本质可以看成是一种排序好的数据结构。索引的作用就相当于书的目录。打个比方: 我们在查字典的时候,如果没有目录,那我们就只能一页一页的去找我们需要查的那个字,速度很慢。如果有目录了,我们只需要先去目录里查找字的位置,然后直接翻到那一页就行了。索

CompletableFuture学习总结

CompletableFuture 简介 在Java8中,CompletableFuture提供了非常强大的Future的扩展功能,可以帮助我们简化异步编程的复杂性,并且提供了函数式编程的能力,可以通过回调的方式处理计算结果,也提供了转换和组合 CompletableFuture 的方法。 Java

记录一次fs通话无声的问题

概述 freeswitch是一款简单好用的VOIP开源软交换平台。 fs的实际应用中,由于网络、配置等问题,经常会产生通话无声的问题。 环境 CentOS 7.9 freeswitch 1.10.7 问题描述 部署一台新服务器,作为SBC,对接B路,部署简图如下。 A -- fs1 -- fs2(f

[转帖]“炫技”还是“真硬核”,OpenPPL 实测阿里「倚天 710」芯片

“炫技”还是“真硬核”,OpenPPL 实测阿里「倚天 710」芯片 本文将以「深度学习模型推理应用」为出发点,对「倚天 710」这款 ARM Server 芯片进行性能实测。 OpenPPL 自开源以来,便密切关注着业界的进展,致力于优化模型推理的全链条。完善对国产化芯片的支持,是 OpenPPL