Redis 架构与缓存治理：高性能背后的失效、穿透与一致性

Redis 是很多系统中最常见的 NoSQL 组件。它快、简单、数据结构丰富，但也最容易被滥用。缓存穿透、缓存雪崩、大 key、热 key、内存碎片、主从延迟、持久化抖动，都可能在高峰期把 Redis 从性能利器变成事故源。

要用好 Redis，必须明确它在系统中的角色：缓存、会话、分布式锁、限流、排行榜、消息队列、临时状态。不同角色对一致性、持久化和高可用的要求完全不同。

缓存模式

最常见的是 Cache Aside：应用先读缓存，未命中再读数据库，然后写回缓存。更新时先更新数据库，再删除缓存。

为什么很多场景选择删除缓存而不是更新缓存？因为缓存数据可能是复杂聚合结果，直接更新容易出错；删除后下一次读取重建，逻辑更简单。

但删除缓存也有并发窗口。常见改进包括：

• 设置合理 TTL。
• 删除失败时重试。
• 使用消息队列异步失效。
• 对强一致路径避免使用缓存作为唯一判断来源。

缓存穿透、击穿与雪崩

缓存穿透指查询不存在的数据，导致请求直接打到数据库。解决方法包括缓存空值、布隆过滤器、参数校验和限流。

缓存击穿指热点 key 过期瞬间，大量请求同时回源。解决方法包括互斥重建、逻辑过期、热点 key 预热。

缓存雪崩指大量 key 同时过期或 Redis 故障，导致后端被打垮。解决方法包括 TTL 加随机抖动、多级缓存、熔断降级、核心 key 预热。

这些问题的本质是缓存层把流量峰值传递给了数据库。缓存治理就是控制回源流量。

大 key 与热 key

大 key 会造成网络阻塞、持久化压力、迁移慢、删除慢。常见大 key 包括超大 Hash、List、Set、String。应通过扫描和监控定期发现。

热 key 是访问量极高的 key，可能让单个 Redis 节点 CPU 或网络打满。解决方式：

• 本地缓存。
• key 分片。
• 读副本扩展。
• 热点数据预计算。
• 对非强一致场景使用多副本缓存。

Redis Cluster 虽然能分片，但单个 key 仍然只在一个 slot 上。热 key 不会因为集群存在而自动消失。

过期策略与淘汰策略

TTL 设计要结合业务语义。太短会增加回源，太长会增加脏数据窗口。对热点数据，可以使用逻辑过期：缓存中保存过期时间，读取时发现逻辑过期后异步刷新，旧值仍可短暂返回。

淘汰策略要谨慎选择。allkeys-lru、volatile-lru、allkeys-lfu 等策略适合不同场景。如果 Redis 同时存储不可丢的会话和可丢的缓存，淘汰会非常危险。建议不同用途使用不同实例或集群。

持久化

Redis 持久化包括 RDB 和 AOF。RDB 适合快照备份，AOF 提供更细粒度恢复。开启持久化会带来磁盘 IO 和 fork 开销，需要监控延迟。

如果 Redis 只是纯缓存，可以不追求强持久化，但要确保数据库能承受缓存重建。如果 Redis 存储会话、队列或业务状态，就必须设计持久化和恢复。

一个原则：不要让 Redis 承担你没有明确恢复方案的数据责任。

高可用

Redis Sentinel 适合主从自动故障切换，Redis Cluster 提供分片和高可用。选择取决于数据规模和吞吐需求。

要关注：

• 主从复制延迟。
• 故障切换时间。
• 客户端是否支持拓扑更新。
• Cluster slot 迁移影响。
• 网络分区下的写入风险。

应用客户端配置非常关键。连接池、超时、重试、读写分离策略不合理，会在故障切换时放大问题。

分布式锁

Redis 常被用于分布式锁，但要谨慎。锁必须设置过期时间，释放锁时要校验 owner，避免误删别人的锁。简单实现：

SET lock_key token NX PX 30000

释放时用 Lua 脚本检查 token 后删除。对金融交易、库存扣减等强一致业务，不要只依赖 Redis 锁作为唯一一致性保障。

监控指标

生产 Redis 至少监控：

• QPS。
• p95/p99 延迟。
• 内存使用和碎片率。
• key 数量。
• 命中率。
• evicted keys。
• expired keys。
• blocked clients。
• replication lag。
• slowlog。

命中率不是唯一指标。一个 99% 命中率的缓存，如果 1% 回源集中在热点接口，也可能打垮数据库。

总结

Redis 的价值来自速度，也正因为速度太快，错误设计会把问题放大得更快。生产中要把缓存模式、失效策略、热点治理、持久化、高可用和客户端行为一起设计。Redis 不是万能数据库，它更像系统里的高性能加速层和临时状态层。用得好，系统轻盈；边界不清，事故会来得很快。