系统一到高峰就卡？本地缓存、Redis、多级缓存三种方案对比

企业系统变慢，十有八九不是代码问题，而是"同一个数据被反复现算"：首页报表每次打开都实时聚合全表、商品列表每次刷新都连查五张表、权限树每个请求都重新递归计算。缓存就是为此而生——把算过的结果存起来，下次直接用。主流的缓存方案有三种形态：应用内本地缓存、独立缓存服务（Redis）、以及两者结合的多级缓存。这篇文章把三种方案的成本和适用边界讲清楚。

一、三种方案的真实面目

应用内本地缓存（进程内缓存）。 数据缓存在应用进程自己的内存里，读取零网络开销，速度最快。优点是零依赖、实现最简单；短板是多实例部署时各实例缓存不一致（A 实例更新了缓存，B 实例还是旧数据）、应用重启缓存全丢、缓存量受单机内存限制。适合"单机部署、变更不频繁"的基础数据。

独立缓存服务（Redis 为代表）。 独立的缓存中间件，所有实例共享同一份缓存。优点是天然解决多实例一致性、支持丰富的数据结构（排行榜、计数器、分布式锁都能做）、可持久化可集群；缺点是多了一个要运维的组件，网络往返有开销（虽然通常不到 1 毫秒），且引入了新的一致性问题：数据库和缓存谁先更新、缓存过期怎么设计。

多级缓存（本地+Redis 组合）。 热数据在本地缓存放一份（毫秒级读取），Redis 放共享的一份，本地缓存通过 Redis 的失效通知保持同步。优点是把性能做到极致，扛得住大促级别的并发；代价是复杂度翻倍——失效策略、穿透、雪崩、一致性，每个问题都要专门设计。日活几百的企业内部系统，用不上这套。

二、按场景对号入座

变化慢的基础数据（组织架构、字典、权限规则）： 本地缓存 + 定时刷新（比如 5 分钟）最划算。这类数据一天变不了几次，5 分钟的延迟业务完全无感，换来的是零运维成本。

多实例共享的会话与热点数据（登录态、库存余量、排行榜）： Redis 是标准答案。某电商客户的商品详情页接入 Redis 后，页面响应从平均 2.3 秒降到 300 毫秒，数据库 QPS 下降 80%——大促没再扩容就扛住了。

极端高并发（秒杀、实时大屏）： 才需要多级缓存。内部管理系统别碰，复杂度带来的故障比性能收益多得多。

三、无论选哪种，都要处理好的三件事

缓存穿透与雪崩。 查询一个不存在的数据，缓存和数据库都没有，请求全打到数据库（穿透）；大量缓存同一时间过期，请求洪峰涌向数据库（雪崩）。对策：空值也缓存、过期时间加随机抖动、热点数据提前预热。这三件套不写进设计，缓存上线就是埋雷。

数据一致性策略要明确。 "先更新数据库再删缓存"是最通用的做法，但要接受短暂的不一致窗口。对一致性要求极高的数据（如库存、余额），要么不用缓存，要么用带锁的读写方案——想"既要快又要绝对一致"，是缓存设计里最常见的妄念。

缓存命中率要监控。 命中率低于 80% 说明缓存设计有问题（键设计不合理或过期太短），命中率接近 100% 要警惕数据是不是不更新了。缓存不是设完就完事的基础设施，是要持续看数据的。

写在最后

缓存的本质，是用"短暂的不新鲜"换"数量级的速度"。本地缓存胜在极简、Redis 胜在共享、多级缓存胜在极致性能——按系统规模选对形态，别给内部系统上大促方案。真正的分水岭不在选型，而在穿透雪崩的防护、一致性策略的取舍、命中率的持续监控。这些做扎实了，缓存才是加速器，否则是定时炸弹。