2. Redis生产环境风险地图

Redis 在生产环境中的故障很少是单一原因造成的，更多时候是多个风险点叠加后被某个触发条件引爆。要建立可演练、可恢复的故障体系，第一步不是急着写脚本，而是先把“风险地图”画清楚：哪些故障会直接影响可用性，哪些会拖慢响应，哪些会破坏数据一致性，哪些会在恢复过程中制造二次伤害。本节围绕八类典型场景展开，重点说明它们的触发条件、可观测信号、影响面以及演练时的观察点。

一、缓存穿透：查询不存在的数据

缓存穿透指请求查询的 key 在缓存和数据库中都不存在。每次请求都会穿过 Redis 打到数据库，如果这类请求量很大，数据库会被无效查询压垮。典型触发场景包括：恶意攻击使用随机不存在的 ID 刷接口、业务代码对空结果没有做缓存、参数校验缺失导致非法 key 直接进入查询链路。

可观测信号是：Redis 命中率骤降、数据库 QPS 异常升高、大量 key 查询返回 nil。演练时可以构造一批不存在的用户 ID，以固定速率持续请求，观察数据库连接池是否被占满。防护手段通常有两类：一是缓存空值并设置较短过期时间，二是用布隆过滤器在入口层拦截明显不存在的 key。演练重点不是验证防护是否生效，而是确认在防护失效时系统能撑多久、数据库先出现什么症状。

二、缓存雪崩：大量 key 同时失效

缓存雪崩与穿透的区别在于：穿透是查不存在的数据，雪崩是大量原本存在的 key 在同一时间集中过期，导致请求同时涌向数据库。常见诱因是批量预热时给同一批 key 设置了相同的 TTL，或者 Redis 实例整体重启后缓存全部为空。

演练时可以模拟一批 5000 个 key 在 10 秒内集中过期，观察数据库 QPS 曲线是否出现尖峰、Redis 命中率是否断崖式下跌。防护思路包括：TTL 加随机抖动、多级缓存、热点数据永不过期配合后台更新、以及数据库层的限流和降级。雪崩的恢复难点在于数据库已经被打满，此时即使 Redis 恢复，请求也不会立刻回落，需要配合熔断和队列削峰。

三、热 key：单点流量集中

热 key 指某个 key 的访问量远超其他 key，导致单个 Redis 节点 CPU 或网络带宽被打满。典型场景是秒杀商品、明星八卦、突发热点事件。热 key 的危险在于它不会让整个集群崩溃，但会让承载该 key 的节点成为瓶颈，进而影响该节点上的其他 key。

可观测信号是：单节点 CPU 使用率明显高于其他节点、该节点网络流入流出量异常、慢查询日志中出现大量同一 key 的 GET 操作。演练时可以用 redis-cli --hotkeys 或 monitor 采样统计 key 访问频率，确认热 key 位置。缓解手段包括：本地缓存、key 拆分、读写分离、以及将热 key 复制到多个节点分散压力。

四、大 key：单 key 体积过大

大 key 通常指 String 类型超过 10KB，或集合类型元素超过 5000 个。大 key 的危害是多方面的：删除时阻塞主线程、迁移时造成网络拥塞、持久化时产生巨大 RDB 文件、主从同步时延迟加剧。常见来源是业务把整个列表或哈希塞进一个 key，或者历史数据没有清理。

演练时可以用 redis-cli --bigkeys 扫描，或对已知大 key 执行 DEL 并观察延迟。更安全的做法是用 UNLINK 异步删除，或分批用 HSCAN、SSCAN 逐步清理。判断标准是：单次操作延迟是否超过 10ms、是否引发主从复制缓冲区溢出、是否导致 RDB 重写时间明显拉长。

五、内存溢出：达到 maxmemory 后的行为

当 Redis 内存达到 maxmemory 且淘汰策略无法释放足够空间时，写命令会返回 OOM 错误。如果策略设置为 noeviction，所有写操作直接失败；如果设置为 allkeys-lru，则可能淘汰掉仍在使用的 key，造成缓存命中率下降。演练时需要观察：内存增长曲线、淘汰 key 数量、写命令错误率、以及是否触发 RDB 或 AOF 重写。

关键判断依据是 info memory 中的 used_memory、maxmemory、evicted_keys 三个指标。如果 evicted_keys 持续增长但 used_memory 仍居高不下，说明存在大 key 或内存碎片问题，需要进一步用 MEMORY USAGE 定位。

六、持久化失败：RDB 与 AOF 异常

持久化失败通常表现为：RDB 快照因 fork 失败或磁盘空间不足而中断，AOF 因写入错误或 fsync 策略配置不当而丢失数据。演练时要关注 lastsave 时间是否停滞、aof_last_write_status 是否为 err、以及磁盘剩余空间。如果 RDB 失败后 Redis 仍继续接受写入，一旦发生重启，这段时间的数据将全部丢失。

恢复时不能只看 Redis 进程是否存活，必须验证持久化文件是否完整、能否成功加载。建议在演练中主动制造磁盘满或权限错误，观察 Redis 的日志输出和客户端表现。

七、主从延迟：复制链路滞后

主从延迟指从节点执行主节点同步过来的命令落后于主节点。延迟过大时，读从节点会读到旧数据，故障切换时可能丢失更多数据。可观测指标是 master_repl_offset 与 slave_repl_offset 的差值，以及 info replication 中的 lag 字段。

常见原因包括：从节点执行大 key 操作、网络带宽不足、主节点写入量突增、从节点配置过低。演练时可以持续写入并观察延迟变化，确认延迟是否随写入速率线性增长。如果延迟持续超过阈值，应考虑增加从节点、优化大 key、或调整 repl-backlog-size。

八、集群脑裂：网络分区下的双主

脑裂发生在集群网络分区时，主节点与哨兵或集群其他节点失去联系，但客户端仍能写入该主节点。当网络恢复后，这个旧主节点会被降级为从节点，期间写入的数据全部丢失。演练时需要模拟网络分区，观察哨兵是否触发故障转移、旧主节点恢复后是否自动重连并同步。

关键防护参数是 min-replicas-to-write 和 min-replicas-max-lag，它们能限制主节点在从节点数量不足或延迟过大时拒绝写入，从而减少脑裂期间的数据丢失。演练判断依据是：故障转移期间是否有写入被拒绝、恢复后数据差异量是否在可接受范围内。

风险地图的使用方式

这张图不是用来背诵的，而是用来做演练设计的。每个风险点都应该对应一组可观测指标、一个触发条件、一个恢复目标。例如，针对缓存穿透，演练目标是“数据库连接池被打满后，系统能否在 30 秒内通过限流恢复”；针对主从延迟，演练目标是“延迟超过 5 秒时，读请求能否自动切换到主节点”。

在实际排查中，多个风险点往往同时出现。比如大 key 会导致主从延迟，主从延迟又会在故障切换时放大集群脑裂的数据丢失。因此，风险地图的价值在于帮助我们在故障发生时快速定位“根因链”，而不是只处理表面症状。建议把这张图贴在演练看板上，每完成一次演练，就在对应节点上标注实际观测到的指标阈值和恢复耗时，逐步形成属于自己系统的风险基线。