Redis线上问题排查指南（小白面试版）
一、面试官压力测试题
1. “线上Redis内存持续增长，怎么排查？”
排查步骤：
- 第一步：
info memory看内存使用情况 - 第二步：
redis-cli --bigkeys找大key - 第三步：
redis-cli --hotkeys找热key（需先开启） - 第四步：
info commandstats看命令统计 - 第五步：检查业务代码，是否忘记设过期时间
2. “某个key访问量特别大，怎么处理？”
解决方案：
- 加本地缓存（如Guava Cache）
- 读写分离：主从架构，读请求走从节点
- 多副本：key复制多份，如
key_1、key_2 - 升级Redis集群，分散压力
3. “怎么发现大key和热key？”
发现方法：
# 大key扫描（可能影响性能，在从节点执行）
redis-cli --bigkeys
# 热key发现
redis-cli --hotkeys
# 或通过monitor命令分析
redis-cli monitor > monitor.log
二、排查工具速记
| 工具 | 用途 | 注意点 |
|---|---|---|
--bigkeys | 找大key | 扫描慢，建议在从节点用 |
monitor | 实时看所有命令 | 性能杀手，只能短时间用 |
| 慢查询日志 | 找慢操作 | 需提前设置阈值 |
三、解决方案模板
1. 大key拆分
问题： 一个hash有100万字段 解决： 拆成10个hash，每个10万字段
2. 热key多副本
// 访问时随机选副本
String key = "hotkey_" + random.nextInt(3);
3. 本地缓存+Redis
- 先读本地缓存
- 没有再读Redis
- 适合不经常变的数据
四、面试加分回答
“说说你处理过的大key问题”
“我们有个用户信息hash特别大，我拆成了多个小hash，按用户ID分片存储，内存降了70%”
“如何预防大key产生？”
- 代码规范：单个value不超过10KB
- 列表/集合元素不超过5000个
- 设计时就考虑拆分方案
- 定期用
--bigkeys巡检
五、监控告警设置（简单版）
必须设置的监控：
- 内存使用率 > 80% 告警
- 连接数 突然翻倍告警
- QPS 超过日常3倍告警
- 慢查询 每分钟超过10次告警
面试一句话总结
“先监控发现，再工具定位，最后业务解决。平时做好规范，出事不急不慌。”
小提示：面试时可以说“我一般会在从节点用--bigkeys扫描，避免影响线上性能”，显得有经验。
