做过几年后端跟缓存打了太多照面。有一次线上事故印象特别深一个读接口平时响应 50ms因为并发上来团队决定加一层 Redis 缓存。结果加完之后接口响应直接飙到 800ms数据库倒是没事了Redis 的连接数和 CPU 先被打满了。后来排查发现缓存 key 大量集中在同一秒过期过期之后所有请求同时穿透到数据库数据库扛住了但 Redis 因为大量重建缓存的写操作和网络连接被打崩了。那一次之后我对缓存设计的看法就变了缓存从来不是“加了就一定快”的东西用好了是锦上添花用不好就是给你系统落井下石的那块石头。这篇文章把我在缓存设计上踩过的坑、排查过的故障、最后沉淀下来的方案一起梳理出来。不管是正准备给系统引入缓存还是已经在用缓存但时不时出点诡异问题这篇内容应该都能帮上忙。我会从缓存失效的三大经典故障、缓存与数据库的一致性、key 设计和过期时间设计这些最容易出事的地方逐个拆开讲每个问题都会聊到底层原因、为什么是这个方案、实操的时候怎么落地以及有哪些坑是常规文档里不会告诉你的。1. 缓存设计的本质为什么它既是加速器又是风险源1.1 缓存提速的本质与代价缓存能提速底层逻辑无非两件事一是把数据放到离计算更近的地方减少网络开销二是把重复计算的结果存下来降低后端存储的负载。就像你家里常备冰箱不用每次吃饭都去菜市场但冰箱本身要耗电、要占地方、里面的菜会过期你还要操心什么时候该补货。缓存也一样多了一层副本就多了一份一致性问题和容量管理的成本。很多团队加缓存的时候只看到了“快”这一个收益没有认真评估过这层副本带来的代价。如果业务数据量很小单次数据库查询本身就只要几毫秒QPS 也不高这个时候加缓存反而可能是负优化。因为每次写入都要额外维护缓存读的时候还要先查缓存再回源数据库多一次 Redis 网络往返本身就增加了延迟。我在一个内部管理系统里见过这种案例一个配置表总共几千行本来数据库查询 3ms 就返回了加完缓存之后平均响应反而变成了 6ms因为每次请求多了一次 Redis 的访问命中率还不到 40%纯粹是花钱买罪受。关键在于缓存方案选型和业务特征必须匹配。适合缓存的是两类场景一类是典型的热点读场景比如商品详情、用户信息、配置数据读的频率远高于写另一类是计算成本高的场景比如复杂的报表聚合查询每次实时算要几秒钟缓存计算结果能带来数量级的提升。不适合缓存的场景也很明确写多读少的数据、实时性要求极高且不能接受任何延迟的数据、以及本身查询极快且量小的数据。1.2 缓存设计的三维取舍时效、一致、成本我习惯把缓存设计拆成三个维度来看时效性、一致性、成本。时效性说的是数据多久可以被更新到缓存中业务能不能接受这个延迟窗口一致性说的是缓存中的脏数据是否允许存在以及允许存在多久成本说的是内存资源、组件维护、代码复杂度这些投入。这三个维度永远是在互相打架的。想要强一致就会牺牲时效性优势可能需要同步更新甚至事务性操作来保证想要极致的读性能就得接受缓存和数据库之间存在一个短暂的不一致窗口想要降低成本少维护组件就得接受功能上的阉割。没有一种缓存方案是三个维度都拉满的做设计的过程本质上就是根据业务做取舍。举个典型的例子一个电商的库存系统缓存中的库存数如果和数据库不一致哪怕偏差几分钟都可能导致超卖这种场景时效性和一致性要求都很高就不能只依赖简单缓存过期来兜底需要引入更严格的对账或者串行化更新机制。但同一家电商的商品标题、描述这类数据晚几分钟更新完全无感这类数据就非常适合纯缓存过期策略给一个相对宽松的 TTL 就行。实际操作中我建议在做缓存设计前先回答三个问题业务可以接受多久的数据延迟缓存失效瞬间的回源流量是否在数据库承受范围内内存成本和维护成本是否可控这三个问题没有明确答案之前不要急着动手写代码。2. 三大经典故障缓存穿透、缓存击穿、缓存雪崩的成因与防线2.1 缓存穿透查询不存在的数据会绕过所有防线缓存穿透这个概念很多人容易跟缓存击穿混在一起但两者的成因和处理方式完全不同。穿透是指查询一个数据库和缓存中都不存在的数据比如用了一个不存在的用户 id、非法的商品编号。因为缓存里没有这个 key每次请求都会直接打到数据库数据库也查不到也就不会回写缓存导致这个“查什么都是空”的请求每次都穿透缓存层直达数据库。我见过最典型的穿透事故是有人写脚本遍历 id里面掺杂了大量不存在的 id直接把数据库的连接池打满了。数据库倒是没有崩但所有正常业务请求也跟着被拖慢因为连接都让垃圾请求占用了。这个案例说明穿透问题的真实危害不只是数据库压力而是它可能变相影响所有正常流量。防穿透有几个层次的方案每层解决不同的问题。最基础的是参数校验不合法、不存在的 id 直接拦截不落到存储层。第二层是布隆过滤器把所有可能存在的数据 id 加载到布隆过滤器中查询前先判断 id 是否存在不存在就直接返回。布隆过滤器之所以常用是因为它用极小的内存代价换来了“一定不存在的肯定不会放过”的判断能力它允许误判存在但不允许漏判不存在。虽然 Set 或者哈希表也能存所有 id但数据量大时内存占用太高布隆过滤器几百 MB 就能支撑上亿 id 的判断。第三层是空值缓存也就是当数据库查询结果为空时也把这个空结果写入缓存并且设置一个比较短的过期时间比如 60 秒。这样下一次同样的非法请求就会被缓存挡住不会继续穿透到数据库。空值缓存的问题是第一次请求还是要穿透到数据库所以它适合防御重复性的穿透请求。我在实践中的习惯是三层全上参数校验挡住明显非法的请求布隆过滤器挡住不存在的 id空值缓存兜住漏网之鱼。提示布隆过滤器有误判率它会把一些不存在的数据判断为可能存在。所以布隆过滤器不能用来做精确判断只能用来排除“肯定不存在”的情况。误判率可以通过参数控制一般控制在 1% 以下但内存和 hash 次数也要跟着调整。2.2 缓存击穿热点 key 失效瞬间的并发风暴击穿和穿透最大区别在于击穿针对的是单个热点 key而且这个 key 在缓存中本来是有值的只是恰好到了过期时间同时大量并发请求闯了进来。因为在缓存失效的那一瞬间所有请求都发现缓存里没有数据于是同时回源数据库查询同一个 key数据库瞬间被打出高峰。打个比方就像一个热门店铺在中午突然关门休息十分钟所有等餐的人都涌向后厨窗口。击穿的核心危险在于单点热点比如微博热搜、爆款商品的详情页、某个数据大屏的指标聚合。正常流量下缓存扛住了 99% 的请求但只要这个 key 一过期回源流量会在毫秒级翻几十倍。如果数据库连接池不够大这一波就能直接拖垮整个库。解决击穿的主流方案是互斥锁重建和逻辑过期。互斥锁的思路是当缓存失效时同一时刻只允许一个请求去数据库加载数据并重建缓存其他请求先等待或者直接返回旧值。具体实现上可以有多种做法最简单的是用 Redis 的 SETNX 命令抢锁抢到锁的请求去查库写缓存没抢到锁的请求 sleep 几十毫秒后重新查缓存。这个方案的优点是实现简单能真正控制住回源并发缺点是会导致一部分请求在锁等待期间延迟上升。逻辑过期则换了一个思路不像传统 TTL 那样让 key 物理消失而是在 value 里额外存一个逻辑过期时间。每次读数据时发现逻辑时间已经过期不直接删除 key而是返回当前可能稍微过期的数据同时异步发起一个后台线程去数据库加载最新数据并更新缓存。这个方案的优点是对客户端响应几乎无感知不会出现请求等待缺点是实现复杂度高而且会短暂地向用户返回过期数据。我个人的建议是如果业务能容忍极短暂的旧数据逻辑过期是体验最好的方案如果业务要求严格互斥锁方案更稳妥。2.3 缓存雪崩大面积 key 同时失效的连锁反应雪崩的杀伤力比击穿大一个量级。击穿是单个 key 失效雪崩是大面积 key 在同一时间段失效。最常见的原因是缓存设置了统一的过期时间。比如把一批热点数据的 TTL 都设成了 30 分钟那么这 30 分钟一到所有 key 会同时过期所有请求同时穿透到数据库。数据库连接池、CPU、磁盘 IO 在瞬间被打满即使缓存服务本身还活着整个系统也会因为数据库过载而雪崩。还有一个经常被忽略的雪崩场景Redis 本身重启了。如果 Redis 宕机或者重启所有 key 全部丢失重启后所有请求都会直连数据库这个回源量比正常流量大 N 倍稍大一点的系统都扛不住。Redis 持久化配置、哨兵主从切换期间的缓存不可用都可能成为雪崩的导火索。防雪崩的核心思路是错峰和降级。错峰最简单有效的手段是过期时间加随机抖动比如基础 TTL 是 30 分钟再给每个 key 加一个 0 到 300 秒的随机值让过期时间分布在 30 分钟到 35 分钟之间。这样任何一个时刻过期的 key 数量都会少很多回源量被分摊到更长的时间轴上。实际项目中我用得比较多的公式是TTL 基础值 random(0, 基础值 * 0.2)既保证了合理的缓存时长又分散了过期压力。多级缓存也是防雪崩的常用手段。在 Redis 之上再加一层本地缓存比如 Caffeine、Guava Cache热点请求优先走本地缓存本地没有再去 RedisRedis 没有再回源数据库。本地缓存的容量不用很大但能挡住相当大比例的重复请求相当于给数据库加了一个额外的缓冲垫。这套方案在 Java 生态里很成熟Caffeine 的读写性能很好内存控制也比 Guava 更精细。提示Redis 重启导致的雪崩往往比 TTL 到期导致的雪崩更严重因为所有 key 同时没了。除了开启持久化之外更稳妥的做法是给缓存服务配置好监控告警一旦 Redis 不可用业务侧立刻切到数据库直读的降级模式宁可慢一点也不能被打挂。3. 缓存与数据库的一致性最硬的一块骨头3.1 不一致是怎么产生的缓存和数据库是两套独立的存储系统任何一套系统都无法保证一次跨存储的事务操作。你说“先更新数据库再更新缓存”如果在更新缓存时网络抖动或写入失败数据库是新值缓存是旧值两边就不一致了。你说“先更新缓存再更新数据库”更是反过来了缓存变新了数据库还是旧的下次更新数据库成功还好失败的话缓存就一直错下去。所以缓存一致性问题的本质是数据库写入和缓存更新之间天然存在时间窗口和失败可能而我们缺少一个原子机制来消除这个窗口。网上有些文章把一致性描述得很玄乎但实际拆开也就两个点先操作谁失败怎么办以及并发读写交错时会出现什么结果。3.2 为什么“先更新数据库再删除缓存”是现实中最优解业界讨论缓存更新策略时主流方案基本绕不开 Cache Aside 模式这也是我实际工作中用得最多的模式。Cache Aside 的原则很清晰读的时候先读缓存读不到就读数据库然后回写缓存写的时候先写数据库然后删除缓存。这套模式被广泛使用的原因不只是简单而是它在大多数业务场景下把不一致窗口压缩到了最小。你可能会问为什么写的时候不直接更新缓存而要删除缓存因为更新缓存比删除缓存的成本高得多而且更容易出错。更新缓存需要知道新数据长什么样如果涉及联合查询或者复杂的计算逻辑更新一次缓存可能导致额外的查询开销和序列化成本而删除缓存只是删一个 key简单、快、不容易出错。缓存里没有这个 key 时下一次读请求自然会去数据库加载新数据相当于缓存自愈了。那先更新数据库再删除缓存和先删除缓存再更新数据库选哪个我建议在绝大多数场景下选前者。先删缓存再更新数据库有个经典并发问题线程 A 删除了缓存还没更新数据库线程 B 发起了读请求缓存没命中于是从数据库查到了旧值并写回了缓存等线程 A 更新完数据库后缓存里的旧值就永远留在那里了。先更新数据库再删除缓存虽然也存在一个读线程在更新间隙读到旧值并写回缓存的短窗口但这个窗口要小得多因为删除缓存发生在数据库更新完成之后旧的缓存大概率已经被清掉了就算读线程在删除前那一刻读到了旧缓存它也不会重新写回一个旧值因为缓存里已经有值了Cache Aside 在读缓存命中时是不会回写数据库的。3.3 延迟双删和 binlog 异步删除先更新数据库再删除缓存的方案也不是绝对安全。极端情况下线程 A 更新数据库后删除缓存但在它删除之前线程 B 读到了数据库的旧值并写回了缓存发生在 A 的更新事务提交前等 A 删完缓存后B 写回去的旧值又留在缓存里了。为了处理这种极端场景出现了延迟双删的思路更新数据库后第一次删除缓存然后等待一小段时间再删除一次缓存。等待时间的目的是让并发读请求把旧值写回缓存的动作完成然后第二次删除把它清掉。延迟双删的时间怎么定并没有一个精确公式基本思路是大于“读请求从数据库读到数据再写回缓存的平均耗时”。实际项目中我会看业务读链路的耗时通常取 500ms 到 1s 之间设置太短没效果设置太长会影响写的感知延迟。延迟双删虽然能解决绝大多数不一致场景但它本质上仍是一个偏经验性的方案参数需要根据实际业务调整而且双删间隔内确实存在短暂的不一致窗口。如果想要更强的最终一致性保障业界比较成熟的方案是借助 binlog 订阅来实现异步删除。核心思路是数据库写入完成后业务代码不直接删缓存而是由 Canal 这类组件订阅 MySQL 的 binlog解析出变更事件再异步删除对应的缓存 key。这样做的好处是缓存删除完全由数据库变更驱动不依赖业务代码的执行结果即使应用进程在更新数据库后立刻宕机binlog 事件依然会被消费缓存依然会被删除从机制上根治了“数据库更新成功但缓存删除失败”的隐患。我个人的经验是小团队小系统没必要一上来就上 binlog 方案维护 Canal 本身也有成本。先做好 Cache Aside 延迟双删就够用了等系统真的遇到一致性事故、或者业务提出更严格的最终一致要求再平滑迁移到 binlog 方案。设计上没有银弹只有当前阶段最合适的取舍。4. 缓存 Key 设计与过期时间细节里的魔鬼4.1 Key 命名与粒度的常见问题很多上线后才暴露的问题根源其实是设计阶段没想清楚 key 怎么建。一个高频问题是不加业务前缀。比如直接拿用户 id 作为 key那么这个系统里所有数据都共用一套 key 空间如果有人建了另一个业务也用用户 id直接就会冲突。正确做法是统一命名规范业务模块:实体类型:唯一标识比如 user:profile:10001、product:detail:SKU123。前缀的作用不只是避免冲突更大的价值是你在排查问题时能通过前缀快速筛出相关 key比如用 SCAN 按前缀扫描来分析热点。另一个问题是 key 的粒度选择不合理。缓存粒度太粗比如把整张商品表塞进一个 key任何一个商品变更都要重建整个缓存重建成本高且并发更新容易覆盖粒度太细比如每个商品属性单独一个 key一个商品详情页要读取十几个 key网络往返开销全回来了。我的判断标准是一个业务读场景中一次用户请求需要的数据如果天然属于同一次查询就把它们放在同一个 key 下如果不同的用户场景需要的数据范围差异很大就拆开。商品详情页可能包括标题、价格、库存、图片但用户打开详情页时这些数据是同时需要的那一个商品一个 key 存 JSON 整体结构就是合理的。还有一个经常被忽略的是 key 的可读性。生产环境排查问题时看到一个大写的 hex 字符串 key 完全没法判断它对应什么业务看到 user:profile:10001 一眼就知道是什么数据。我之前因为偷懒用 uuid 当 key 后缀线上排查热点问题的时候浪费了整整一个下午从那以后我对 key 的可读性要求就变得很高这也算是一笔学费换来的教训。4.2 过期时间的固定值陷阱固定过期时间是最常见的雪崩催化剂这个前面已经说过。但除了雪崩过期时间长短本身还牵涉一个命中率和数据新鲜度的平衡。TTL 太短缓存频繁失效命中率低缓存的加速效果有限TTL 太长数据长时间不更新业务看到的都是旧数据。判断一个 TTL 设定是否合理最直接的方法是看命中率监控。如果命中率长期低于 60%要么这个缓存场景本身不适合缓存要么 TTL 设置偏短。有些团队的 TTL 完全没有业务依据拍脑袋定一个 10 分钟就上去了。我建议每个缓存 key 的 TTL 都要对应一个业务容忍度。比如用户昵称这类几乎不敏感的数据可以设 24 小时库存数量这类时效性敏感的数据TTL 设 30 秒或者干脆不设 TTL走实时更新或逻辑过期。设置 TTL 之前多问一句如果这个数据晚更新一分钟用户的体验会变差多少这个问题能帮你排出优先级。4.3 大 key 与热 key 的处理大 key 和热 key 是两个不同的问题但经常一起出现。大 key 是指单个 key 的 value 特别大比如几 MB 的二进制数据。大 key 的问题是操作成本高、阻塞风险大Redis 是单线程处理命令一个几 MB 的 value GET 下来网络传输和反序列化都会拖慢其他命令执行。热 key 是指某个 key 的访问 QPS 特别高比如一个爆款商品的详情被几十万用户同时看。处理大 key 的思路是拆分。把一个大的 JSON 按业务维度拆成多个小 key或者把列表数据分页存入多个 key。比如一个用户关注列表有 5000 个 id存成一个 key 可能 200KB读一次就很重拆成多个分页 key 每次只读一页单个请求的负载就降下来了。处理热 key 的思路是打散和本地兜底。打散是指给同一个热 key 加多个副本比如 product:detail:SKU123 复制成 product:detail:SKU123#0 到 product:detail:SKU123#9读请求随机访问其中一个副本把压力分摊到多个 key 上本地兜底是指把热点数据放到应用本地缓存里不每次访问 Redis。实际项目中我先看监控确认哪些 key 是真正的热 key再针对性地做处理不求全只求把 Top 10 的热 key 管好。提示排查大 key 和热 key 可以用 Redis 的redis-cli --bigkeys命令扫描也可以监控慢日志来定位异常命令。生产环境执行大 key 扫描要用 SCAN 而不是 KEYS前者是游标方式不会阻塞 Redis。5. 内存容量与淘汰策略缓存服务不被拖垮的底线5.1 内存上限必须设置不少团队部署 Redis 的时候没有设置 maxmemory结果 Redis 启动后随着缓存不断写入内存悄悄占满整台机器最终触发系统 OOM killer 把 Redis 进程杀掉。Redis 本身跑得好好的却被操作系统强制杀死这个事故原因我见过至少三次。正确做法是部署时就必须设置 maxmemory而且要根据业务预估容量加 30% 到 50% 的余量。maxmemory 不设置意味着 Redis 可以无限吃内存设置了以后 Redis 才会触发淘汰策略在内存满时有条不紊地把不重要的 key 清理出去。如果内存使用已经触顶、淘汰策略又不是合理的那么 Redis 会频繁执行淘汰操作CPU 持续升高读写延迟明显变大但至少服务不会直接死掉。5.2 淘汰策略选型不能拍脑袋Redis 的淘汰策略必须想清楚。很多团队用默认的 noeviction内存满了之后写操作直接报错这等于把内存打爆的问题转成了写入失败问题对业务的影响可能更大。说实话noeviction 在大多数缓存场景下都是错误选择。日常缓存场景我优先推荐 allkeys-lru不区分 key 是否设置了过期时间统一按 LRU 算法淘汰最久没使用的 key。这套策略适合“缓存里的数据整体上都是可丢弃的”场景也就是缓存命中与否不影响数据正确性只是影响性能。如果业务数据里有部分数据是必须常驻缓存的不能用 allkeys-lru那就用 volatile-lru只淘汰设置了过期时间的 key 中最近最少使用的部分但这样要求所有可淘汰 key 都必须显式设置 TTL。LFU 比 LRU 更激进适合缓存访问频率极度不均的场景。LRU 只记录最后访问时间一个 key 被访问一万次和一万年没访问、但恰好最近被碰过一次LRU 会把这个 key 当成热数据LFU 记录了访问频率能更好地保留真正高频访问的 key。LFU 的问题是它比较难调参而且对访问模式突变不敏感。我自己的经验是除非监控数据显示个别 key 的访问频率极度集中否则 LRU 就够用LFU 不是必需品用不好反而会把一些短期热点错误地保留在缓存里。6. 监控指标与缓存健康看板出了问题不再抓瞎6.1 核心指标一命中率、延迟与驱逐量没有监控的缓存系统出了问题基本靠猜。根据我个人排查缓存事故的经验下面这四个指标如果都有监控90% 的问题可以快速定位。命中率是最直观的缓存健康指标。命中率低说明缓存没起到应有的加速效果需要检查 key 设计、TTL 设置或者业务访问模式命中率低于 40% 时缓存基本是负资产建议直接考虑去掉缓存。计算命中率的公式是 gets 命中的次数除以总 gets 次数Redis 的 INFO 命令能直接看到 Redis 实例级别的命中率。延迟是另一个必须盯的指标。Redis 的平均命令延迟如果超过 10ms大概率有问题。要注意区分是网络延迟、Redis 自身处理延迟还是客户端阻塞可以用 INFO commandstats 或 SLOWLOG 来看具体命令耗时slowlog 设置成每命令超过 10ms 就记录。驱逐量表示的是内存满后有多少 key 被淘汰驱逐量突然大幅度上升说明内存不够了需要扩容或者优化 key 存储。6.2 核心指标二内存与热点 key内存使用率不用多说它决定是否触发淘汰。热点 key 的监控比较隐蔽很多事故排查起来困难是因为不知道哪个 key 是热点。Redis 4.0 以上可以用redis-cli --hotkeys配合 maxmemory-policy 为 LFU 或 LRU 时查看热点 key更通用的是在代码里做读请求的埋点统计记录 key 的访问次数输出到日志或监控系统里。我在项目中会预先对一些核心业务 key 做访问计数比如每 10 秒汇总一次访问次数超过阈值就告警。提前知道哪些 key 是热点比出事之后用客户端从一堆 key 里大海捞针要高效得多。把以上四类指标拼起来就能组成一块缓存健康看板。看板的意义不只是出问题时用更重要的是平时观察趋势。内存使用量的周环比变化、命中率的日均走势、驱逐量的时间分布这些趋势能提前帮你发现容量瓶颈和访问模式变化在事故到来前做好扩容和调参。7. 常见问题速查现象、原因与排查方向现象可能原因排查方向响应时间突然飙升数据库连接被打满缓存穿透或缓存雪崩看 Redis 命中率、数据库慢查询数量、key 过期分布Redis CPU 高但数据库压力不大大 key 频繁读写或热 key 集中查看大 key 和慢日志定位具体 key同一时刻大量缓存同时失效TTL 固定或批量 key 同时初始化检查 key 的 TTL 设置是否需要加随机抖动读到的数据总是旧值缓存更新失败或 TTL 过长核对更新链路是否删缓存失败TTL 是否符合业务容忍度缓存删除后数据还是旧的并发读把旧值写回缓存评估是否需要延迟双删或 binlog 异步删除内存使用持续增长驱逐量大缓存过期时间过长或 key 数量增长快检查是否有不设 TTL 的 key是否需要对 key 做容量规划Redis 重启后数据库被打挂没有持久化或没有降级方案开启 RDB/AOF准备缓存不可用时的降级策略这张表里的每一行我在实际项目中都踩到过。其中有件事想特别提醒遇到缓存问题先看监控数据别急着改代码。很多人排查问题的第一步是打开代码反复看逻辑但缓存相关的问题绝大多数是运行时动态问题代码静态逻辑往往看不出毛病。先拉命中率、慢查询、驱逐量、key 过期分布这些数据很多问题其实一眼就能定位。8. 最后再分享几点经验做缓存设计这些年我最大的感受是缓存方案没有绝对最优只有当前业务阶段下的最优。一个千万级日活的系统和一个刚上线的内部系统对缓存的需求和容错能力完全不同。小规模系统用最简单的 Cache Aside 加固定 TTL 就能跑得很好没必要一上来就上一堆组件和策略过度的架构设计和没有架构一样危险。我之前踩过的最深的坑基本都是同一个套路业务初期觉得缓存反正就是加一层没有认真想清楚 key 的细化、TTL 的分布、内存上限和淘汰策略等流量涨上来之后问题集中爆发。反而是那些愿意在设计阶段花两三个小时把 TTL 分布、淘汰策略、命名规范、监控告警都定下来的团队后期很少在缓存上翻车。如果你现在正准备引入缓存我建议从最小可用方案开始设置 maxmemory、选择淘汰策略、统一 key 命名、TLL 加随机抖动、至少把命中率和驱逐量监控起来。这五件事做完已经能躲开缓存设计里 80% 的坑。剩下的问题等系统规模真到了那个程度再针对性地优化也不迟。