一、背景
应用持续访问又大又热的key，会造成Redis实例CPU高、流量被打满、数据在内存积压，甚至导致实例达到配额限制被oom-kill。在异步调用、pipeline、mget等批量调用场景比较常见。
大key分为两种情况
- 集合元素多且全量获取集合数据：命令时间复杂度是O(N)，持续访问这样的key会导致CPU打满，业务响应变慢，甚至超时。而且响应得不到及时发送，积压在内存，最终触发oom-kill。
- value占用内存大：持续访问这样的key会导致响应不过来（很小的请求也会造成较大的响应），从而造成返回给客户端的数据积压在Server内存，最终触发oom-kill。
二、如何发现问题
Redis集群侧会收到端口阻塞、客户端缓冲区高、实例内存高报警，推测可能是大/热key。
应用侧看到Redis服务性能变差、甚至出现大量超时。
三、问题处理过程
1、 Redis侧关闭集群Failover
Redis值班同学收到告警后，会关闭该集群的自动failover，避免该分片上所有副本被打死导致数据丢失。同时会第一时间联系业务研发，双方一起定位出问题的key。
2、研发和 Redis侧一起定位出问题的key
Redis侧：抓包（大key导致命令阻塞，只能抓包分析）、热key扫描工具
业务研发侧：日志等信息
3、选择一种合适的方式处理key
确认导致问题的key后，可以选择下面三种方式任意一种进行处理
1、对key限流（需要应用侧具备按照key限流能力）
2、在Redis客户端开启本地缓存
3、删除key或者将key设置成一个很小的值（需要权限，对业务有影响，key设置成小值，可以避免数据回源打挂数据库）
4、处理key完成后同步给Redis侧，JIMDB侧开启集群自动Redis，恢复服务
如果原来的主实例被打死，此时会自动Failover，Failover完成后业务恢复访问。