记录一次生产Redis 告警

记录一次生产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 的设计标准.

最后我们看一下效果

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