面经策

线上发现 Redis 机器爆了，如何优化？ ​

  • 标签：后端、场景题

🏛 业务架构师 ​

线上 Redis 机器故障（内存/带宽/CPU 打满），我的处置按止血→定位→根治，全程以业务优先级为纲：

第一步：定性（1 分钟内）

  • 监控看是内存、CPU、网络带宽哪个维度爆——三种根因完全不同；
  • 看是单实例还是集群性的：单实例（热点/大 key 问题）vs 全集群（流量暴涨/批量过期）。

第二步：止血（保业务）

  • 主从切换/故障转移：哨兵或云托管自动切，手动兜底；
  • 非核心使用方降级：统计、通知类应用先断开或限流——牺牲非核心保核心；
  • 核心读走本地缓存快照（如有）或 DB 限流读；
  • 带宽打满：扩带宽/升配、限流上游写。

第三步：定位优化（按最常见根因排）

  1. 热点 key：单分片 CPU 独高——本地缓存 L1 + key 打散多副本；
  2. bigkey：--bigkeys 扫描——拆分、UNLINK 异步删；
  3. 慢命令：slowlog 查——keys */大集合操作，改 scan 分页；
  4. 持久化拖累：fork 停顿 + 磁盘 IO 抢占——错峰、关不必要持久化；
  5. 容量真不够：业务自然增长——垂直升配快速、水平拆实例根治（按业务拆比集群化更省心）；
  6. 网络流量：大 value 压缩、减少全量拉取（改增量/字段级）。

根治与预防机制：

  • 水位告警前移：内存 70%、带宽 60%、CPU 60% 预警；
  • 周期巡检（bigkey/热点/慢查询）制度化；
  • 大促容量预案：活动前压测 + 提前扩容——把"线上爆了"变成"事前算了"。

一句话：Redis 爆机的优化主轴是**"先切流保业务，再按数据找根因"**——八成故障根因在使用方式（热点、大 key、慢命令），两成才是容量。

🏗 系统架构师 ​

"Redis 机器爆了"我按止血 → 定位 → 治理 → 预防的故障响应流程答：

1. 止血（分钟级）：

  • 确认影响面：主节点 or 从库、单实例 or 集群分片；哨兵/集群是否已完成 failover（多数场景自动切换，应用自愈）；
  • 若未切换：手动提升从库、客户端切流量；
  • 应用侧：缓存层降级开关（熔断对 Redis 的调用，读走 DB 限流兜底 + 本地缓存），保护 DB 不被二度击垮——Redis 挂时 DB 的限流必须提前配好。

2. 定位根因：

  • 内存爆：OOM 被杀？看 big key（--bigkeys）、淘汰策略是不是 noeviction、TTL 覆盖率；
  • CPU 爆：慢命令阻塞（slowlog）、大 key 操作、热点 key 单分片打满、持久化 fork 压力；
  • 网络/连接：连接数打满（maxclients）、带宽打满（monitor 误用、大 value 频繁拉取）；
  • 磁盘：AOF 写满、RDB 写盘 IO 故障。

3. 治理：

  • big key 拆分、TTL 补齐、淘汰策略改 allkeys-lfu；
  • 热点 key 本地缓存化；
  • 容量扩容/增加分片（SCAN 双写迁移）；
  • 持久化与内存配比调整（fork 内存翻倍预留）。

4. 预防机制：容量水位 70% 告警、慢日志与延迟监控常开、big key 周扫、故障演练（定期 kill 节点验证自动切换与降级链路）。

核心架构观点：Redis 故障的损失取决于降级预案——缓存架构必须回答"Redis 不可用时，DB 能不能活"。

💻 全栈开发专家 ​

"爆了"分两种：CPU 100% 或内存打满，处理顺序：止血 → 定位 → 优化 → 预防。

第一步：止血（5 分钟内）

  1. 客户端开启熔断降级：非核心读直接返回兜底数据，核心是别让流量全砸到 DB（Redis 挂了最大风险是 DB 被打穿）；
  2. 入口限流降级，非核心功能先关；
  3. 有从库/集群其他节点，切读流量。

第二步：定位（看什么爆了）

  • CPU 100%：redis-cli --hotkey 找热 key；慢查询 SLOWLOG GET 看有没有 HGETALL/大 key 操作；info commandstats 看哪类命令重；
  • 内存爆：info memory + --bigkeys；淘汰策略是不是 noeviction；碎片率是否异常；
  • 网络：监控网卡打满没（大 value 高频读写）。

第三步：针对性优化

  • 热 key → 本地缓存（Caffeine 3~5s）+ key 打散；
  • bigkey → 拆分 + UNLINK 删除；
  • 慢命令 → 换 SCAN/分页，禁 keys *；
  • 单机瓶颈 → 上 Cluster 扩分片/读写分离；
  • 单实例内存太大 → 拆实例（控制 10GB 内，防 fork 卡顿）。

第四步：预防（制度化）

  • 容量水位告警（内存 70%、CPU 60%、网卡 50%）；
  • 大 key/热 key 巡检定时任务；
  • 压测容量基线，大促前扩容；
  • 降级预案演练：Redis 故障时 DB 限流值是多少、哪些接口走兜底，提前写进预案而不是临场决策。