搞过几年分布式系统的人几乎都跟Memcached打过交道。这玩意儿快是真快但坑也是真坑。尤其是在缓存过期这块很多团队都是在线上出了事故、数据库被压垮了才回头去研究那几行expire代码。说实话Memcached本身的过期机制并不复杂真正的麻烦在于”过期“这个动作会通过高并发访问被无限放大演变成缓存穿透、缓存击穿、缓存雪崩这几类经典灾难。今天这篇我就把自己这些年排查和解决Memcached过期相关问题的经验从机制原理到分布式锁、逻辑过期、多级缓存等一整套方案一次讲清楚。无论你是刚接手公司老项目的维护者还是正在设计新系统的高并发存储方案这篇文章都适合你。我会尽量把每个方案背后的取舍逻辑说明白——不光是给你代码更重要的是让你知道为什么在这个场景下要选它以及选它会付出什么代价。1. 先从根上理解Memcached的过期机制到底是怎么回事1.1 惰性过期与LRU淘汰不是一回事很多人容易把Memcached的过期删除和LRU淘汰混在一起其实这是两套完全独立的机制搞清楚这一点特别关键。Memcached对key设了过期时间后并不像我们想象中那样有个后台线程盯着时间一到立刻删掉。它用的是惰性过期lazy expiration策略——就是说只有当某个key被再次访问的时候Memcached才会去检查它的过期时间戳如果发现已经过期才会真正把它从内存里删掉并返回空值。这种设计的动机很好理解减少无谓的CPU扫描用空间换性能。但副作用也随之而来——过期的数据在被访问之前会一直占着内存不释放。如果短时间写入大量带过期时间的key而它们又迟迟没有访问请求内存里就会堆很多“幽灵数据”。这时候LRU淘汰就开始起作用了。Memcached的内存分配器在空间不足时会优先淘汰最近最少使用的条目注意是替换掉最老的、包括那些还没到过期时间的有效数据。这就是很多新手会惊讶的地方明明我设置了60秒过期怎么40秒就被“消失”了原因就是内存不够用了LRU把它当成“冷数据”提前清掉了。所以在排查Memcached缓存丢失问题时第一件事就是分清楚到底是过期时间到了被清理还是内存不足被LRU淘汰这两者的数据恢复策略完全不同。1.2 过期时间设置的隐藏细节0、30天与时间戳Memcached的过期时间参数expiration在设置时有一个容易踩坑的分界线当秒数不超过30天2592000秒时它被解释为相对当前时间的偏移量超过30天则直接解释为Unix绝对时间戳。也就是说你如果想给缓存设置一个40天的有效期传进去的是3456000这个相对秒数但实际上Memcached会认为这是一个绝对时间戳而这个时间戳在1970年早就过期了key就会立刻失效。反过来也一样如果你拿某个未来时间戳但数值小于30天偏移量它也会被当成相对时间处理。提示设置超长过期时间时先用date %s算出目标时刻的绝对时间戳再手动计算是否跨过了30天界限两种字段类型要做好转换标记避免埋雷。在实际场景中大部分业务的缓存过期时间都集中在几分钟到几小时很少触及这个坑。但一旦你做的是优惠券、秒杀库存这类需要精确到天的长周期业务就必须把这个30天分水岭刻在脑子里。1.3 过期时间精确性其实不是你想的那样精确Memcached内部处理过期时间时并不会在毫秒级别触发清理操作。有一个小细节是Memcached在get时判断过期使用的内部时钟有些人会担心服务器时间被修改会不会导致缓存异常——这个担忧是有道理的。虽然Memcached启动后会维护自身的内部时钟但它也会周期性地与系统时间同步如果运维人员手动调整了系统时间缓存过期判断就会出现短暂的漂移。我曾经遇到过一次线上事故排查到最后发现是DBA在凌晨校准NTP时间导致几十台缓存实例同时多存活了十几秒那一次数据库连接数直接飙到报警阈值。因此在生产环境部署缓存时请务必保证ntpd或chronyd时间同步服务正常运行并且禁止任何未经评估的手动改时间操作这比想象中影响更广。2. 三类经典故障穿透、击穿、雪崩的成因与判定了解了Memcached底层机制再来看实际中最常发生的三类问题。虽然现在很多人把这三个词挂在嘴边但不少人在实际排查时仍然容易搞混我在这里用比较直白的说法重新梳理一遍。2.1 缓存穿透不停地查那些“根本不存在”的key缓存穿透是指请求的key在缓存中不存在数据库中也同样不存在的场景。这种请求每来一次缓存必然没有因为压根没数据可写于是就直接怼到数据库。如果这种请求量一大数据库会被无效查询压垮。典型的攻击场景是恶意用户遍历一批不存在的商品ID或者一个正常用户突然请求了大量已下架的旧商品。这类数据不仅在缓存里查不到在数据库里也不存在因此缓存层完全起不到“挡一层”的作用。核心特征可以用一句话概括缓存和数据库都没有但请求量巨大。判定方式也很简单临时开启Memcached的stats命令查看cmd_get与get_hits计数如果命中率断崖式下跌而数据库查询量同步上升且查询多为无效查询基本可以断定是穿透。2.2 缓存击穿热点key在过期瞬间被大量请求“打穿”缓存击穿指的是一个被特别高频访问的key比如微博热搜、爆款商品详情在过期的瞬间大量请求同时发现缓存为空然后一起涌向数据库。这里要特别注意它与穿透的区别击穿的前提是数据在数据库中是存在的只是缓存恰好在这一刻缺失了。我经历过最典型的案例是一次大促活动的商品详情页。商品id是固定的Redis里也有备份但是Memcached里设置的缓存时间正好在流量高峰期的前几秒过期了一瞬间几百个线程同时回源查库。数据库连接池被打满整个服务链路的可用性都受了影响最后重启才恢复。击穿问题的本质是单个热点key的失效时间和高并发窗口重叠。统计上你可以用stats items命令观察热点key所在slab的expired_unfetched数值如果大量key过期但还没被访问然后再突发访问基本就是击穿的前兆。2.3 缓存雪崩大规模的key在同一时间段集中失效雪崩是指缓存中大量的key在同一时间段内一起过期导致这些key的请求全部回源到数据库。相比击穿的单点问题雪崩是面上问题影响面更大。一个常见的诱因是程序员在设置缓存过期时间时图省事用了统一的固定时间。比如对所有商品设置60 * 60 * 24一天的过期时间上线时刻是上午10点那么第二天上午10点整所有缓存几乎同时过期。这一分钟的数据库流量能冲到平常的几十倍DBA当场血压拉满。另外还有一种被人忽略的“人工雪崩”发布系统在版本上线时统一执行了缓存清理脚本把所有key一次性删掉了。当时还没引入灰度导致一个简单的发布操作硬生生搞出一次数据库故障。2.4 一张表理清三类故障的差别故障类型缓存情况数据库情况核心特征典型触发场景缓存穿透无该key缓存无该数据查询目标不存在恶意遍历ID、下架商品访问缓存击穿有key但已过期有该数据单个热点key失效热搜词条、爆款详情页缓存雪崩大量key集中失效有该数据大批key同时过期统一固定过期时间、批量清理3. 落地解法从基础策略到分布式锁的完整演进3.1 第一层防线空值缓存与布隆过滤器解决缓存穿透最朴素的办法就是把空结果也缓存起来。当数据库查询不到数据时仍然在Memcached里写入一个空值占位并设置一个较短的过期时间比如60秒到5分钟。这样后续相同的无效请求就会直接被缓存层拦截不会到达数据库。用PHP客户端操作Memcached的伪代码如下$memcached new Memcached(); $memcached-addServer(127.0.0.1, 11211); $productId $_GET[id]; $cacheKey product:info: . $productId; $product $memcached-get($cacheKey); if ($memcached-getResultCode() Memcached::RES_NOTFOUND) { $product queryDatabase($productId); if (empty($product)) { // 写入空值占位60秒后过期避免缓存穿透 $memcached-set($cacheKey, , 60); } else { $memcached-set($cacheKey, $product, 3600); } }这里有一个小细节判定RES_NOTFOUND要比直接判断返回值更可靠因为缓存的值本身可能就是空字符串或者false直接判断返回内容真假容易误判。空值缓存能解决大部分穿透但有一个明显缺陷如果恶意请求的key每个都不一样比如随机拼接的UUID那么缓存里会堆满无效key占内存不说每次还是要回源一次数据库判断到底存不存在该数据。这种情况下就需要引入布隆过滤器在前置层拦截。布隆过滤器是一种很省内存的概率型数据结构它的原理说白了就是对一个key做多次哈希映射到一个bit数组上查询时只要任何一位为0那这个key一定不存在。把数据库里所有存在的商品ID预先加载进布隆过滤器每次请求先过布隆判定不存在就直接拦掉根本不进缓存和数据库。提示布隆过滤器有一定的误判率把不存在的key误判为存在但不会漏判存在的key一定会被放行。实际使用中可以通过调整bit数组长度和哈希函数数量控制误判率在1%以下代价是误判的那些请求会继续走到缓存层但影响可控。3.2 第二层防线过期时间打散与多级缓存处理缓存雪崩最直接的办法就是让key的过期时间分散不要让它们齐刷刷地到期。业内最常用的做法就是在原始过期时间基础上加一个随机偏移量。Java伪代码示意// 基础过期时间5分钟加上0~60秒的随机偏移 int baseExpire 5 * 60; int randomOffset new Random().nextInt(60); int expireTime baseExpire randomOffset; memcachedClient.set(cacheKey, value, expireTime);这种做法虽然不优雅但实现成本极低、效果立竿见影。对于大促活动这种场景还可以进一步把热点数据的缓存时间直接拉长到小时级别只要数据变更时手动删除对应key即可用一致性换可用性。多级缓存的思路也很实用。简单说就是优先查本地进程内的缓存如Caffeine、Guava Cache查不到再查Memcached再查不到才回源数据库。本地缓存是放在应用JVM堆里的没有网络IO快得离谱Memcached做二级共享缓存解决多实例间数据一致性问题数据库兜底。这套方案在实际落地时有个需要特别注意的点本地缓存的生命周期要可控。如果本地缓存不及时失效就可能出现同一个请求打到不同实例上拿到不同数据的情况。我当时的方案是给本地缓存设置极短的过期比如10~30秒同时通过消息总线广播失效通知一旦数据库数据变更所有实例监听MQ消息主动删掉本地缓存。这样在绝大多数场景下数据最多延迟几十毫秒业务完全可接受。3.3 第三层防线互斥锁与分布式锁利用互斥锁是应对缓存击穿的核心手段。它的逻辑很简单当多个请求同时发现缓存失效时只放一个请求去数据库加载数据其他请求阻塞等待或快速失败重试。单机场景下用synchronized或ReentrantLock就行但在分布式集群环境下必须用分布式锁。结合热词中提到的“springcloud架构中分布式定时任务的解决方案”很多组件天然为分布式锁提供了支持。我以Memcached自身的add命令来实现分布式锁为例来说明原理因为Memcached的add只有在key不存在时才能设置成功这个原子性特点正好可以用来做锁。public class MemcachedDistributedLock { private static final int LOCK_EXPIRE 3000; // 锁过期时间单位毫秒 private static final int RETRY_INTERVAL 50; // 重试间隔 private static final int MAX_RETRY_TIMES 20; // 最大重试次数 public boolean tryLock(MemcachedClient client, String lockKey) { boolean locked client.add(lockKey, 1, LOCK_EXPIRE / 1000); if (!locked) { // 拿到锁失败可能是别人持锁中轮询等待 for (int i 0; i MAX_RETRY_TIMES; i) { try { Thread.sleep(RETRY_INTERVAL); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return false; } locked client.add(lockKey, 1, LOCK_EXPIRE / 1000); if (locked) { break; } } } return locked; } public void unlock(MemcachedClient client, String lockKey) { try { client.delete(lockKey); } catch (Exception e) { // 删除失败也无所谓锁有自动过期兜底 } } }这里有一个很关键的细节加锁时一定要设置过期时间。如果持有锁的线程在执行数据库查询时发生Full GC或网络抖动卡顿住了锁会一直持有没有人释放其他线程全部阻塞整个接口就瘫痪了。设了过期时间后即使持锁线程失联锁也会自动消失其他线程就能继续抢锁执行。当然过期时间设得太短也不行如果数据库查询平均耗时是500ms锁时间设1000ms就过于紧张建议按业务最慢查询时间的3~5倍来设置。3.4 更优雅的实践逻辑过期方案互斥锁方案虽然有效但有一个体验问题是在高并发下抢不到锁的线程需要阻塞或快速失败重试用户可能会感觉到明显的响应延迟。后来业界慢慢演进出一个更丝滑的方案——逻辑过期。所谓逻辑过期本质上是缓存数据里的字段保留真正的业务数据并额外增加一个逻辑过期时间戳但Memcached层面对这个key不设置物理过期时间让它一直存在。当读取时发现业务时间戳已过期就返回旧数据给调用方同时异步线程去数据库加载最新数据回填缓存。实现要点public class CacheWrapperT { private T data; // 真实业务数据 private long expireTime; // 逻辑过期时间戳 public CacheWrapper(T data, long expireTime) { this.data data; this.expireTime expireTime; } } public T getFromCache(String key) { CacheWrapperT wrapper memcachedClient.get(key); if (wrapper null) { // 缓存中该key不存在说明从未加载过走正常回源流程 return loadAndCache(key); } if (wrapper.getExpireTime() System.currentTimeMillis()) { // 逻辑过期时间未到直接返回缓存数据 return wrapper.getData(); } // 逻辑过期但数据仍返回给用户同时触发异步刷新 asyncRefresh(key); return wrapper.getData(); }这种方案的优点是在缓存过期瞬间用户依然能拿到旧数据不会出现接口响应延迟或空窗期。数据库的压力也被分散到异步刷新线程不会出现瞬时大流量。缺点也很明显数据一致性窗口被拉长了如果业务对数据新鲜度要求极高比如库存扣减就不太适合。另外一个代价是每个缓存value都要额外封装一个包装类序列化大小会膨胀一些。我在实际项目中是把互斥锁和逻辑过期结合用的逻辑过期保证“不击穿”如果异步刷新线程发现数据库查询失败或者存在多线程并发刷新同一个key再用分布式锁保证只有一个线程在刷。4. 实战现场一次Memcached缓存雪崩的完整排查记录第三节把方案讲完了这一节分享一次真实的故障排查过程。那是一个标准Spring Cloud微服务架构的电商项目某个晚上大促预热阶段监控突然告警商品数据库的QPS在30秒内从500飙到了18000数据库连接数打满多个接口返回超时。第一反应是数据库出问题了DBA排查后给出结论无慢SQL但收到大量商品详情的查询请求应该是缓存失效。于是我立刻登录Memcached控制台执行了以下排查命令telnet 127.0.0.1 11211 statsstats输出中我重点看了几个指标curr_items当前存储的key数量这时候是8000多比平时少了近3万expired_unfetched已过期但还未被访问的key数量这个数值已经到了6位数evictionsLRU淘汰数也在一路暴涨结合业务日志发现缓存写入端的代码里所有商品详情key的过期时间都设置成了一个固定值86400也就是24小时。因为上线时间是上午10点当天晚上8点正好是第一批key过期的时刻又赶上促销预热流量高峰几万个商品key几乎同时失效所有请求同时回源数据库直接被压崩。确认了是雪崩问题我当时的处理分三步走临时熔断在网关层针对商品详情接口开启限流只放行部分流量同时把数据库连接池扩容一倍保住核心链路。快速恢复写了一个脚本分段批量回刷缓存让key的过期时间错开避免再次统一过期。长期修复在业务代码里把所有固定过期时间全部改成“基础时间随机偏移”并上了多级缓存。这次事故给我最大的教训是缓存过期时间是系统参数不是业务参数。不要凭感觉写一个看着合理的固定值就上线一定要评估这个失效时间落在哪个流量时段以及同时过期的key有多少。上线前在测试环境用脚本模拟一下同时写入1万个不同过期时间的key观察在过期临界点数据库的回源流量曲线。4.1 常见问题速查表现象可能原因排查命令/方法解决方法缓存命中率突降过期时间到点/LRU淘汰stats查看evictions加内存、缩短缓存时间、检查过期设置key提前消失内存不足被LRU淘汰stats items查看内存使用调整-M参数关闭LRU、增加内存众多key同时失效过期时间未加随机偏移代码审查搜set(的过期参数过期时间基础值随机值缓存中有但读不到客户端使用不同序列化方式检查两端序列化协议是否一致统一JSON或二进制序列化set后立即get返回空过期时间超30天踩了分界线检查过期时间的秒数转成绝对时间戳传入并发回源数据库热点key击穿查看监控中单key的get量加互斥锁或逻辑过期4.2 Memcached服务端参数调优实战除了业务代码上的方案Memcached本身也有一些启动参数可以帮助平滑过期问题。我常用的几个# 启动memcached时建议加的参数 memcached -d -m 2048 -p 11211 -u root -l 127.0.0.1 -c 1024 -M-M参数禁止LRU淘汰内存不足时直接返回错误而不是替换数据。这个参数要慎用它只是把问题从缓存层推给了业务层但对排查问题很有帮助。-f 1.5与-n参数控制slab内存块的增长因子和最小分配空间。如果业务缓存数据大小很均匀默认参数过得去如果数据大小很离散建议调小-f到1.25减少内存浪费。-t参数Memcached 1.5及以上版本支持多线程可以用-t 4开启4个工作线程提升高并发下key查询的处理能力。还有一个容易被忽略的点Memcached的stats命令输出的get_hits是累计值需要间隔几秒取两次做差值才能算出实时的命中率。很多监控系统直接把累计值当实时值展示绷了误导判断排查时留意一下。# 第一次取数 echo stats | nc 127.0.0.1 11211 | grep get_hits # 等10秒后第二次取数 sleep 10 echo stats | nc 127.0.0.1 11211 | grep get_hits # 命中率 (第二次get_hits - 第一次get_hits) / (第二次cmd_get - 第一次cmd_get)4.3 代码层面的避坑经验再分享几个代码层面容易踩的坑这些是我在带团队Code Review时反复强调的点第一缓存写入和更新要保持原子性。很多业务场景是先更新数据库再删缓存key。但如果删缓存失败旧数据就会一直留在缓存里。我当时在项目里的标准做法是数据库更新成功后不走delete而是直接set新的值并且通过MQ消息兜底重试如果第一次set失败消费消息再set一次。第二批量加载大key时要限制并发。有些团队为了预热快上线时写了个for循环把所有商品全部加载一遍几十个线程并发去数据库拉全量把DBA吓得不轻。正确的做法是控制并发数单个线程循环加载并在循环中短暂sleep给Memcached和数据库都留一点喘息空间。第三警惕客户端连接池耗尽。Memcached客户端一般都有连接池机制默认连接数往往只有几十个。如果缓存过期后大量请求同时回源热点key的耗时变长连接池里的连接可能全部被占满其他正常请求也会跟着阻塞等待连接造成“雪崩叠加雪崩”。我建议连接池的maxTotal至少调到200以上并且设置合理的maxWaitMillis宁可快速失败也不无限等待。第四序列化方式要统一。Memcached本身不关心value是什么类型存进去的是字节数组。如果一个服务用Java序列化写入另一个服务用JSON读取轻则拿到乱码重则直接抛出反序列化异常导致缓存永远读不到流量全部回源。我们的规范是全团队统一用JSON并且value统一加一个版本号字段方便未来做格式升级。5. 多级缓存与高并发架构下的进阶应用前面提到的方案大多围绕Memcached自身来做优化。但实际在高并发架构中尤其是Spring Cloud这类微服务架构下缓存层往往是多级组合的。这里聊聊我比较推崇的一套组合形态以及它们各自发挥什么作用。5.1 本地缓存 Memcached Redis的组合设计很多人会问既然有了Redis为什么还要用Memcached这个问题在技术选型时经常被拿出来讨论。我的判断是如果团队没有历史包袱新项目可以直接用Redis功能更丰富支持持久化、数据结构多、分布式锁成熟。但如果公司已经有大量存量的Memcached集群并且你的场景就是简单的key-value读取和写入Memcached的性能依然相当能打尤其是纯读场景下多线程模型比Redis单线程模型在密集型小key读取上更有优势。但如果是在一个比较完善的微服务架构中我更推荐的是本地缓存(Caffeine) Redis Memcached的三级组合一级Caffeine放最热的数据爆炸快但容量有限二级Memcached作为进程外的分布式缓存在多个应用实例之间共享降低回源率三级Redis承担需要持久化与复杂数据结构的场景比如分布式锁、计数器、排行榜三级缓存的更新策略是数据变更时逐级淘汰先删本地缓存再删Memcached最后再更新Redis。因为本地缓存没有跨进程通知机制所以它的过期时间必须非常短通常3~5秒就够了。如果业务上有强一致需求可以引入Zookeeper的节点监听或者Redis的Pub/Sub机制做广播失效这部分篇幅比较多改天单独开一篇聊。5.2 缓存预热如何避免冷启动瞬间击穿缓存过期问题的另一个变种是服务启动时的冷缓存。系统刚部署完Memcached里空荡荡这时如果有大量请求涌进来所有key都会回源数据库等同于一次虚拟雪崩。我们的处理手段是在服务启动完毕、开始接流量的前几秒先执行一个预热任务把最核心的几百个key提前加载到Memcached。这个预热任务通常写在启动监听器里用PostConstruct或者Spring Boot的ApplicationRunner触发。Component public class CacheWarmer implements ApplicationRunner { private static final ListString HOT_KEYS Arrays.asList(product:10001, product:10002); Autowired private MemcachedClient memcachedClient; Override public void run(ApplicationArguments args) { for (String key : HOT_KEYS) { if (memcachedClient.get(key) null) { Object data loadFromDatabase(key); memcachedClient.set(key, data, 3600 new Random().nextInt(60)); } } log.info(Hot keys cached, total{}, HOT_KEYS.size()); } }注意这里设置过期时间时也加了随机偏移避免其他实例同时启动导致同一批key同时失效。另外还有一个小技巧预热时优先从数据库读最近24小时内有访问记录的数据而不是遍历全表。这样预热的数据才是“准热点数据”比盲目加载全量有效得多。5.3 监控报警体系让过期问题在爆发前被发现很多缓存问题之所以酿成大事故不是因为解决不了而是因为没能在爆发前发现。我强烈建议每个使用Memcached的业务都建立一套包含三个维度的监控第一维度缓存实例自身的健康状态。采集curr_items、bytes、evictions、expired_unfetched四个指标。evictions持续走高说明内存不足expired_unfetched居高不下说明大量key过期但没被访问需要审视过期时间的设置逻辑。第二维度业务层面的命中率。客户端每次get都记录get_hits与cmd_get上报到Prometheus或类似监控系统计算实时命中率。正常情况下命中率应保持在95%以上一旦连续5分钟低于90%就要告警排查。第三维度数据库回源流量。比对数据库层的QPS曲线和缓存命中率曲线如果缓存命中率下降的同时数据库QPS同步陡增说明缓存层失效了如果命中率没变但数据库QPS仍然很高则可能是穿透或者业务本身在暴量增长需要单独分析。这三个维度的监控缺一个排查时都可能变成盲人摸象。我之前遇到过一次数据库QPS无故升高与快速检查缓存命中率是正常的后来才发现是某个爬虫在大量请求不存在的商品ID属于缓存穿透问题。如果没有数据库流量监控的对比分析这个结论会绕很久才能得出。6. 个人实践后的几点体会最后聊几句个人体会。Memcached缓存过期问题表面上是几个技术方案的选择题实际上更重要的是对缓存生命周期的全局管理。之前带的团队里最开始的缓存代码都是散落在各个业务Service层里的每个业务自己设定过期时间、自己管理失效逻辑。结果就是同一份数据在3个不同的缓存key里各存了一份每个key的过期时间完全不同一致性维护成本非常高。后来我们统一收敛到一层CacheService封装所有读写Memcached的操作都必须走这个Service过期时间的配置集中管理在配置中心任何变更都有审批记录。这个改造完成之后缓存相关的线上问题数量下降了至少70%。所以如果你现在的团队也是缓存代码到处飞的状态我诚恳建议下一步不是引进更新的技术而是先做统一封装和规范。另外关于缓存过期问题我的心态也经历了三个阶段最初看别人遇到缓存雪崩觉得是运气不好后来自己踩了坑觉得是设计失误再到现在觉得这就是系统演进必须经历的过程。缓存层帮数据库挡掉了99%的流量那剩余1%回源的请求一旦瞬间集中爆发就必然会在某一刻考验系统的兜底能力。做技术方案时多想想极端情况——凌晨三点这批key过期了怎么办所有服务实例同时重启了怎么办缓存集群断连了怎么办把这些问题提前想清楚就不用每次都在事故群里狼狈地道歉了。最后再分享一个小技巧Memcached的key建议统一加上业务前缀和版本号比如v2:product:detail:123这样业务升级时可以通过更换前缀来做到逻辑隔离而不是删除旧key后承受瞬间的缓存穿透。这个习惯帮我避免了至少三次潜在的事故也推荐给你。
