先说个现象很多团队把 Redis 当万能缓存用QPS 上去了就加集群、加内存觉得 Redis 已经够快。但真到业务体量涨起来你会发现在极端流量下Redis 也会成为瓶颈。我见过一次线上事故Redis 单节点 CPU 冲到 90% 以上所有业务都在抢连接一批核心接口 RT 从几十毫秒飙到几秒最后靠限流才没把数据库拖死。那次事故之后我开始认真研究多级缓存。所谓多级缓存本质上就是把数据按照访问频率和热点程度分布在离用户越来越近的位置浏览器、CDN、Nginx、进程内本地缓存、Redis最后才是数据库。每一层各司其职层层挡流量。这篇文章我会从实际落地角度拆解整套多级缓存设计包括每层缓存的定位、Caffeine 等本地缓存的配置细节、数据一致性怎么保证、以及缓存穿透击穿雪崩在多级缓存下怎么防希望给正在做缓存架构的读者一份可参考的实战笔记。1. 为什么 Redis 扛不住还要引入本地缓存一次事故拆解1.1 Redis 不是慢而是访问 Redis 这件事本身有成本很多人对 Redis 有一个误解Redis 是单线程的处理命令极快平均响应时间在微秒到亚毫秒级别所以只要 Redis 不挂缓存就一定快。这话前半句对后半句有坑。Redis 得快是指数据在内存里、命令执行本身快。但你的应用服务去访问 Redis要经历一次网络往返RTT。即使在同一个机房内网纯网络损耗也要 0.1ms 到 0.5ms再加上客户端连接池获取连接、Redis 侧排队、序列化和反序列化一次长尾请求走到 5ms 以上非常正常。如果是跨机房、跨可用区调用单次 RT 可能直接到 10ms。这还不是最致命的。真正的问题是吞吐量瓶颈。Redis 单实例每秒能处理十万级甚至更高命令看起来很强但你的应用服务每高并发请求要访问多次 Redis连接池会迅速被打满。线上单台应用服务器最多维持数百个并发连接一旦 Redis 端出现抖动或者热点大 key所有线程都会阻塞在获取连接上形成线程池排队最终表现为接口大面积超时。1.2 事故复盘Redis 抖动如何传导到全站那次事故的链路大概是这样的某个核心商品接口先查 Redis空了查 MySQL再回填缓存。平时 QPS 并不算极端但某一天运营做了个推送活动瞬时流量是平时的五倍以上。Redis 单节点 CPU 首先打满。之后所有请求都在等待 Redis 响应Tomcat 线程池被占满新的请求全部排队。更麻烦的是缓存过期时间设置得比较集中大批 key 在同一时刻过期穿透到数据库数据库连接池也扛不住了。事后复盘最大的问题不在于 Redis 不够快而在于架构里缺少一层“进程内缓存”来挡住高频、重复的请求。Redis 虽然快但每个请求都去打一次远程 Redis 就是浪费。如果让大部分请求在本地 JVM 内存里直接命中只有 miss 才去访问一次 RedisRedis 的压力至少能下降一个数量级。当然引入本地缓存不是为了让系统更复杂而是要在合适的位置挡住该挡的流量。这也是为什么多级缓存的第一原则是永远让流量在最靠近用户、成本最低的一层命中。下图就是典型的流量走向你可以在自己系统里对照一下当前请求从进入到返回到底穿透了多少层。浏览器缓存命中则请求根本不会到后端CDN命中则请求不会到达源站 NginxNginx 层缓存命中则不会到达应用服务本地缓存命中则不会访问 RedisRedis命中则不会访问数据库数据库最后兜底2. 多级缓存每一层到底承担什么角色从客户端到数据库的完整分层多级缓存最难的地方不是技术选型而是搞清楚每一层的适用场景和边界。很多人一上来就本地缓存加 Redis 两层看似做了多级实际上本地缓存和 Redis 存的数据一模一样更新逻辑一概通刷根本没有发挥分层的作用。我先按真实请求链路把每一层摆开说清楚每个节点的职责。2.1 浏览器缓存与 CDN离用户最近的两道闸门浏览器缓存通常由 HTTP 响应头控制比如 Cache-Control、Expires、ETag。对于不敏感、允许公开缓存的静态资源这一层就能直接挡掉大量重复请求。静态资源是指图片、CSS、JS、字体这类不经常变化的内容建议全部开启强缓存配合版本号或内容哈希来实现更新。CDN 是第二道闸门适合承载全国甚至全球范围内的静态资源和边缘动态数据。CDN 边缘节点离用户物理距离近能把几十毫秒的延迟降到几毫秒。对纯静态页面或接口的公共部分比如首页的结构化数据、公共配置CDN 回源校验已经足够。但注意 CDN 不适合存强实时、强个性化的数据它的淘汰和刷新存在延迟不适合高一致性场景。2.2 Nginx 层缓存业务入口处的第一道进程内挡板很多后端团队会忽略 Nginx 这一层。Nginx 在反向代理位置能拿到所有请求的访问入口。如果业务允许一定程度的脏读完全可以用 Nginx 的 proxy_cache 模块缓存一部分 GET 接口的响应结果尤其是非登录态、变化频率低的接口。Nginx 缓存命中后直接返回根本不进 Tomcat这是成本极低的一道拦截。我用过 Nginx 缓存配置大概是这样的proxy_cache_path /data/nginx/cache levels1:2 keys_zoneapi_cache:128m max_size10g inactive60m; server { location /api/ { proxy_cache api_cache; proxy_cache_key $host$request_uri$cookie_user_id; proxy_cache_valid 200 304 10s; proxy_cache_valid any 1s; proxy_pass http://backend; } }需要注意 proxy_cache_key 的设计。如果接口和用户相关key 里必须带用户维度信息否则不同用户会串数据如果纯粹是公共数据key 越简单命中率越高。2.3 JVM 进程内缓存毫秒级接口的关键先生进程内缓存在当前主流 Java 体系中通常用 Caffeine 或 Guava Cache。它的最大优势是零网络开销读取速度纳秒级比访问 Redis 快几个数量级。最大缺点也很明显它是应用进程私有的容量小多实例之间数据不共享。所以本地缓存最适合存两类数据极度热点但变化不频繁的 key比如活动配置、商品详情中的公共部分单个实例内可容忍短暂不一致的读取量例如关键接口为了抗住瞬时峰值网上很多教程喜欢说“本地缓存加 Redis 就是多级缓存”但在实际业务中这两类数据必须做差异化选择而不是一股脑把所有数据往本地塞。本地缓存一旦放太多内存吃紧会频繁 GC反而拖垮应用所以容量上限和淘汰策略必须提前设计好。2.4 Redis 层分布式缓存的核心枢纽Redis 在多级缓存架构里扮演的是“事实缓存”和“兜底热数据”双重角色。它承接了从本地缓存 miss 下来的流量并负责多实例之间的数据共享。当某个 key 在本地缓存失效后应用会回源到 Redis只有 Redis 也 miss 时才会打到数据库。为什么不能让 Redis 作为唯一缓存原因在上一节讲过网络往返有成本、连接池有上限。更高阶的做法是Redis 和本地缓存之间的数据同步通过消息广播完成而不是每次写操作都双写。下表是我对多级缓存各层延迟与容量的直观对比方便大家心里有个底层级延迟量级单机容量命中成本典型实现浏览器缓存0ms几 MB 到几十 MB无网络请求HTTP CacheCDN1-10ms取决于节点公网流量CDN 边缘节点Nginx 缓存0.1ms-1ms几 GB 到十几 GB本地磁盘/内存proxy_cache本地进程缓存纳秒到微秒几十 MB 到几百 MBJVM 内存CaffeineRedis0.2ms-2ms几十 GB 到数百 GB网络 IORedis ClusterMySQL/DB1ms-数十ms大磁盘 IO数据库2.5 数据库兜底但不该频繁出场数据库是整个缓存体系最后的“安全网”。多级缓存设计得合理与否本质就是看数据库 QPS 被压到多低。一个健康的读比例接口数据库 QPS 应该稳定在个位数到几十而不是被缓存击穿打出的流量淹没。如果 DB 频繁被打说明前面各层的命中率没做好需要回头检查缓存策略而不是扩容数据库。3. 本地缓存选型与配置实操Caffeine 核心参数精解3.1 为什么选 Caffeine 而不是 Guava Cache本地缓存的选型现在基本不用纠结首选 Caffeine。Caffeine 是 Guava 作者之一 Ben Manes 后续开源的进程内缓存库大量借鉴了 Guava Cache 的 API 设计同时内核更激进。它的优势主要体现在淘汰算法上Guava 默认使用 LRULeast Recently Used最近最久未使用而 Caffeine 默认使用近似 LFU 的 W-TinyLFU 算法能够更好地识别频发访问的热点 key避免偶发的一次性访问把热数据挤出去。Caffeine 还支持异步加载、主动刷新、命中率统计、淘汰通知等高级功能。API 友好度也够从 Guava 迁移成本很低很多依赖 Guava 的历史项目依然能平滑替换。实际的配置我建议以容量和过期策略为两个主轴而不是照抄网上模板。下面是我在项目里常用的一套配置CacheString, ProductBO productCache Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofMinutes(30)) .refreshAfterWrite(Duration.ofMinutes(5)) .recordStats() .build();几个参数展开说maximumSize控制本地缓存最大条目数。这个值必须根据 JVM 堆大小和单个缓存对象大小衡量。切忌设置过大否则缓存数据实际占用的内存可能远超预期导致 GC 压力剧增。expireAfterWrite写入后过期是一种绝对过期策略适合那些不能脏读很久的数据。refreshAfterWrite写入后刷新不是直接让缓存过期而是当缓存条目超过该时长后访问时触发异步刷新。刷新过程中旧值还能照样返回这就解决了“缓存过期瞬间所有请求一起回源”的击穿问题。recordStats开启后可通过 cache.stats() 获取命中率等信息多级缓存生命周期里命中率监控全靠它。3.2 用 refreshAfterWrite 解决“缓存全挤在同一秒过期”我在 1.1 提到的大面积穿透就是因为集中过期。本地缓存这一层也有同样的问题。比如 expireAfterWrite 统一设置为 30 分钟那么所有 key 会在各自的写入 30 分钟后的同一批时刻过期。如果这批 key 恰巧是热点那几毫秒内全部 miss形成本地缓存的“局部雪崩”。解决办法有两个层面。第一层让过期时间带上随机扰动值Duration.ofMinutes(30 ThreadLocalRandom.current().nextInt(10))第二层就是上面说的 refreshAfterWrite。Caffeine 在判断条目需要刷新时会尝试加锁并让一个线程去重新加载数据其他线程直接返回旧值所以不会出现同一时刻所有线程都穿透到下游的情况。这个机制非常实用但有一个前提LoadingCache 的 load 方法必须能稳定、快速地返回数据。如果 refresh 方法本身会去查很慢的数据库那异步刷新照样会拖慢接口。这里有一个很容易踩的坑expireAfterWrite 和 refreshAfterWrite 同时存在时两者的时间关系很关键。refreshAfterWrite 必须小于 expireAfterWrite否则某个条目到了刷新时间但还没到过期时间看起来和“只过期不刷新”没有区别。而在过期时间真正到达后Caffeine 会强制移除条目下一次访问走完整的 miss 回源流程。实际项目里我一般把 refresh 时间设为 expire 时间的六分之一到三分之一再结合随机扰动效果最好。3.3 本地缓存的容量评估按单个对象大小算而不是按条数算一个很容易被忽略的问题maximumSize 设置成 10000但不知道 10000 个对象实际占多少内存。产品对象如果是包含几十个字段、几层嵌套的 JSON单个对象可能 10KB 以上那么 10000 个就是 100MB。如果同时存在十几个这样的本地缓存实例堆内存直接膨胀到 GB 级。所以配置本地缓存前我会先做一次简单估算单条数据平均占用内存 × 最大条数 × 安全系数1.3 到 1.5≤ 分给缓存的堆内存预算。如果算下来超出预期就只能减小 maximumSize 或者对缓存对象做瘦身只保留接口最需要的字段。千万别忘记 JVM 还有其他对象、线程、堆外内存都在竞争给缓存留出过大的堆只会让应用整体不稳定。4. 多级缓存最难的部分数据一致性怎么保多级缓存的核心矛盾就是“缓存变多了数据更新的链路变长了”。之前只有 Redis 一层缓存时更新数据只需要同时更新 Redis 即可。现在有了 Nginx 缓存、本地 Caffeine 缓存、Redis 三层任何一层数据不一致都会引发线上问题。这里我不讲教科书里的理论组合直接讲实际可落地的方案和取舍。4.1 Cache Aside 模式读回源、写删除不管缓存有几层我建议数据更新统一用 Cache Aside 模式。核心思想是读请求先读缓存缓存 miss 再读数据库然后回填缓存写请求直接更新数据库再删除缓存相关 key。这里有一个经典问题为什么写的时候不是更新缓存而是删除缓存因为更新缓存要付出额外的操作成本而且容易出现并发写场景下旧值覆盖新值的问题。删除缓存后下一次读请求会自动 miss 并加载最新数据虽然多了一次回源开销但一致性保障比更新缓存更好。在多级缓存环境下删除缓存要删除哪几层以我常用的商品接口为例数据库更新完成后先删除 Redis 中的热点 key再删除本地 Caffeine 中的对应 key如果 Nginx 有缓存需要等待过期或者主动调用接口触发刷新但问题是本地缓存遍布在多个应用实例里不可能让每个写请求去遍历所有实例的本地缓存。这就需要下面两种机制。4.2 本地缓存失效广播用 Redis Pub/Sub 和 MQ 双通道本地缓存一致性本质上是一个“发布-订阅”问题。在分布式架构中任何一台应用实例执行了写操作或收到删除信号后需要通知所有实例把本地缓存的 key 删掉。我最常用的方式是 Redis Pub/Sub。在更新数据库之后发送一条消息到固定频道例如 cache:invalidation各个应用实例订阅该频道并删除本地 key。这比每个实例都去轮询数据库要高效得多。伪代码大概是这样// 发送失效消息 redisTemplate.convertAndSend(cache:invalidation, JSON.toJSONString( InvalidationMessage.builder() .cacheName(product) .key(String.valueOf(productId)) .build() )); // 订阅端 redisMessageListenerContainer.addMessageListener( (message, pattern) - { InvalidationMessage msg JSON.parseObject(message.getBody(), InvalidationMessage.class); localCache.invalidate(msg.getKey()); }, new ChannelTopic(cache:invalidation) );但 Redis Pub/Sub 有一个大问题它不是可靠消息队列消息会丢失。如果发布时正好有订阅方短暂断开或者 Redis 主从切换期间消息根本没发出去那这个 key 的本地缓存就只能等着自然过期。所以还要搭配一个兜底方案——让本地缓存的有效期尽量短比如 30 秒到 5 分钟这样即使失效通知丢了本地缓存最长只会造成几分钟的脏读。如果你追求更可靠可以把失效消息打到 RabbitMQ / Kafka / RocketMQ 中由各个实例消费这样消息不会丢。代价是链路多一层中间件架构更重。我的取舍原则是核心数据用 MQ 保证最终一致非核心数据用 Pub/Sub 配合短过期时间已经够用。4.3 数据库 Binlog 监听一种旁路数据更新方案在实践中还有一种很流行的模式就是用 Canal 监听 MySQL 的 Binlog把数据库的任何变更转化成消息再推进 Redis 缓存更新或者消除操作。为什么这么做因为某些场景下数据更新的入口藏在多个服务里应用层无法统一管控。例如订单系统订单状态可能在交易服务、支付回调、定时任务多处被修改如果每个修改点都手动触发缓存删除漏一处就是脏数据。用 Canal 监听订单表的 Binlog 后任何 update 都会产生一条变更消息统一由消费服务做缓存失效。这样大大减少了业务代码的侵入性但也引入了一套独立的同步基础设施。在多级缓存中Canal 同步的通常只是 Redis 层。至于本地缓存可以同时订阅 Canal 处理程序发出的消息因为它本质上也是走 MQ 或 Pub/Sub 的失效广播机制。整体链路就是MySQL Binlog - Canal - MQ - 缓存失效订阅器 - 本地缓存删除。需要注意Canal 方案会增加维护成本适合数据一致性要求较高、写入链路复杂的业务对于写少读多的场景不建议一上来就上这一套否则容易为了缓存把系统搞复杂。4.4 最终一致性 vs 强一致性多级缓存必须让步讲句实话多级缓存的引入就意味着数据一致性的标准要从强一致性降低到最终一致性。你不可能做到数据库一更新所有层的缓存立刻全部失效且绝对无延迟。即使是删除缓存的动作也有网络延迟和多实例时间差。所以设计多级缓存时一定要提前和产品确认好业务容忍度。常见的做法是把数据按“实时性敏感程度”分为三类强实时数据如秒杀库存、用户余额不放进本地缓存只走 Redis 且用极短过期时间或者干脆直接查库可接受秒级延迟的数据如商品详情非库存字段、配置类数据多层缓存 过期时间较短可接受分钟级延迟的数据如排行榜、文章阅读数多层缓存 较长的过期时间 异步刷新这样分类后每一层缓存放什么数据、过期策略用什么心里就有数了而不是所有数据一套逻辑混用。5. 穿透、击穿、雪崩多级缓存也防不住但必须面对的三种明细做缓存架构除了考虑“命中了怎么办”更要考虑“没命中会怎样”。缓存穿透、缓存击穿、缓存雪崩这三个问题在多级缓存体系下会被放大因为每一层 miss 都会向下层传递流量。我先说清楚三者的区别再讲在多级缓存里怎么分层应对。缓存穿透查询一个根本不存在的数据比如用随机 ID 请求商品详情Redis 和数据库都没有请求直接打到 DB。攻击者可以伪造大量不存在的 key 打垮数据库。缓存击穿某个热点 key 在 Redis 失效的瞬间大量并发请求同时回源 DB造成瞬时压力集中。缓存雪崩大量 key 在同一时间段过期或者 Redis 实例整体不可用海量请求直接打到 DB导致数据库宕机。5.1 穿透防御布隆过滤器 空值缓存穿透的根源是查询了“查无此物”的数据。最简单的办法是如果从 DB 查出来是空也把这个 key 放进 Redis 缓存value 写一个特殊空值过期时间设为 30 到 60 秒。这样后续相同 key 的请求在短时间内不会再次打到 DB。空值缓存的缺点是有大量不存在 key 时会占用缓存空间所以过期时间要短。更好的前置拦截是布隆过滤器Bloom Filter。把合法存在的 key 预置到一个大型 bit 数组里查询前先判断 key 是否存在不存在直接拒绝。布隆过滤器的特点可以非常肯定地说“某个 key 一定不存在”但只能说“某个 key 可能存在”。在缓存查询前加一道布隆过滤器可以挡掉绝大多数恶意穿透请求。在多级缓存框架下布隆过滤器应该放在哪个位置我建议放在 Redis 层之前。本地缓存 miss 后先过布隆过滤器如果判断 key 不存在直接返回空结果不再访问 Redis。这样能避免大量无用请求占用 Redis 连接。不过布隆过滤器有两个工程问题需要处理一是初始容量和误判率的权衡容量预估过小会导致误判率飙升二是数据删除时布隆过滤器不会删 key需要定期重建或者使用带删除能力的 Cuckoo Filter布谷过滤器。这块我不想展开太多但做之前一定要想清楚 key 集合的规模上限。5.2 击穿防御互斥锁和逻辑过期击穿本质上是一个热点 key 的并发回源问题。应对手段有两种第一种是互斥锁典型实现是 Redis SETNX。热点 key miss 后先尝试获取锁只有一个线程拿到锁回源数据库其他线程等待锁释放后直接读缓存。这种方式逻辑清晰但有一个问题是锁等待期间可能会造成线程阻塞。第二种是逻辑过期。不设置真正的物理过期时间而是把过期时间作为一个字段存在 value 里。查询时发现逻辑过期就返回旧值同时异步发起一个线程去更新缓存。这个方案和 Caffeine 的 refreshAfterWrite 异曲同工能够有效避免单点热点 key 失效瞬间的大流量穿透。多级缓存中这个策略可以在本地和 Redis 两层同时使用。Caffeine 已经内置了 refreshAfterWriteRedis 层的逻辑过期则可以在应用代码里实现。例如public ProductBO getProductWithLogicalExpire(Long productId) { String key product: productId; String cached redisTemplate.opsForValue().get(key); if (cached ! null) { ProductCacheDTO dto JSON.parseObject(cached, ProductCacheDTO.class); // 逻辑过期触发异步刷新 if (dto.getExpireTime() System.currentTimeMillis()) { asyncRefresh(key, productId); } return dto.getProduct(); } // 真正 miss需要回源 return loadFromDB(key, productId); }需要注意异步刷新要做幂等控制否则多个请求同时触发刷新数据库压力又起来了。通常可以用一个 per-key 的锁或者 Redisson 的 tryLock 来控制同一时刻只有一个刷新线程。5.3 雪崩防御过期时间随机化 熔断降级雪崩和击穿的区别在于影响范围。击穿是单个 key雪崩是大量 key。针对雪崩的常规手段有三板斧过期时间加随机值、集群分片避免单点故障、开启限流熔断兜底。过期时间随机化是在设置 Redis 过期时间时让基础 TTL 加上随机偏移。比如预期过期时间 30 分钟实际设置为 1800 秒加上 0 到 300 秒随机数。这样同一批 key 不会在同一瞬间失效。这个操作成本极低但能被很多团队忽略。如果 Redis 整体不可用多级缓存架构反而能体现出优势因为本地缓存和 Nginx 缓存不依赖 Redis仍然可以继续提供一定时间的服务。但本地缓存总会有过期和淘汰所以必须配合熔断降级逻辑当 Redis 不可用时不再尝试访问 Redis而是直接放行到本地缓存或 DB并对 DB 访问做限流避免打爆数据库。我之前在项目中加过一个很简单的降级开关用本地一个 AtomicBoolean 记录 Redis 健康状态健康检查失败超过阈值则熔断 Redis 访问 30 秒期间查询只走本地缓存和 DB。这个开关代码量很小但在极端场景下真的能救命。6. 热点 key 识别与动态多级缓存命中率翻倍的关键多级缓存不是配置好了就完事还要解决一个问题哪些 key 值得放在本地缓存哪些 key 应该降级因为本地缓存容量有限不可能把所有数据都塞进 JVM。如果塞了一堆冷数据不仅命中率低还挤占了热数据的空间。所以热点识别是动态优化系统的基础。6.1 三种热点发现方式第一种是日志采集。在应用层对每次缓存查询做埋点记录 key 的访问频率然后异步聚合统计把 TOP N 的 key 动态推送到本地缓存。这种方式最直接但需要自己设计采集和推送链路。第二种是 Redis 侧统计。Redis 4.0 之后提供了hotkey参数可以配合redis-cli --hotkeys提取热点 key。此外Redis 6.0 之后支持客户端缓存Client Side Caching本质上就是服务端通知客户端哪些 key 失效这算是 Redis 官方对多级缓存的一种支持。但这个能力更多的是针对单机场景集群模式下需要额外处理转向逻辑。第三种是代理层统计。如果 Redis 前面有 Codis、Proxy 或自研网关可以在代理层统计 key 访问频次再同步给应用层。这套方案能够无侵入地拿到全局视角的热点分布是大型团队比较喜欢做的方向。对于大多数中小团队我建议先做第一种用本地缓存组件自带的 stats 统计如 Caffeine 的 recordStats就能看到当前命中率。如果命中率长期偏低就调整 key 的选择策略而不是盲目上更复杂的监控系统。6.2 动态提升和降级把热数据留在最近的一层识别出热点后还需要一套动态策略。比如某个商品 ID 在 5 分钟内访问量突增系统应自动把它加入本地缓存白名单并延长本地过期时间当热度下降后又自动移出白名单释放 JVM 空间。这个机制可以用定时任务实现每隔 10 到 30 秒从日志或 Redis 访问计数中统计各 key 的滑动窗口访问量生成热 key 集合再通过配置中心Nacos/Apollo推送到各应用实例。各应用实例收到热 key 列表后动态调整本地缓存策略。冷 key 则逐渐从本地缓存淘汰。很多人觉得这个太复杂不知道从哪里入手。其实可以分两步来落地第一步先把所有核心接口的 key 都放本地缓存配合短 TTL 和随机过期时间观察命中率和 GC第二步再引入热点 key 动态管理把容量控制在合理范围内。两步之间通常间隔一两个迭代版本不宜一上来就追求完美。6.3 命中率监控这是多级缓存是否有效的唯一标准最后一定要强调监控。多级缓存不是上线就完事你起码要能看到每一层的命中率。Caffeine 可以输出内部统计Caffeine.newBuilder().recordStats().build(...).stats();Redis 可以通过 INFO stats 查看 keyspace_hits 和 keyspace_misses 计算命中率。Nginx 可以通过 log_format 记录 cache_status 字段然后按状态聚合统计 HIT 占比。然后再统计数据库 QPS 的变化几个数据联动分析就能快速定位问题。我自己一般设置两个报警阈值Redis 命中率低于 85% 时需要排查是否存在缓存穿透或过期策略配置问题数据库 QPS 明显升高时直接检查 Redis 和大 key 情况本地缓存命中率低于 60% 时就要考虑是不是热 key 没识别出来或容量太小有了监控和报警多级缓存系统才真正具备可持续迭代的基础否则它就是一个“上线时很好用、运行三个月后没人敢动”的黑盒。7. 实测效果与几个必须带走的心得7.1 一组直观的压测对比最后分享一组我在测试环境做的简单对比数据。同一台 4 核 8G 机器同一个商品详情接口QPS 压测大约在 2000 并发只走 Redis 缓存平均 RT 约 2.5msRedis CPU 占用约 65%客户端连接数打满本地缓存 Redis本地命中率约 70%平均 RT 约 1.1msRedis CPU 占用降到 15%连接数大幅下降本地缓存 Redis Nginx 缓存公共接口部分 Nginx 命中后 RT 降到 0.3msRedis CPU 占用进一步降低这些数字不代表绝对标准但它能直观说明一个问题多级缓存不是为了让速度从 99 变成 100而是为了把下游压力降低一个数量级让系统具备更强的抗冲击能力。尤其是 Redis 连接池和线程池的占用在出现流量尖峰时差距是致命的。我试过几次之后发现多级缓存里真正难的不是写代码而是确定哪些数据能接受脏读、哪些数据必须保证实时。如果你是一个刚开始接触多级缓存的读者我的建议是这样的先从“本地缓存 Redis”两层开始只把读量大、允许短期脏读的公开数据放本地缓存把过期时间随机化加上命中率监控稳定后再考虑 Nginx 层或者 Canal 同步。千万别一上来就追求六层架构那只会让问题排查变得异常痛苦而收益很可能早就有缓存兜底了。7.2 几条踩过坑之后才明白的心得本地缓存的过期时间一定不要统一必须加随机扰动值否则到点就是一波穿透。本地缓存失效广播用 Redis Pub/Sub 时消息可能丢失一定要搭配短过期时间兜底重要数据用 MQ 更稳。布隆过滤器能防穿透但别指望它防一切空值缓存是更简单的第一道防线。热 key 识别越早做越好否则本地缓存容量再大也会被冷数据占满命中率上不去。多级缓存不是一劳永逸每次大促前要重新评估热点数据集合必要时把过期时间、白名单动态调一轮。7.3 如果你想把多级缓存继续推得更远多级缓存这套思路还可以和更多技术组合起来。比如本地缓存用 JDK 的 ConcurrentHashMap 做极简版也行但不要在小项目里过度设计Redis 6.0 的客户端缓存Client Side Caching也能提供一定程度的服务端辅助能力值得研究Nginx 层如果业务允许还可以搭配 OpenResty 的 shared dict 做更灵活的缓存控制。我自己目前的线上架构是 Nginx 缓存 Caffeine 本地缓存 Redis 三套共存数据库 QPS 长期压在一个很低的水平大促期间也只需要调整缓存策略而不必频繁扩容。多级缓存给我最大的感受是缓存不是越多越好而是每一层都要有清晰的职责边界。想清楚什么数据放哪一层比堆多少层缓存都重要。