崩堡垒怎么抵抗那个烦人的Redis缓存雪崩问题，真是头疼啊

崩堡垒怎么抵抗那个烦人的Redis缓存雪崩问题,真是头疼啊，这个问题说白了，就是一大堆缓存数据在同一时间突然都失效了，或者Redis服务器自己挂掉了，导致所有的请求像雪崩一样，哗啦啦地全都直接砸到了后面的数据库上，数据库平时有缓存挡着，优哉游哉的，突然面对这么多请求，根本扛不住，轻则响应变慢，整个系统卡顿，重则直接宕机，引发连锁反应，整个服务都可能瘫痪，这确实非常让人头疼。

要解决这个问题,咱们不能指望它不发生，得从根儿上想办法，让即使发生了雪崩，系统也能扛得住，或者把冲击降到最低，下面这几招，都是实践中摸爬滚打总结出来的，咱们一个一个说。

第一招，别让缓存同时失效，给它们错开时间。 这是最直接也是最有效的一招，你想啊，雪崩为啥发生？就是因为缓存键的过期时间（TTL）设置得太一致了，咱们图省事，给一万个缓存数据都设置成一样的过期时间，比如一小时，那么一小时之后，这一万个缓存会同时失效，这一万个数据的请求就全都得去查数据库，数据库可不就压力山大了嘛。

那怎么办呢？很简单，在设置缓存过期时间的时候，加个随机数，原本都想设置成一小时过期，现在可以改成“一小时 + 一个随机的几分钟”，可以是61分钟，也可以是63分钟，或者55分钟，这样一来，缓存失效的时间点就被打散了，就不会集中在某一个时刻，虽然总体上缓存还是会陆续失效，但数据库在每个时间点需要承担的请求量就变得平缓多了，就像把一场暴雪变成了连续几天的小雪，危害性就大大降低了，这个方法是《Redis实战》这本书里提到过的经典策略。

第二招，给热点数据上个“永不过期”的保险，但背后偷偷更新。 对于一些特别重要、访问频率极高的热点数据，我们可以考虑不设置过期时间，让它们永远待在缓存里，这样就从根源上避免了它们因为过期而失效的问题。

数据总归是要更新的呀？不然用户就看到旧数据了，这时候，咱们可以用“后台更新”的策略，具体有两种做法：一种是启动一个独立的定时任务，定期去数据库里取出最新的数据，然后悄悄地更新到Redis里，用户无感知，另一种是，当发现某个数据有更新操作时（比如管理员在后台修改了商品价格），在更新数据库之后，立刻也把Redis里的缓存给更新掉，这样既能保证数据的及时性，又避免了缓存失效的冲击，这种做法在很多大型互联网公司的架构中都有应用，比如电商网站的核心商品信息就常用这种方式。

第三招，在数据库前面设一道“闸门”，防止被冲垮。 这一招是最后的防线，它的核心思想是：即使缓存雪崩真的发生了，我们也要拼命保护数据库不挂，这里常用的技术叫做“熔断”和“降级”，还有“限流”。

• 熔断： 可以想象成电路里的保险丝，当系统检测到访问数据库的请求异常比例太高（比如超过50%），或者响应时间长得离谱，就自动“熔断”，在一段时间内，所有尝试访问数据库的请求都会被直接拒绝掉，给数据库喘息的机会，等过一会儿，系统感觉数据库应该缓过来了，再慢慢恢复访问。
• 降级： 当系统压力巨大时，我们可以暂时关闭一些非核心的功能，或者给用户返回一个默认的、稍微简单点的结果，在商品详情页，如果推荐商品列表的数据库查询压力太大，可以先不显示这个列表，或者只显示一个静态的、预先准备好的热门商品列表，牺牲一部分用户体验，保住核心的交易流程不挂掉。
• 限流： 这个更好理解，就是严格控制在一秒钟内，能打到数据库上的请求数量，我们设定一秒只允许1000个请求查询数据库，多出来的请求，要么让它们排队等待，要么直接返回一个“系统繁忙，请稍后再试”的提示，这就像节假日景区限流一样，虽然有些人进不去，但保证了里面的人不至于被挤垮。

这些保护数据库的机制,Netflix开源的Hystrix库是这方面的鼻祖，虽然现在有更多新的工具，但思想是相通的。

第四招，搭建高可用的Redis集群，让缓存服务本身更结实。 上面说的都是缓存失效后怎么办，我们还得想想，万一不是缓存失效，而是Redis服务器本身宕机了呢？这也会引发雪崩，不能让Redis单点运行，得给它组个团。

常见的做法是搭建Redis主从复制（Replication）加哨兵（Sentinel）模式，简单说，就是搞一个主Redis（Master）负责写，多个从Redis（Slave）负责读和备份，哨兵呢，就是个监工，时刻盯着主Redis是否健康，一旦主Redis挂了，哨兵会立刻自动从从Redis里选举出一个新的主Redis，接替工作，这样，整个缓存服务就能在几十秒内自动恢复，对外的影响降到最低，如果要求更高，还可以用Redis Cluster集群模式，能把数据分片存储在多个节点上，性能和可用性更高，这是Redis官方文档里重点介绍的高可用方案。

第五招，在应用内部搞个“本地缓存”，多一层保护。 除了使用Redis这种分布式的缓存，我们还可以在每一个应用程序服务器的内存里，搞一个小型的本地缓存，可以用Google的Guava Cache或者Caffeine这样的库来实现。

对于一些极其热点、变化又不频繁的数据，比如城市列表、配置信息等，可以在应用启动时就加载到本地内存里，这样，即使Redis完全挂掉，应用本身还能依靠本地缓存提供最基础的服务，不至于完全崩溃，这招要慎用，因为要考虑到本地缓存的数据一致性问题和内存占用问题。

抵抗缓存雪崩,不能靠单一方法，得组合拳出击：“过期时间随机化”是预防，“热点数据永不过期”是重点保护，“熔断降级限流”是兜底保障，“Redis集群”是提升自身可靠性，“本地缓存”是最后一道防线。 根据自己系统的实际情况，把这些策略灵活地用起来，就能大大增强系统面对缓存雪崩时的抵抗力，晚上睡觉也能更踏实些。