记录一次生产Redis 告警

博客记录了一次生产环境中Redis告警的排查过程,分析了接口调用频率与缓存策略导致的内存增长问题,并提出了优化方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

记录一次生产Redis 告警

当社会工具人 开始享受完成996的福报,晚上10.30到家开始享受这一天的仅有的自己私人生活,突然手机邮件. 群里被疯狂的@我 把我搞慌了,最近好像没有发版啊,一直挺稳定的啊,运维组开始刷锅直接扔图出来 看下方:–>

在这里插入图片描述

从上午的6点开始正常的增长一直在稳定的增长 直到晚上9点才基本稳定下来, TMD 我都到家了,才告诉我 哎!没有办法 大佬都在群里,应用负责人是我,还好我带了电脑,这个还是比较难排查的,这个不是代码的bug

在这里插入图片描述

先想想 最近做了什么, …

哦,这个应用功能比较少,只是给我客户端提供了一个接口,这个接口是分装了多个业务方的接口这个比较复杂简单的说一下 这个暴露一个接口给客户端(app)使用得到数据在前端展示 . 这个接口的业务 封装了业务方的数据

  1. 实时接口 每次都要调用 实时性比较强 (每个人得到的数据不一样)

  2. 一天调用一次 (每个人得到的数据不一样)

  3. 业务方接口 返回的数据量比较大 也是一天调用一次 (每个人得到的数据不一样)

  4. 一天调用一次 (目前所有人看到数据是一样的)

    这个接口早就上生产了,但是新版本app 会使用到,新版本好像还是在审核中,一直卡在App Store中.

    赶紧找运营咨询 -->

在这里插入图片描述

竟然发布了安卓, ios没有更新 这个好像也没有同时我们啊.差不多定位到问题了,赶紧去看一下数据埋点.安卓用户差不多有70%用户, 我们用户日活正常百万级别的.又看了一下 安卓升级到了最新版本的差不多有50w 用户.我在去看了一下逻辑, 重点上面2和3 的接口进行了缓存 都是缓存到12点进行定时清除,那这个容量图稳步增长是有道理的, 在思考了一下这个其实不是太好的, 其实可以缓存4小时后者2小时,因为我们是做支付app 有大量的用户的是为了支付的场景 后面停留的时间不多, 这个是一个可以改造的.

在看了一下生产的日志,第三个接口 缓存的数据比较大这个返回的是对象进行返回的 这个对象下面包装了5个List<对象> 每个人都会缓存下来,所以想想 这又是空间的浪费.当时的开发的时候只是为了快速完成,没有考虑到.

在这里插入图片描述

和运维沟通 等等到12点后看一下容量图的结果,后面来优化代码,培训一下组内 Redis 的设计标准.

最后我们看一下效果

图片转存中...(img-4su8REvB-1590307095568)]

好了先写到这里,后面把我组内的redis 的设计规范放出来,谢谢大家

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值