缓存这东西用对了是加速器用错了就是隐形炸弹。我之前维护活动系统时遇到过一次线上事故运营在后台把商品状态从“下架”改成“上架”前端页面却迟迟不刷新最后排查到下游定时任务用set把刚更新的状态又覆盖回了旧值。问题暴露得很典型——很多人对 Memcachedreplace命令的理解仅限于“可以更新缓存”但真正到生产环境里把它的语义和set分清、把它的边界条件吃透才能避免同类问题。这篇文章我就把replace命令从使用姿势、协议参数、踩坑案例到源码行为完整讲一遍希望能帮到正在用 Memcached 或者准备入手的同学。1. replace命令解决的问题远不止“更新缓存”这么简单很多文档给replace的定义只有一句话替换已存在的键。听起来理所当然甚至有点多余——毕竟set也能覆盖已存在的键那我为什么还要单独记一个replace这套逻辑在单机单线程测试环境里没问题一旦进入多服务、多线程、有淘汰和过期策略的生产环境replace的语义价值就体现出来了。1.1 一个让我记忆深刻的生产事故事故背景是这样的我们的商品服务里有一个状态机商品状态依次是“待审核 - 审核通过 - 上架 - 下架”。缓存 key 的格式是product:{id}:statusvalue 是状态枚举。运营在后台操作“上架”时接口会写库然后更新缓存与此同时有一个定时任务在扫描待审核商品把“超过72小时未审核”的商品自动驳回为“待审核”。定时任务的逻辑很简单set(product:{id}:status, 待审核)。看起来没问题对吧但它用的就是全量覆盖的set。运营刚把状态改成“上架”定时任务同一秒扫描到该商品之前处于“审核通过”状态于是又用set写回了“待审核”。前端轮询到的缓存就一直是旧状态直到缓存过期才恢复。这个问题的本质不是业务逻辑错误而是写缓存时没有区分“我要确保覆盖一个已存在的值”和“我只想更新我预期的那个值”——这正是replace和set的核心分水岭。1.2 replace的语义定位只在“键已存在”时执行替换replace的实际行为是如果 key 存在就用新 value 覆盖旧 value如果 key 不存在什么都不做返回NOT_STORED。也就是说它不是一个无条件的写操作而是一个带前置条件“key 必须存在”的写操作。用数据库的话来类比replace更像UPDATE WHERE key XXX而set是标准数据库里的UPSERT存在则更新不存在则插入。“Key 是否存在的判定”里面有一个容易被忽略的细节如果 key 已经过期Memcached 在内部执行惰性删除逻辑上等同于不存在。你向一个已经过期的 key 发replace返回的也是NOT_STORED并不会因为“这个 key 以前存在过”就让你替换成功。这一点在下一节的过期时间参数里还会再强调。从命令设计的历史来看Memcached 最初只有set后来才补充了add和replace。add解决的是“仅在不存在时写入”replace解决的是“仅在存在时写入”两者合在一起才让缓存的写入从全量覆盖进化到了带条件写入为分布式锁、状态机更新、防重复初始化这类场景提供了底层支持。2. 命令格式与参数细节flags不是摆设exptime有隐藏规则无论你用的是 telnet 手敲命令还是通过 PHP、Python、Java 客户端调用最终都会转换为 Memcached 的文本协议或者二进制协议。文本协议上手最快也最适合排查问题所以我先从文本协议讲起。2.1 完整的文本协议格式replace的文本协议格式如下replace key flags exptime bytes\r\n data block\r\n注意这里有两个\r\n。第一行是请求头以\r\n结束紧接着发送长度为bytes的数据块数据块发送完毕后再补一个\r\n表示数据结束。一个完整的 telnet 会话示例replace user:1001 0 0 4 男 STORED这里key是user:1001flags是0exptime是0永不过期bytes是4“男”的 UTF-8 字节数是 6这里注意中文在 UTF-8 下是 3 字节一个字符所以你要按实际字节数写数据块是具体内容。2.2 flags、exptime、bytes的隐藏规则flags是一个 32 位无符号整数Memcached 本身不关心它的值只是在存储和返回时原样带出。很多语言客户端会把序列化方式、压缩标记、数据类型写进 flags比如 flags1 表示 JSONflags2 表示 MessagePack。实际踩坑点在于如果你在一个客户端里设置数据时用了 flags读取时必须从 Get 的返回里拿到 flags否则可能无法反序列化。之前有个同事用set写数据时没经过统一封装flags 写成了 0但业务读取端用php-memcached扩展默认按 PHP 序列化格式解析结果读到一堆乱码排查了半天才发现 flags 不一致。exptime是过期时间规则如下exptime 值含义0永不过期1 到 259200030天相对时间表示从现在起多少秒后过期大于 2592000绝对时间Unix 时间戳也就是说你写replace key 0 3600 5表示一个小时后过期如果是replace key 0 1893456000 5表示的是 2030 年 1 月 1 日零点过期按 Unix 时间戳算。还有一点容易踩坑replace 成功之后key 的过期时间会被重置为本次命令里设置的 exptime而不是保留原来的剩余时间。也就是说你每次 replace 一个 key就是给它续了一次命即使那个 key 原本只剩 1 秒就过期了replace 之后它又按你设置的过期时间重新计时了。这一点在下面的“踩坑记录”里会展开。bytes是数据块的实际字节数不是字符数。如果你存的是中文、emoji 或二进制内容必须用字节数计算。发少了Memcached 会等不到完整数据然后返回CLIENT_ERROR bad data chunk发多了多余的部分会被当成下一条命令解析直接导致协议错乱。2.3 STORED、NOT_STORED、EXISTS到底谁返回哪个replace执行之后的响应码取决于当前状态响应码触发条件STOREDkey 存在替换成功NOT_STOREDkey 不存在没有被存储CLIENT_ERROR数据格式错误比如 bytes 和实际数据不一致SERVER_ERROR服务端问题例如数据超过最大 item 大小默认 1MB这里特别提一下EXISTS它主要用于cas命令表示版本号冲突。文本协议下replace不会返回EXISTS因为 replace 不带版本校验它只关心 key 是否存在。如果你在代码里看到了对EXISTS的异常处理但又没用cas那说明可能是你的客户端内部做了封装需要去看客户端的源码。3. 为什么说replace比set更适合“只更新已存在键”的场景从表面语法上看set和replace都可以覆盖一个已存在的 key很多人觉得set就够了。但实际工程里两者在“更新已存在的键”这个场景下行为差异非常大。3.1 Upsert与条件更新的本质区别set是 upsert 语义key 不存在就创建key 存在就覆盖。它天然适合“无论缓存里有没有反正我要保证这条数据是我的最新值”这种场景比如用户登录后更新他的 session 数据。replace是条件更新key 不存在就失败。它天然适合“缓存里必须已经有一条数据了我才有资格更新它”这种场景比如计数器累加、状态迁移、锁续期。用一个日常类比set就像你走进自习室不管有没有人占座你坐下就说“这位置是我的了”replace则像你预约了某个座位只有确认座位牌上写的是你的名字你才落座否则连椅子都不能碰。3.2 一个典型的伪代码对比假设我们要实现“只有商品处于上架状态时才允许更新库存缓存”# 错误的做法无条件覆盖 memcached.set(product:1001:stock, 99) # 正确的做法先查再替不行这种写法有竞态 stock memcached.get(product:1001:stock) if stock is not None: memcached.set(product:1001:stock, 99)上面的“先查再替”在单线程里没问题但并发环境下两个线程同时 get 到旧值然后都执行 set后 set 的线程可能覆盖前一个线程基于旧值计算的库存产生超卖。如果用replace语义就变成了“只有缓存里已经有库存这个 key 了我才能把新库存写进去”至少保证了更新的前提条件是“key 存在”而不是“什么条件都没有”。# 更合理的做法用 replace 表达“只更新已存在的 key” stored memcached.replace(product:1001:stock, 99) if not stored: # 说明缓存里还没有这个 key需要先初始化 memcached.add(product:1001:stock, 99)3.3 并发场景下的语义差异再想深一层如果两个线程同时都要replace同一个 key会发生什么谁的replace最后执行谁的值就生效replace本身不提供任何版本校验这跟set没有区别。所以在严格的并发控制场景下replace替代不了cas。但即便如此replace的价值在于它划分了“写入的资格边界”它可以保证一个本来就存在的 key 不会被误删或者跳过也可以保证一个不存在的 key 不会被意外创建。比如你做缓存预热时先用add写入初始值然后所有后续更新统一用replace这样整个缓存的生命周期就是“创建 - 更新 - 过期”逻辑非常清晰。而如果全程用set一旦预热失败后续的set会默默把 key 补上掩盖了上游数据缺失的问题反而不利于排障。4. 真实踩坑记录replace返回NOT_STORED之后怎么办纸上谈兵到这里分享几个我在生产环境里的实际踩坑案例。每一个都配上了解法和思路希望能帮你省掉几晚上的排查时间。4.1 场景一缓存被淘汰后replace失败需要回退策略Memcached 内存管理的机制是 LRU 过期惰性删除内存不足时最久未访问的 item 会被淘汰即使它还没到过期时间。所以“key 存在”这个前置条件是脆弱的一个 key 可能在没有任何人操作的情况下突然被 LRU 淘汰掉。我遇到的一个真实案子是用户购物车的缓存 key正常情况下设置 24 小时过期但由于某个大促时段数据量暴涨部分用户的购物车缓存被 LRU 提前淘汰。此时用户只要一加购代码里执行的逻辑是replace(cart:{uid}, new_cart)结果返回NOT_STORED购物车在缓存层面就“丢”了。表面看用户没报错但实际他的购物车加购操作没生效数据在底层数据库里也是对的只是缓存一直没更新。解决办法是replace失败之后要么回退set/add重新初始化要么捕获NOT_STORED后重新从数据库加载并add回去。但这里必须小心两个问题回退用set会让“key 不存在”这个信号失效等于把条件更新退化成了无脑更新。回退用add更合理一旦并发情况下多个线程都发现replace失败只有一个线程能add成功其他线程会继续拿到NOT_STORED但它们的作用本来只是“确保有一条数据”所以失败也没关系。4.2 场景二replace也解决不了并发互相覆盖要用cas有一次做秒杀库存扣减我用replace写剩余库存逻辑是先从库中读一次余量扣减后再replace。看起来没问题但高并发下一测试就出现了超卖。原因很简单两个并发请求都读到了库存为 1请求 A 扣减为 0 后replace成功请求 B 基于旧的 1 再扣减也写成 0但实际库存已经被扣了两次业务上等于卖了两件只减了一次。replace只保证“key 存在”才更新不保证“value 是我上次读到的那个版本”。这种情况必须用casCompare And Swap也就是 Memcached 里的getscas组合。gets会返回一个唯一版本号cas带上这个版本号去更新如果版本号不匹配就返回EXISTS由业务层决定重试还是拒绝。这是我反复跟团队强调的一点不要因为有了 replace 就把原语级别的并发控制忘掉它们解决的是不同层次的问题。4.3 场景三bytes算错replace直接CLIENT_ERROR这个坑在写脚本或者 telnet 调试时最容易碰到。比如你想往 Memcached 里写一条中文数据Python 里看字符串长度是 3但用 UTF-8 编码后字节数是 9如果命令里的 bytes 写 3Memcached 会认为数据块还没结束一直等不到结束符最终返回CLIENT_ERROR bad data chunk。实际操作里bytes 应该是编码之后的数据长度import memcache value 新的状态 raw value.encode(utf-8) print(len(raw)) # 12而不是 4 mc memcache.Client([127.0.0.1:11211]) # 一定要传字节长度 mc._unsafe_set(bkey, raw)如果你的客户端已经封装好了 set/replace它内部会自动处理编码问题。但如果你想通过 telnet 或者 netcat 手动发协议包一定要先把数据编码好再数 bytes。4.4 场景四过期时间被重置不是保留旧TTL我刚用 replace 的时候有一种错觉replace 只是更新 value原来的过期时间应该保持不变。但实际行为是replace 和 set 一样会应用你这次命令里的 exptime。也就是说如果你每次 replace 都传了一个比较大的过期时间那么这个 key 的理论过期时间会被不断往后推相当于续期。这在有些场景里是好事比如活跃用户 session 续期。但在另一些场景里却是坏事比如你想让一个 key“过期后自动消失”但某个服务会定期对它执行 replace导致它永远不过期。我曾经排查过一个缓存雪崩的前兆某个排行榜缓存设计了 5 分钟过期但由于刷榜任务每 1 分钟就 replace 一次并重置过期时间为 5 分钟这个 key 实际上永远不会过期一旦原服务重启缓存里全是旧数据直到手动清掉才恢复。所以用 replace 之前想清楚你重置过期时间的行为是不是你想要的如果不是考虑是否应该只在 value 变化时才更新而不是定时无条件 replace。5. 调试与源码验证从telnet到items.c把replace彻底看透文字说了一堆不如实际动手验证一次。这里给出一套完整的调试路径从外部协议到内部源码真正把 replace 的运行机制从外到内看透。5.1 telnet直连Memcached实操Memcached 默认端口是 11211文本协议可以直接通过 telnet 调试Windows 上记得先在“启用或关闭 Windows 功能”里打开 Telnet 客户端。连上之后先确认服务正常telnet 127.0.0.1 11211 stats看到STAT pid、STAT uptime说明服务正常。然后模拟一次完整的 replace 流程# 先塞一个 key set greeting 0 0 6 hello STORED # 用 replace 更新 replace greeting 0 0 6 world STORED # 用 get 验证 get greeting VALUE greeting 0 6 world END # 对不存在的 key 执行 replace replace not_exist_key 0 0 2 hi NOT_STORED这里有个细节get greeting返回的第二行VALUE greeting 0 6中的0就是当时的 flags最后面的6是字节数。如果之前用set时 flags 写的 1get 时这里就会显示 1客户端拿到这个值才能正确反序列化。如果系统里没装 telnet也可以配合 bash 自带的/dev/tcp来做快速验证exec 3/dev/tcp/127.0.0.1/11211 printf replace dev_tcp_test 0 0 3\r\nbar\r\n 3 head -n 1 35.2 源码层面确认replace的“存在”判定Memcached 的源码结构不算复杂关键函数在items.c的do_store_item和proto/text.c老版本在memcached.c里的process_update_command。文本协议收到replace时命令解析后会把操作类型标记为NREAD_REPLACE。核心逻辑大体是先对 key 执行一次内部查找如果 key 为空且操作类型是 replace直接返回NOT_STORED不会进入真正的存储流程。只有 key 存在才会走item_replace或者类似的覆盖逻辑。为什么要讲这个因为“key 存在”的判定并不等于“内存里有一个没过期的 item”。Memcached 的 item 带有过期时间查找时会做一次过期检查如果发现已经过期会先执行惰性删除再返回空。所以你今天通过 telnet 手敲replace一个“你记得存在但已经过期”的 key返回的一定是NOT_STORED。理解了这一点你再看前面讲到的 LRU 淘汰场景就会明白 replace 的“存在”前提比我们想象得更脆弱也更需要配合 add/set 回退策略。5.3 stats是验证replace行为的好帮手调试完命令后建议用stats命令观察 Memcached 的内部统计指标重点看这几个指标意义get_hits / get_missesget 的命中与未命中情况delete_misses删除操作没有命中 key 的次数curr_items当前存储的 item 数量total_items累计存储的 item 数量expired_unfetched已过期但尚未被外部 get 读取到的 item 数量一个典型的验证思路先stats记录curr_items和total_items然后对同一个 key 多次执行 set你会发现curr_items不变但total_items增加而对同一个 key 多次执行 replacecurr_items不变但total_items也不一定增加视版本而定。这个差异可以帮你确认你操作的是“创建”还是“替换”尤其适合写脚本自动化验证大批量缓存操作时检查是否发生意外的新增。6. 工程实践习惯set、replace、add、cas该怎么选最后聊聊我在实际编码中一直遵守的选择逻辑。Memcached 这几个写命令可以简单梳理成四种语义命令语义适用场景setupsert存在则覆盖不存在则创建普通缓存写入可以无脑覆盖add仅在不存在时创建缓存预热、分布式锁占位、避免并发重复初始化replace仅在存在时替换只更新已存在的 key不创建新 keycas带版本校验的更新并发场景下的强一致性更新6.1 什么时候用replace我一般在这种场景下优先选择 replace更新一个已经确认存在且应该由本次写操作独占的缓存对象做缓存续期比如活跃用户 session、在线状态实现“只更新不新增”的业务约束比如状态机流转缓存里没有状态就不能生成新状态多服务之间对某个 key 的“存在性”有依赖希望写操作在 key 被淘汰/过期时显式失败而不是默默创建。用 replace 最大的价值不是性能性能上和 set 没有本质差别它的价值在于失败可见。NOT_STORED是一个明确的信号它告诉你“这个 key 不在了”你可以据此触发回源加载、重建缓存、或者告警。而 set 的静默创建会把这些问题掩盖掉。6.2 什么时候用cas如果你发现“两个服务同时更新同一个 key谁后写谁赢”是不可接受的那 cas 才是答案。cas 需要搭配 gets 使用流程是value, cas_token mc.gets(product:1001:stock) new_value value - 1 result mc.cas(product:1001:stock, new_value, cas_token) if not result: # 版本冲突重读重试 ...cas 的重试逻辑要控制好次数否则高并发下可能一直冲突。实际经验是重试 3 次以内超过就直接返回失败或者走降级方案不要在 cas 重试上消耗太多时间。6.3 生产环境代码示例下面是一段我比较推荐的缓存初始化加更新“模板”把 add replace cas 都串起来了import memcache mc memcache.Client([127.0.0.1:11211], socket_timeout2) CACHE_KEY product:1001:stock def init_cache(value: int) - bool: 只有不存在的 key 才初始化避免并发重复写 return bool(mc.add(CACHE_KEY, value, time3600)) def update_cache(value: int) - bool: 只更新已存在的 key失败时返回 False 由调用方处理 return bool(mc.replace(CACHE_KEY, value, time3600)) def update_with_retry(value: int, max_retry: int 3) - bool: 并发安全更新使用 gets/cas for _ in range(max_retry): _, cas_token mc.gets(CACHE_KEY) if cas_token is None: # key 不存在先初始化 if not init_cache(value): continue return True if mc.cas(CACHE_KEY, value, cas_token, time3600): return True return False这套模板把缓存的生命周期划分得很清晰初始化走 add普通更新走 replace高并发更新走 cas。调用方不需要在业务代码里频繁判断 key 是否存在成功和失败都由返回值明确表达出了问题日志也容易定位。6.4 最后的补充建议我在实际运维中发现很多 Memcached 分配的异常都源于对 flags 和 bytes 的忽视。如果你用的是字符串类型一定要确认客户端在 get 时是否拿到了正确的 flags如果你自己写协议解析器一定要对 bytes 做异校验防止数据错位。另外线上环境建议开启-o modern或按需调优 LRU 相关参数避免热点 key 过早被淘汰减少 replace 失败率。回头看那场商品状态被覆盖的事故其实只要当初写代码的同学把“更新缓存”从 set 换成 replace并且做好 NOT_STORED 的回退处理问题根本不会发生。缓存命令虽小选错了就是线上事故选对了就是让系统少一个隐患。希望这篇能帮你把 replace 这个命令用得明明白白以后遇到“只更新已存在的 key”这种需求第一反应不再是无脑 set。
Memcached replace命令详解：与set的区别、生产踩坑与源码验证
缓存这东西用对了是加速器用错了就是隐形炸弹。我之前维护活动系统时遇到过一次线上事故运营在后台把商品状态从“下架”改成“上架”前端页面却迟迟不刷新最后排查到下游定时任务用set把刚更新的状态又覆盖回了旧值。问题暴露得很典型——很多人对 Memcachedreplace命令的理解仅限于“可以更新缓存”但真正到生产环境里把它的语义和set分清、把它的边界条件吃透才能避免同类问题。这篇文章我就把replace命令从使用姿势、协议参数、踩坑案例到源码行为完整讲一遍希望能帮到正在用 Memcached 或者准备入手的同学。1. replace命令解决的问题远不止“更新缓存”这么简单很多文档给replace的定义只有一句话替换已存在的键。听起来理所当然甚至有点多余——毕竟set也能覆盖已存在的键那我为什么还要单独记一个replace这套逻辑在单机单线程测试环境里没问题一旦进入多服务、多线程、有淘汰和过期策略的生产环境replace的语义价值就体现出来了。1.1 一个让我记忆深刻的生产事故事故背景是这样的我们的商品服务里有一个状态机商品状态依次是“待审核 - 审核通过 - 上架 - 下架”。缓存 key 的格式是product:{id}:statusvalue 是状态枚举。运营在后台操作“上架”时接口会写库然后更新缓存与此同时有一个定时任务在扫描待审核商品把“超过72小时未审核”的商品自动驳回为“待审核”。定时任务的逻辑很简单set(product:{id}:status, 待审核)。看起来没问题对吧但它用的就是全量覆盖的set。运营刚把状态改成“上架”定时任务同一秒扫描到该商品之前处于“审核通过”状态于是又用set写回了“待审核”。前端轮询到的缓存就一直是旧状态直到缓存过期才恢复。这个问题的本质不是业务逻辑错误而是写缓存时没有区分“我要确保覆盖一个已存在的值”和“我只想更新我预期的那个值”——这正是replace和set的核心分水岭。1.2 replace的语义定位只在“键已存在”时执行替换replace的实际行为是如果 key 存在就用新 value 覆盖旧 value如果 key 不存在什么都不做返回NOT_STORED。也就是说它不是一个无条件的写操作而是一个带前置条件“key 必须存在”的写操作。用数据库的话来类比replace更像UPDATE WHERE key XXX而set是标准数据库里的UPSERT存在则更新不存在则插入。“Key 是否存在的判定”里面有一个容易被忽略的细节如果 key 已经过期Memcached 在内部执行惰性删除逻辑上等同于不存在。你向一个已经过期的 key 发replace返回的也是NOT_STORED并不会因为“这个 key 以前存在过”就让你替换成功。这一点在下一节的过期时间参数里还会再强调。从命令设计的历史来看Memcached 最初只有set后来才补充了add和replace。add解决的是“仅在不存在时写入”replace解决的是“仅在存在时写入”两者合在一起才让缓存的写入从全量覆盖进化到了带条件写入为分布式锁、状态机更新、防重复初始化这类场景提供了底层支持。2. 命令格式与参数细节flags不是摆设exptime有隐藏规则无论你用的是 telnet 手敲命令还是通过 PHP、Python、Java 客户端调用最终都会转换为 Memcached 的文本协议或者二进制协议。文本协议上手最快也最适合排查问题所以我先从文本协议讲起。2.1 完整的文本协议格式replace的文本协议格式如下replace key flags exptime bytes\r\n data block\r\n注意这里有两个\r\n。第一行是请求头以\r\n结束紧接着发送长度为bytes的数据块数据块发送完毕后再补一个\r\n表示数据结束。一个完整的 telnet 会话示例replace user:1001 0 0 4 男 STORED这里key是user:1001flags是0exptime是0永不过期bytes是4“男”的 UTF-8 字节数是 6这里注意中文在 UTF-8 下是 3 字节一个字符所以你要按实际字节数写数据块是具体内容。2.2 flags、exptime、bytes的隐藏规则flags是一个 32 位无符号整数Memcached 本身不关心它的值只是在存储和返回时原样带出。很多语言客户端会把序列化方式、压缩标记、数据类型写进 flags比如 flags1 表示 JSONflags2 表示 MessagePack。实际踩坑点在于如果你在一个客户端里设置数据时用了 flags读取时必须从 Get 的返回里拿到 flags否则可能无法反序列化。之前有个同事用set写数据时没经过统一封装flags 写成了 0但业务读取端用php-memcached扩展默认按 PHP 序列化格式解析结果读到一堆乱码排查了半天才发现 flags 不一致。exptime是过期时间规则如下exptime 值含义0永不过期1 到 259200030天相对时间表示从现在起多少秒后过期大于 2592000绝对时间Unix 时间戳也就是说你写replace key 0 3600 5表示一个小时后过期如果是replace key 0 1893456000 5表示的是 2030 年 1 月 1 日零点过期按 Unix 时间戳算。还有一点容易踩坑replace 成功之后key 的过期时间会被重置为本次命令里设置的 exptime而不是保留原来的剩余时间。也就是说你每次 replace 一个 key就是给它续了一次命即使那个 key 原本只剩 1 秒就过期了replace 之后它又按你设置的过期时间重新计时了。这一点在下面的“踩坑记录”里会展开。bytes是数据块的实际字节数不是字符数。如果你存的是中文、emoji 或二进制内容必须用字节数计算。发少了Memcached 会等不到完整数据然后返回CLIENT_ERROR bad data chunk发多了多余的部分会被当成下一条命令解析直接导致协议错乱。2.3 STORED、NOT_STORED、EXISTS到底谁返回哪个replace执行之后的响应码取决于当前状态响应码触发条件STOREDkey 存在替换成功NOT_STOREDkey 不存在没有被存储CLIENT_ERROR数据格式错误比如 bytes 和实际数据不一致SERVER_ERROR服务端问题例如数据超过最大 item 大小默认 1MB这里特别提一下EXISTS它主要用于cas命令表示版本号冲突。文本协议下replace不会返回EXISTS因为 replace 不带版本校验它只关心 key 是否存在。如果你在代码里看到了对EXISTS的异常处理但又没用cas那说明可能是你的客户端内部做了封装需要去看客户端的源码。3. 为什么说replace比set更适合“只更新已存在键”的场景从表面语法上看set和replace都可以覆盖一个已存在的 key很多人觉得set就够了。但实际工程里两者在“更新已存在的键”这个场景下行为差异非常大。3.1 Upsert与条件更新的本质区别set是 upsert 语义key 不存在就创建key 存在就覆盖。它天然适合“无论缓存里有没有反正我要保证这条数据是我的最新值”这种场景比如用户登录后更新他的 session 数据。replace是条件更新key 不存在就失败。它天然适合“缓存里必须已经有一条数据了我才有资格更新它”这种场景比如计数器累加、状态迁移、锁续期。用一个日常类比set就像你走进自习室不管有没有人占座你坐下就说“这位置是我的了”replace则像你预约了某个座位只有确认座位牌上写的是你的名字你才落座否则连椅子都不能碰。3.2 一个典型的伪代码对比假设我们要实现“只有商品处于上架状态时才允许更新库存缓存”# 错误的做法无条件覆盖 memcached.set(product:1001:stock, 99) # 正确的做法先查再替不行这种写法有竞态 stock memcached.get(product:1001:stock) if stock is not None: memcached.set(product:1001:stock, 99)上面的“先查再替”在单线程里没问题但并发环境下两个线程同时 get 到旧值然后都执行 set后 set 的线程可能覆盖前一个线程基于旧值计算的库存产生超卖。如果用replace语义就变成了“只有缓存里已经有库存这个 key 了我才能把新库存写进去”至少保证了更新的前提条件是“key 存在”而不是“什么条件都没有”。# 更合理的做法用 replace 表达“只更新已存在的 key” stored memcached.replace(product:1001:stock, 99) if not stored: # 说明缓存里还没有这个 key需要先初始化 memcached.add(product:1001:stock, 99)3.3 并发场景下的语义差异再想深一层如果两个线程同时都要replace同一个 key会发生什么谁的replace最后执行谁的值就生效replace本身不提供任何版本校验这跟set没有区别。所以在严格的并发控制场景下replace替代不了cas。但即便如此replace的价值在于它划分了“写入的资格边界”它可以保证一个本来就存在的 key 不会被误删或者跳过也可以保证一个不存在的 key 不会被意外创建。比如你做缓存预热时先用add写入初始值然后所有后续更新统一用replace这样整个缓存的生命周期就是“创建 - 更新 - 过期”逻辑非常清晰。而如果全程用set一旦预热失败后续的set会默默把 key 补上掩盖了上游数据缺失的问题反而不利于排障。4. 真实踩坑记录replace返回NOT_STORED之后怎么办纸上谈兵到这里分享几个我在生产环境里的实际踩坑案例。每一个都配上了解法和思路希望能帮你省掉几晚上的排查时间。4.1 场景一缓存被淘汰后replace失败需要回退策略Memcached 内存管理的机制是 LRU 过期惰性删除内存不足时最久未访问的 item 会被淘汰即使它还没到过期时间。所以“key 存在”这个前置条件是脆弱的一个 key 可能在没有任何人操作的情况下突然被 LRU 淘汰掉。我遇到的一个真实案子是用户购物车的缓存 key正常情况下设置 24 小时过期但由于某个大促时段数据量暴涨部分用户的购物车缓存被 LRU 提前淘汰。此时用户只要一加购代码里执行的逻辑是replace(cart:{uid}, new_cart)结果返回NOT_STORED购物车在缓存层面就“丢”了。表面看用户没报错但实际他的购物车加购操作没生效数据在底层数据库里也是对的只是缓存一直没更新。解决办法是replace失败之后要么回退set/add重新初始化要么捕获NOT_STORED后重新从数据库加载并add回去。但这里必须小心两个问题回退用set会让“key 不存在”这个信号失效等于把条件更新退化成了无脑更新。回退用add更合理一旦并发情况下多个线程都发现replace失败只有一个线程能add成功其他线程会继续拿到NOT_STORED但它们的作用本来只是“确保有一条数据”所以失败也没关系。4.2 场景二replace也解决不了并发互相覆盖要用cas有一次做秒杀库存扣减我用replace写剩余库存逻辑是先从库中读一次余量扣减后再replace。看起来没问题但高并发下一测试就出现了超卖。原因很简单两个并发请求都读到了库存为 1请求 A 扣减为 0 后replace成功请求 B 基于旧的 1 再扣减也写成 0但实际库存已经被扣了两次业务上等于卖了两件只减了一次。replace只保证“key 存在”才更新不保证“value 是我上次读到的那个版本”。这种情况必须用casCompare And Swap也就是 Memcached 里的getscas组合。gets会返回一个唯一版本号cas带上这个版本号去更新如果版本号不匹配就返回EXISTS由业务层决定重试还是拒绝。这是我反复跟团队强调的一点不要因为有了 replace 就把原语级别的并发控制忘掉它们解决的是不同层次的问题。4.3 场景三bytes算错replace直接CLIENT_ERROR这个坑在写脚本或者 telnet 调试时最容易碰到。比如你想往 Memcached 里写一条中文数据Python 里看字符串长度是 3但用 UTF-8 编码后字节数是 9如果命令里的 bytes 写 3Memcached 会认为数据块还没结束一直等不到结束符最终返回CLIENT_ERROR bad data chunk。实际操作里bytes 应该是编码之后的数据长度import memcache value 新的状态 raw value.encode(utf-8) print(len(raw)) # 12而不是 4 mc memcache.Client([127.0.0.1:11211]) # 一定要传字节长度 mc._unsafe_set(bkey, raw)如果你的客户端已经封装好了 set/replace它内部会自动处理编码问题。但如果你想通过 telnet 或者 netcat 手动发协议包一定要先把数据编码好再数 bytes。4.4 场景四过期时间被重置不是保留旧TTL我刚用 replace 的时候有一种错觉replace 只是更新 value原来的过期时间应该保持不变。但实际行为是replace 和 set 一样会应用你这次命令里的 exptime。也就是说如果你每次 replace 都传了一个比较大的过期时间那么这个 key 的理论过期时间会被不断往后推相当于续期。这在有些场景里是好事比如活跃用户 session 续期。但在另一些场景里却是坏事比如你想让一个 key“过期后自动消失”但某个服务会定期对它执行 replace导致它永远不过期。我曾经排查过一个缓存雪崩的前兆某个排行榜缓存设计了 5 分钟过期但由于刷榜任务每 1 分钟就 replace 一次并重置过期时间为 5 分钟这个 key 实际上永远不会过期一旦原服务重启缓存里全是旧数据直到手动清掉才恢复。所以用 replace 之前想清楚你重置过期时间的行为是不是你想要的如果不是考虑是否应该只在 value 变化时才更新而不是定时无条件 replace。5. 调试与源码验证从telnet到items.c把replace彻底看透文字说了一堆不如实际动手验证一次。这里给出一套完整的调试路径从外部协议到内部源码真正把 replace 的运行机制从外到内看透。5.1 telnet直连Memcached实操Memcached 默认端口是 11211文本协议可以直接通过 telnet 调试Windows 上记得先在“启用或关闭 Windows 功能”里打开 Telnet 客户端。连上之后先确认服务正常telnet 127.0.0.1 11211 stats看到STAT pid、STAT uptime说明服务正常。然后模拟一次完整的 replace 流程# 先塞一个 key set greeting 0 0 6 hello STORED # 用 replace 更新 replace greeting 0 0 6 world STORED # 用 get 验证 get greeting VALUE greeting 0 6 world END # 对不存在的 key 执行 replace replace not_exist_key 0 0 2 hi NOT_STORED这里有个细节get greeting返回的第二行VALUE greeting 0 6中的0就是当时的 flags最后面的6是字节数。如果之前用set时 flags 写的 1get 时这里就会显示 1客户端拿到这个值才能正确反序列化。如果系统里没装 telnet也可以配合 bash 自带的/dev/tcp来做快速验证exec 3/dev/tcp/127.0.0.1/11211 printf replace dev_tcp_test 0 0 3\r\nbar\r\n 3 head -n 1 35.2 源码层面确认replace的“存在”判定Memcached 的源码结构不算复杂关键函数在items.c的do_store_item和proto/text.c老版本在memcached.c里的process_update_command。文本协议收到replace时命令解析后会把操作类型标记为NREAD_REPLACE。核心逻辑大体是先对 key 执行一次内部查找如果 key 为空且操作类型是 replace直接返回NOT_STORED不会进入真正的存储流程。只有 key 存在才会走item_replace或者类似的覆盖逻辑。为什么要讲这个因为“key 存在”的判定并不等于“内存里有一个没过期的 item”。Memcached 的 item 带有过期时间查找时会做一次过期检查如果发现已经过期会先执行惰性删除再返回空。所以你今天通过 telnet 手敲replace一个“你记得存在但已经过期”的 key返回的一定是NOT_STORED。理解了这一点你再看前面讲到的 LRU 淘汰场景就会明白 replace 的“存在”前提比我们想象得更脆弱也更需要配合 add/set 回退策略。5.3 stats是验证replace行为的好帮手调试完命令后建议用stats命令观察 Memcached 的内部统计指标重点看这几个指标意义get_hits / get_missesget 的命中与未命中情况delete_misses删除操作没有命中 key 的次数curr_items当前存储的 item 数量total_items累计存储的 item 数量expired_unfetched已过期但尚未被外部 get 读取到的 item 数量一个典型的验证思路先stats记录curr_items和total_items然后对同一个 key 多次执行 set你会发现curr_items不变但total_items增加而对同一个 key 多次执行 replacecurr_items不变但total_items也不一定增加视版本而定。这个差异可以帮你确认你操作的是“创建”还是“替换”尤其适合写脚本自动化验证大批量缓存操作时检查是否发生意外的新增。6. 工程实践习惯set、replace、add、cas该怎么选最后聊聊我在实际编码中一直遵守的选择逻辑。Memcached 这几个写命令可以简单梳理成四种语义命令语义适用场景setupsert存在则覆盖不存在则创建普通缓存写入可以无脑覆盖add仅在不存在时创建缓存预热、分布式锁占位、避免并发重复初始化replace仅在存在时替换只更新已存在的 key不创建新 keycas带版本校验的更新并发场景下的强一致性更新6.1 什么时候用replace我一般在这种场景下优先选择 replace更新一个已经确认存在且应该由本次写操作独占的缓存对象做缓存续期比如活跃用户 session、在线状态实现“只更新不新增”的业务约束比如状态机流转缓存里没有状态就不能生成新状态多服务之间对某个 key 的“存在性”有依赖希望写操作在 key 被淘汰/过期时显式失败而不是默默创建。用 replace 最大的价值不是性能性能上和 set 没有本质差别它的价值在于失败可见。NOT_STORED是一个明确的信号它告诉你“这个 key 不在了”你可以据此触发回源加载、重建缓存、或者告警。而 set 的静默创建会把这些问题掩盖掉。6.2 什么时候用cas如果你发现“两个服务同时更新同一个 key谁后写谁赢”是不可接受的那 cas 才是答案。cas 需要搭配 gets 使用流程是value, cas_token mc.gets(product:1001:stock) new_value value - 1 result mc.cas(product:1001:stock, new_value, cas_token) if not result: # 版本冲突重读重试 ...cas 的重试逻辑要控制好次数否则高并发下可能一直冲突。实际经验是重试 3 次以内超过就直接返回失败或者走降级方案不要在 cas 重试上消耗太多时间。6.3 生产环境代码示例下面是一段我比较推荐的缓存初始化加更新“模板”把 add replace cas 都串起来了import memcache mc memcache.Client([127.0.0.1:11211], socket_timeout2) CACHE_KEY product:1001:stock def init_cache(value: int) - bool: 只有不存在的 key 才初始化避免并发重复写 return bool(mc.add(CACHE_KEY, value, time3600)) def update_cache(value: int) - bool: 只更新已存在的 key失败时返回 False 由调用方处理 return bool(mc.replace(CACHE_KEY, value, time3600)) def update_with_retry(value: int, max_retry: int 3) - bool: 并发安全更新使用 gets/cas for _ in range(max_retry): _, cas_token mc.gets(CACHE_KEY) if cas_token is None: # key 不存在先初始化 if not init_cache(value): continue return True if mc.cas(CACHE_KEY, value, cas_token, time3600): return True return False这套模板把缓存的生命周期划分得很清晰初始化走 add普通更新走 replace高并发更新走 cas。调用方不需要在业务代码里频繁判断 key 是否存在成功和失败都由返回值明确表达出了问题日志也容易定位。6.4 最后的补充建议我在实际运维中发现很多 Memcached 分配的异常都源于对 flags 和 bytes 的忽视。如果你用的是字符串类型一定要确认客户端在 get 时是否拿到了正确的 flags如果你自己写协议解析器一定要对 bytes 做异校验防止数据错位。另外线上环境建议开启-o modern或按需调优 LRU 相关参数避免热点 key 过早被淘汰减少 replace 失败率。回头看那场商品状态被覆盖的事故其实只要当初写代码的同学把“更新缓存”从 set 换成 replace并且做好 NOT_STORED 的回退处理问题根本不会发生。缓存命令虽小选错了就是线上事故选对了就是让系统少一个隐患。希望这篇能帮你把 replace 这个命令用得明明白白以后遇到“只更新已存在的 key”这种需求第一反应不再是无脑 set。
