redis性能故障的思考

背景:

2月23日晚，业务方反馈应用有redis 超时现象，核心的服务也被波及到。

运维介入排查后，发现redis内存耗尽， 并且这个耗尽现象是规律性地出现。

排查的过程：

通过命令行登录到redis中发现：

1. used_memory_rss远大于maxmemory (原因是used_memory_overhead:21G, maxmemory:21G, 只能说明数据的增量远快于evict速度, maxmemory仅仅只是一个软限制而已)
2. 主从复制中断，2个从库在重新full sync ( slave先发送full sync命令，master然后bgsave ， 传rdb到slave, slave load rdb到内存， slave 从缓冲区做增量同步【缓冲区能容纳这段时间的写数据增量】)。

开发人员让业务运维同学做redis紧急扩容(再没有弄清楚情况下扩容的行为，笔者保留看法)， 扩容过程 让redis的不可用的程度更加恶化(告警更加严重)。

为了搞清楚redis的内存消耗的原因，运维用monitor抓了一段时间的请求，同时分析redis info中的相关信息。

monitor 的分析

info stats段中

半同步失败12次(可能网络中断了一段时间，且这段时间数据增量超过了redis buffer的大小，或者可能是命令阻塞过长，阻塞的这段时间数据增量超过redis buffer大小)，全同步居然达到20次(大部分应该是由sync_partial_err失败而产生full sync)。

但从监控图上，没有看到slave有网络中断的情况，(即使有网络中断

，主从full sync引发bgsave并不会让内存开销翻倍.(参见:redis是否需要预留一半的内存）， 并且未见hash分裂)

查看了一下慢查询：

虽这个地方不合理: hgetall 大key，但是不能确定是不是这个原因导致。（如果是这个因素，为什么之前没有爆发问题？)

运维层排查的思路无法进一步定位原因，于是准备分析redis 内存中的key大小的分布，特别是增量key的大小分布。此时redis扩容持续近1个小时后终于完成， 业务貌似恢复正常了。正当大家准备收工回家，开发方反馈问题并没有解决，仍然有redis超时告警。再次登录redis ,发现内存耗尽，开发者准备让业务运维再次扩容，这次被笔者坚定否决，显然扩容是无法解决这个redis故障(后面有分析)。开发人员和开发负责人联系后，开发负责人反馈现货有压测注册业务行为，注册业务接入了风控。因此排查方向全部转向业务层，开发者分析monitor 捕获出来的大hash key ，开发同学仔细分析和review代码过后，确认该key为风控逻辑所致【key会线性放大】。

联系到现货压测相关同学后，经评估，现货压测行为停止，redis恢复正常。

第二天工作日到公司，对该故障进行复盘。

1. 发现故障时刻的redis实例带宽被打满了。

由于现货业务压测，加上风控逻辑'放大'的效果，导致key非常大，进而导致带宽满，带宽满导致限流，导致大量TCP超时重传，进而导致hgetall之类命令积压(hgetall返回数据的时间会大大延长)，进而阻塞redis的主从同步。

2. repl_backlog_size 过小，主从复制缓冲区默认的repl_backlog_size为:1048576(1M), 主从同步阻塞1,2秒就足可以导致repl_backlog_size溢出引起full sync。

3. redis缓存剔除策略和开发者使用方式相冲突。redis采用的是maxmemory_policy:volatile-lru, 对过期keys进行LRU剔除，但开发者使用hash的时候，并没有全部带上过期时间。

4. AWS redis自带的扩容机制存在很大的性能缺陷， 原来的slave 不会踢掉，在扩容期间，会出现4个slave做全同步， 进一步恶化带宽的争抢带来一系列问题。

改进措施：

如果将该故障改进扩展引申的话，需要解决以下的问题：

开发侧：

1. 整体架构上有熔断，限流的策略？

2. 业务层监控，能够区分出不同的业务流量，快速定位突增的业务流量？

3. redis是否可以按照业务进行拆分【偏向用户体验, 后台类, 核心，非核心 】不至于雪崩？

4. redis的key如何快速定位到具体的应用？【key如何命名？】

5. big hash key 能否通过bitfield进行转换？hash field加过期时间？

6. 风控代码逻辑优化(排除压测行为)

运维侧：

1. redis的偏业务层监控，如:key的内存分布分析，大key监控 （可考虑自建)

2. 优化redis默认参数--（可考虑自建，优化以上的参数)

流程机制：

1. 生产环境的压测/生产环境的大的变更， 周知上下游流程机制。

2. 运维扩容/缩容需要运维评估