Redis高可用搭配缓存设计，聊聊怎么避免雪崩和穿透这两大坑

综合参考了互联网技术社区常见讨论、博客文章如CSDN、掘金、InfoQ等技术平台，以及《Redis设计与实现》等书籍中的核心思想,并结合常见的工程实践进行阐述）

Redis现在几乎是每个互联网应用都离不开的缓存工具，它的速度非常快，能极大地减轻后端数据库的压力，如果用得不好，它不但不能成为帮手，反而可能成为系统稳定性的“炸弹”，缓存雪崩和缓存穿透就是两个最经典、最容易踩的坑，要避免这些坑，我们得从两个层面入手：一是把Redis本身弄得结实一点，也就是高可用架构；二是在使用缓存的设计上多动脑筋。

我们来聊聊怎么让Redis本身更可靠，也就是高可用搭配。

想象一下，如果你的网站只有一个Redis实例，它一旦宕机，所有的请求就会像洪水一样直接冲向后端的数据库，数据库很可能瞬间就被冲垮，整个服务就不可用了，这其实就是最极端的一种“雪崩”,我们不能把鸡蛋放在一个篮子里。

常见的做法是采用主从复制加上哨兵的模式，就是部署多个Redis实例，其中一个作为“主”节点，负责处理主要的写请求和读请求；其他几个作为“从”节点，实时地从主节点那里同步数据，这样做好处是，读请求可以分散到多个从节点上，提升了读性能，但更重要的是，我们还会部署一套独立的“哨兵”系统，哨兵就像是Redis实例的监护者，它会不断地检查主节点是否还活着，一旦发现主节点宕机了，哨兵们就会开会协商，自动从剩下的从节点中选举出一个新的主节点，然后通知所有的客户端连接新的主节点，这个过程是自动化的，虽然会有一小段时间的不可用，但很快就能恢复，避免了长时间的服务中断，这就好比家里的电路跳闸了，备用发电机能够自动启动,保证关键设备不停电。

还有一种更高级的架构叫Redis集群，它把数据分片存储在多个主节点上，每个主节点也有自己的从节点，这样不仅实现了高可用（任何一个主节点宕机，其从节点会顶上来），还实现了数据的分布式存储，可以突破单机内存的限制，承载更大的数据量，这就好像一个大型仓库，把货物分区域存放在多个房间里，每个房间都有备份钥匙，即使一个房间失火了，其他房间还能正常运作,并且总的存储空间变大了。

有了结实的基础设施，我们再来重点看怎么通过设计来避免那两大坑。

第一个大坑：缓存雪崩。

雪崩是什么意思？它指的是在某一时刻，缓存中大量的数据同时过期失效，或者Redis服务整体宕机，这时，所有原本应该命中缓存的请求，都会直接去查询数据库，导致数据库瞬间承受巨大的压力，甚至崩溃,进而引起整个系统的连锁故障。

怎么避免呢？

1. 给过期时间加个随机值：这是最常用也最简单的方法，不要给所有的缓存数据设置相同的过期时间，我们通常设置缓存失效时间为1小时，那么可以在这个基础上，加上一个几分钟的随机值，这样，大量缓存就不会在同一秒内同时失效，而是均匀地分布在一段时间内失效,对数据库的冲击就变得平缓了。
2. 设置永不过期的热点数据：对于一些极其热门、几乎不会变化的数据，比如首页的导航栏信息、城市列表等，可以考虑设置为永不过期，然后通过后台任务或者程序在更新数据库时，主动去更新缓存,这样就完全避免了因过期而产生的雪崩风险。
3. 建立缓存降级和服务熔断机制：当发现数据库压力巨大，快要撑不住的时候，系统应该能主动“降级”，直接返回一个默认值（如“服务繁忙，请稍后再试”），或者返回一些非核心的、稍微过时的数据，而不是一味地让所有请求都去冲击数据库，服务熔断是指，当失败请求达到一定阈值时，暂时停止访问有问题的服务（比如数据库），给数据库喘息的机会，这需要引入像Hystrix、Sentinel这样的组件来实现。
4. 提前预热缓存：在系统即将迎来高流量之前（比如大促活动），可以提前把主要的数据加载到缓存中,并确保它们的过期时间错开。

第二个大坑：缓存穿透。

穿透比雪崩更可怕，它指的是查询一个根本不存在的数据，由于这个数据在缓存中肯定没有，所以每次请求都会穿过缓存去查数据库，如果有人恶意攻击，持续地用大量不存在的关键词来请求,就会导致数据库压力巨大甚至宕机。

解决穿透的核心思路是：即使数据不存在，也不要让请求轻易地到达数据库。

1. 缓存空对象：当从数据库查询不到数据时，我们仍然把这个空结果（比如null）进行缓存，并设置一个较短的过期时间（比如5分钟），这样，后续相同的恶意请求在短时间内再来时，就能在缓存层被挡住，直接返回空结果，从而保护了数据库，这可能会浪费一点缓存空间，但相比于数据库被压垮,这个代价是值得的。
2. 使用布隆过滤器：这是一个更高效的方法，布隆过滤器可以理解为一个很大的二进制向量（或者说一个集合），它能够用很小的空间代价，快速判断一个元素“一定不存在”或“可能存在”于某个集合中，我们在写入数据时，也把数据的Key同步到布隆过滤器中，当有请求过来时，先让布隆过滤器检查一下这个Key是否存在，如果布隆过滤器说“一定不存在”，那么直接返回空结果，根本不用查缓存和数据库，如果布隆过滤器说“可能存在”，我们再继续后续的查询流程，因为布隆过滤器有极小的误判率（即可能把不存在的判为存在），但绝不会把存在的判为不存在，这正好符合我们防止穿透的需求,这种方法非常适合应对恶意攻击场景。

要让Redis真正成为得力助手，我们需要“软硬兼施”。“硬”的方面，通过主从、哨兵或集群搭建高可用的Redis架构，保证服务本身不容易挂掉；“软”的方面，通过错峰过期、缓存空对象、使用布隆过滤器等设计技巧，在业务逻辑层面对缓存雪崩和穿透进行精细化的防御,才能构建一个既高效又稳健的系统。