Redis-线上故障常见问题、排除和解决办法

结合你前面的问题，记住下面这几件事就够了。

1. Redis 为什么会卡？怎么排查？

常见原因	排查方法	解决办法
大 Hash 被全量读取、同步删除	看慢日志，检查 Hash 大小、接口返回量	少用 HGETALL，按字段查询；数据拆分
某个 Key 访问太频繁	看接口访问量、节点 CPU 和带宽	限流、本地缓存，必要时分担读流量
内存不足	看内存使用量、淘汰情况	清理无用数据，设置合理保留时间，必要时扩容
连接池耗尽、网络异常	看应用报错、连接池和连接数	修复连接泄漏或网络问题，控制并发
主库宕机	看节点状态、复制状态和切换日志	通过哨兵或 Cluster 接管，并让客户端连接新主库

2. 发现 Big Hash，不是必须删除

先看数据还要不要：

• 还要用：改成按字段查询，并逐步拆成多个小 Hash。
• 部分无用：分批清理无用字段。
• 整个不要了：确认业务允许后，用 UNLINK 删除，减少同步释放内存带来的阻塞。

大 Hash 存在那里，不代表一定卡；对它执行什么操作才是关键。

3. 限流、降级怎么做？

例如“用户画像查询”拖慢了 Redis：

• 限制这个接口的请求量和并发。
• 暂停全量查询、导出等重操作。
• 允许的话，返回本地缓存、旧快照，或暂时关闭非核心功能。
• 不要把全部请求直接转给数据库，否则数据库也可能被打垮。

4. 有主从，为什么还要读写分离？

主从复制只负责同步数据，不负责分配请求。

如果应用只访问主库，读写仍然都在主库。需要客户端或代理明确配置，才会把部分读请求发到从库。

设计时可以做读写分离，但从库可能有延迟；需要最新数据的请求仍应读主库。它也解决不了大 Hash 的写入压力。

5. 主库宕机后，数据怎么同步？

假设原来 A 主、B 从：

A 宕机 → B 被提升为新主库 → 应用开始写 B
A 恢复 → A 成为 B 的从库 → 从 B 同步数据
-如果 A 还保留着 B 缺失的那段复制偏移量，就走 增量同步；
-如果偏移量已经不在复制积压缓冲区内，就会触发 全量同步，B 生成 RDB 发给 A

纯主从需要人工切换；哨兵或 Cluster 在满足条件时可以自动切换，客户端也要跟着换连接。

注意：A 宕机前还没复制给 B 的写入，可能丢失。

实际处理顺序：先限流保护业务 → 查日志和指标 → 找到具体原因 → 针对性处理 → 逐步恢复流量。