当前位置：首页 > 问答 > 正文

Redis里搞个灵活的二级缓存，怎么实现才靠谱又实用

帖慧艳
问答
2026-01-01 13:30:56
2

关于在Redis里实现一个既靠谱又实用的灵活二级缓存，我们可以参考一些常见的架构思想和实践方案，比如来自互联网架构中常见的“本地缓存+分布式缓存”模式，并结合Spring框架等常见技术栈的实现思路，核心目标很简单：既要快（减少直接访问数据库），又要稳（防止缓存击穿、雪崩），还要活（能方便地更新和失效）。

核心思想：分层与分工

最直接靠谱的思路就是搞一个两级结构，第一级是本地缓存，也就是直接放在应用服务器内存里的缓存，比如用Caffeine或者Ehcache，第二级才是Redis,作为一个所有应用服务器都能访问的公共缓存。

分工是这样的：
1. 本地缓存（L1缓存）： 它的特点是速度极快，因为就在应用进程内，没有网络开销，但它容量小，而且只在当前服务器生效，其他服务器上的本地缓存可能数据不一致，所以它非常适合存放那些更新不频繁、但访问量极高的数据，比如一些基础配置项、热点商品信息等。
2. Redis缓存（L2缓存）： 它的特点是容量可以很大（相对于单机内存），并且是分布式的，所有应用服务器看到的数据都是一致的，但它有网络开销，速度比本地缓存慢，它用来存放更全量的热点数据,并作为本地缓存的备份和统一存储层。
工作流程（引用常见的“旁路缓存”模式思路）： 当应用需要读一个数据时：
- 第一步：先查自己的本地缓存，如果有（命中），直接返回,爽快。
- 第二步：如果本地缓存没有（未命中），就去查Redis。
- 第三步：如果Redis里有，把数据取回来，一方面返回给应用，另一方面顺便在自己本地缓存里存一份（设置一个较短的过期时间）,然后返回。
- 第四步：如果Redis里也没有，那没办法了，只能去查数据库，查到后，先写入Redis（设置过期时间），再写入本地缓存,最后返回数据。

这样做的好处是，热点数据会被自动“推”到访问最频繁的服务器本地，响应速度最快,Redis层扛住了大部分直接访问数据库的请求。

Redis里搞个灵活的二级缓存，怎么实现才靠谱又实用

如何保证“靠谱”？解决常见坑点

光有分层还不够，得考虑各种异常情况，这才是“靠谱”的关键。

缓存穿透（查不存在的数据）：
- 问题： 有人恶意或意外地频繁请求一个数据库中根本不存在的数据,导致请求每次都穿过缓存打到数据库上。
- 实用解法： 当从数据库也查不到这个数据时，也在Redis里缓存一个空值（比如"NULL"），并设置一个较短的过期时间（比如1-5分钟），这样下次再请求这个不存在的数据时，在Redis层就被拦住了，不会攻击数据库，本地缓存同理,也可以缓存空值。
缓存击穿（热点key突然过期）：
- 问题： 一个热点key在Redis里过期了，此时有大量请求同时涌来，全部穿透到数据库,瞬间压力巨大。
- 实用解法： 使用分布式锁，当第一个发现Redis缓存过期的请求，先去拿到一个基于Redis的分布式锁，然后只有这个拿到锁的请求有权去数据库加载数据，其他请求要么等待锁释放后直接读取新缓存，要么可以先返回一个旧的数据（如果业务允许），这样可以保证只有一个请求去重建缓存，对于本地缓存，由于是单机，用本地锁（如Java的synchronized或ReentrantLock）控制单机只有一个线程去加载即可。
缓存雪崩（大量key同时过期）：
- 问题： 设置缓存时，如果一大批key的过期时间都一样，那么它们很可能在同一时刻失效,导致所有请求都砸向数据库。
- 实用解法： 给缓存数据的过期时间加上一个随机值，比如基础过期时间是1小时，那么实际过期时间可以设为 1小时 + (0到10分钟之间的随机数)，这样就能让key的失效时间点分散开,避免集体失效。
数据一致性（本地缓存和Redis不一致）：
- 问题： 当数据更新时,如何让所有服务器上的本地缓存都知道数据变了？
- 实用解法： 这是一个难点，完全强一致会很复杂，一个实用且够用的方法是：主动失效。
  - 当有操作更新了某条数据时，在更新数据库后，立即删除Redis中对应的key。
  - 需要发布一个消息（可以用Redis的Pub/Sub功能，也可以用MQ如RabbitMQ、Kafka），通知所有应用服务器：“某个key的数据已更新，请删除你们的本地缓存”。
  - 应用服务器监听到这个消息后,就去删除自己本地缓存里的对应数据。
  - 这样，下一个读请求到来时，就会按照流程重新从Redis加载最新数据到本地，这种方法保证了最终一致性，在大多数场景下是足够且实用的，如果对一致性要求不是极端高，甚至可以只删Redis,依赖本地缓存设置较短的过期时间来自动失效。

如何实现“灵活”？

灵活性体现在可配置、可监控。

开关和策略可配置： 可以通过配置中心（比如Apollo, Nacos）动态调整是否开启二级缓存、本地缓存的过期时间大小、是否对某些特定key禁用本地缓存等,这样可以根据业务压力灵活调整。
监控和告警： 必须对缓存的命中率进行监控，既要监控Redis的命中率，最好也能监控本地缓存的命中率，如果本地缓存命中率极低，说明可能没必要用它，反而增加复杂度，如果Redis命中率低，可能要检查热点数据设置是否合理，设置合理的告警阈值,能及时发现问题。
优雅降级： 如果Redis集群挂了怎么办？在设计时，要考虑降级方案，当发现Redis不可用时，可以动态降级为只使用本地缓存，并记录日志告警，虽然数据可能不是最新的，但至少能保证核心业务部分可用,不至于全站崩溃。

一个靠谱又实用的Redis二级缓存实现，核心是“本地+远程”的分层设计，重点是针对穿透、击穿、雪崩和数据一致性这四大难题要有简单有效的应对策略，并通过配置化和监控让整个系统变得灵活可控，它不是一套死板的代码,而是一个可以根据实际业务场景进行裁剪和调整的架构模式。