Redis缓存崩溃别慌，这些招数帮你稳住缓存不掉链子

Redis缓存要是突然崩了，那感觉就像是超市的收银系统全瘫痪了，所有顾客（请求）都堵在门口，直接冲向后方的仓库（数据库），数据库哪见过这阵势，分分钟就可能被压垮，导致整个网站或应用卡死、报错，这就是常说的“缓存雪崩”的极端情况，别慌，稳住心态，咱们一步一步来,看看有哪些招数能帮你扛过去。

第一招：事前预防，给缓存上个“保险”

老话说得好，防患于未然,最好的情况就是缓存根本不崩溃。

• 高可用架构是基石：别把鸡蛋放在一个篮子里，单一节点的Redis实例风险太高了，业界普遍的做法是采用主从复制（Replication）加哨兵模式（Sentinel），简单说，就是弄一个主Redis（Master）负责写，多个从Redis（Slave）同步主的数据并负责读，再安排几个“哨兵”进程，7x24小时盯着主节点，一旦主节点挂了，哨兵们能自动开会投票，从从节点里选出一个新的主节点，继续提供服务，这样即使一台机器宕机，缓存服务基本不受影响。（来源：常见于Redis官方文档及技术社区架构讨论）
• 持久化数据要双管齐下：Redis虽然快，但数据是存在内存里的，一断电就没了，所以必须定期把数据写到硬盘上，这叫持久化，Redis提供了两种方式：RDB（快照，定期全量备份）和AOF（日志，记录 every write operation），只开一种都不完美，RDB恢复快，但可能会丢失最近几分钟的数据；AOF数据更安全，但文件大恢复慢，生产环境通常两者都开启，用RDB做冷备，用AOF保证数据完整性，这样即使缓存集群全瘫，也能用持久化文件快速重建缓存，减少数据损失。（来源：Redis官方文档核心概念）
• 监控告警不能少：给你的Redis集群装上“心电图”，监控关键指标，比如内存使用率（快满了就要扩容或清理）、CPU负载、连接数、持久化状态等，一旦发现指标异常，比如内存使用率超过80%，或者主从连接断开，监控系统要能立即发短信、发邮件通知你，让你在问题刚冒头时就发现，而不是等用户投诉了才知道。（来源：运维社区最佳实践）

第二招：事中止损，快速拉起服务

万一预防措施没挡住，缓存真的崩了，首要目标是保护数据库,尽快恢复服务。

• 服务降级与熔断：这时候要果断“舍车保帅”，在业务代码中，当发现访问Redis超时或失败时，不能无休止地重试或者直接抛错给用户，可以启用熔断器模式：连续失败10次后，熔断器“跳闸”，在接下来一段时间内（比如30秒），所有请求直接走降级方案，不再访问Redis和数据库，降级方案可以是返回默认值、静态页面，或者从本地缓存（如Ehcache）读取部分数据，目的是给数据库筑起一道防火墙，防止它被冲垮。（来源：微服务架构常见设计模式,如Hystrix）
• 快速判断与重启：如果是单个Redis实例崩溃，首先通过监控查看是否是机器本身的问题（如宕机），如果是Redis进程假死，可以尝试快速重启，但重启后，大量请求会瞬间涌入，可能再次压垮刚启动的Redis，这时可以配合延迟预热：在应用启动时，先不放量，让缓存慢慢从数据库加载热点数据，等数据加载得差不多了，再开放所有流量。（来源：技术博客中的故障处理经验分享）
• 启用备用缓存：如果架构设计时考虑了多级缓存，比如在应用本地还有一层Guava Cache或Caffeine，那么即使Redis挂了，本地缓存还能扛住一部分热点数据的请求,给恢复争取更多时间。

第三招：事后复盘，避免重蹈覆辙

故障处理完，事情还没结束,一定要开复盘会。

• 分析根因：这次崩溃到底是为什么？是内存不够导致OOM（内存溢出）？是某个慢查询拖垮了整个实例？是网络分区？还是被人误操作了？找到根本原因,才能对症下药。
• 完善预案：根据这次教训，更新你的应急预案，明确缓存崩溃后的处理步骤、沟通机制、升级流程，下次再发生，大家就能按部就班,不至于手忙脚乱。
• 容量规划与优化：根据业务增长趋势，提前规划缓存的容量，该扩容时就扩容，定期审查Redis的慢查询日志，优化那些耗时的命令，比如避免使用KEYS *,对大集合进行拆分等。

特别提醒：对付缓存穿透和雪崩

缓存崩溃是极端情况，更常见的是缓存穿透和雪崩问题,它们的应对策略也是缓存稳定性的关键。

• 缓存穿透：指的是查询一个根本不存在的数据，缓存没有，数据库也没有，大量这样的请求会直接打到数据库上，解决办法：1）缓存空值：即使数据库查不到，也在缓存里存个空值或特殊标记，并设置一个较短的过期时间（比如1分钟），下次同样的请求就直接返回空了，2）布隆过滤器（Bloom Filter）：在缓存之前加一层布隆过滤器这个“安检员”，它能快速判断一个key是否肯定不存在于数据库中，对于不存在的key，直接拦截掉，避免对数据库的无效查询。（来源：解决缓存问题的经典算法方案）
• 缓存雪崩：指的是缓存中大量数据同时过期，导致所有请求这些数据的请求都涌向数据库，解决办法：1）给过期时间加随机值：设置缓存过期时间时，不要都设成一样的，比如基础时间加上一个随机数（如30分钟 +/- 随机5分钟），让key的过期时间分散开，2） 热点数据永不过期：对一些极端热点的数据，可以设置成永不过期，然后由后台任务定期去更新它，3） 互斥锁更新：当缓存失效时，不是所有线程都去查数据库，而是用分布式锁保证只有一个线程去重建缓存，其他线程等待。（来源：技术社区针对高并发场景的常见解决方案）

Redis缓存稳定性是一个系统工程，需要从架构设计、监控预警、故障处理、代码逻辑多个层面共同保障，平时多流汗，战时才能少流血，把这些招数都用上,你的缓存系统稳健性一定会大大提升。