故障背景
最近，公司线上某 Redis 节点因突发异常导致 CPU 飙升至 100%，无法处理正常请求。
该 Redis 实例为单点主从结构，受历史原因限制尚未迁移至集群。故障发生时，Master 节点（记为 A）CPU 瞬间满载，平时负载仅在 30% 左右。此时 telnet 端口不通，部署 Redis Master 的虚拟机甚至无法登录，但该虚拟机上其他服务的端口访问正常。
紧急处置
运维团队尝试将 Slave 节点（记为 B）切换为 Master。然而，B 节点的 CPU 同样达到 100%，大部分请求超时，偶尔返回的 RT 高达 600ms。这意味着提升为主节点的节点也失去了服务能力。
最终只能将流量切至其他备用 Redis 节点（实体机），CPU 负载下降，RT 恢复正常，故障得以解决。
故障复盘
为什么主节点 CPU 会突然飙升？
基于 Redis 单进程单线程的特性，当时我们推测可能由以下原因导致：
- 高并发：连接数激增、QPS 暴涨。
- RDB Fork：持久化 fork 子进程消耗了大量资源。
- 数据过期：密集型数据集中过期，回收线程阻塞。
随后尝试修改配置关闭 save 操作，但情况并未好转。
为什么备机切换后依然不可用？
初步分析认为原主节点配置不足以支撑全量请求。切换至配置更优的实体机 Redis 节点后，服务才恢复稳定。
以上判断均基于理论推导与经验，缺乏实际监控数据的有力支撑。这次故障暴露了我们在性能观测上的盲区，也促使我们重新审视 Redis 的性能压测与指标分析方法。
如何科学分析 Redis 性能
为了避免类似'盲猜'的情况再次发生，我们需要建立标准化的性能分析流程。
1. 关注核心指标
在排查 CPU 占用过高时，不能只看 CPU 使用率，还需结合以下维度：
- 网络带宽：检查是否有大流量突发或攻击。
- 内存使用：观察是否触发 Swap 交换。
- 慢查询日志：通过
slowlog定位耗时命令。 - 客户端连接数：确认是否存在连接泄露或风暴。
2. 压力测试验证
在生产环境进行压测前，务必在预发环境模拟真实场景。使用 redis-benchmark 工具时，注意区分不同命令的权重，避免单一命令掩盖整体瓶颈。
# 示例：基准测试，每秒 10000 次请求
redis-benchmark -q -n 10000 -c 50
3. 监控告警完善
建议接入 Prometheus + Grafana 监控体系，对 Redis 的关键指标设置阈值告警。例如，当 CPU 持续超过 80% 或 QPS 突增 50% 时，立即通知运维人员介入。
总结
Redis 虽然性能优异，但在高并发场景下仍需精细调优。本次故障提醒我们，单纯依靠经验推断是不够的，必须依赖数据驱动决策。完善的压测方案与实时监控体系，才是保障线上稳定的基石。
