Redis 8.4 DELEX 怎么做条件删除：IFEQ、摘要校验与并发安全

删除缓存里的旧配置时，最容易出问题的写法往往不是 DEL 本身，而是先把值读到客户端，再比较版本，最后发起删除。两个请求只要在这三步之间交错一次，刚写入的新配置就可能被误删。Redis 8.4 提供的 DELEX 把“按条件删除”放到服务端直接执行，很适合处理带版本号、租约值或者摘要校验的资源淘汰动作。

旧式 GET 加 DEL，为什么会删掉刚写入的新值

假设配置键 cfg:checkout 当前保存的是 v17，清理任务只想删掉自己读到的旧版本值。客户端开发经常会写成下面这样：

old = GET cfg:checkout
if old == "v17":
    DEL cfg:checkout

问题就出在比较和删除这两个动作的间隙里。清理任务读到 v17 之后，发布服务可能已经把键更新成了 v18；清理任务后续执行普通 DEL，删掉的就会是刚更新的新版本。用事务或者 Pipeline 能减少部分网络往返，但只要比较逻辑还放在客户端，删除条件就始终没法和当前服务端的键值做强绑定。

Redis 8.4 的 DELEX 把比较和删除逻辑塞在同一条服务端命令里执行。它不是带返回值的普通 DEL，而是把条件不满足也当成一种可直接校验的合法结果。

IFEQ 和 IFNE：按完整字符串值决定是否删除

最容易上手的就是直接做值比较。做发布回滚或者租约清理的时候，可以把版本号、请求令牌或者完整的配置快照作为判断条件：

SET cfg:checkout v17
DELEX cfg:checkout IFEQ v17
EXISTS cfg:checkout

SET cfg:checkout v18
DELEX cfg:checkout IFEQ v17
GET cfg:checkout

第一条 DELEX 命中条件，返回 1，对应的键之后就不存在了；第二条判断条件不满足，返回 0，v18 就会被保留下来。这里的“相等”是对Redis字符串值做完整字节比较，不会按照JSON字段、数字大小或者版本号语义做特殊转换。

IFNE 则把判断逻辑反过来：只有当前值不等于传入的给定值时才执行删除。它适合“只保留某个租约版本，其余旧值全部清理”的场景，但要特别注意键不存在时的语义表现；删除前要先用测试数据确认返回值和业务状态的对应关系，不能直接把返回0当成网络失败处理。

大字符串用 IFDEQ：先算摘要，再交给 Redis 比较

如果配置值体积很大，客户端为了做比较把整段内容全取回来传输开销很不划算。Redis 8.4 的 DIGEST 可以直接生成键值摘要，后续再由 DELEX IFDEQ 或者 IFDNE 做条件判断：

SET cfg:checkout '{"version":17,"rules":["coupon","stock"]}'
DIGEST cfg:checkout

DELEX cfg:checkout IFDEQ 

示例里的尖括号只是占位标记，实际写程序的时候要把 DIGEST 返回的摘要原样传入，不要自己把JSON文本截断之后当成摘要传进去。摘要相同只能表示比较对象通过了摘要校验，它不等于业务版本号，也不能用来判断“哪个版本更新”。业务日志里还是要记录版本字段或者请求号做溯源。

摘要比较的计算复杂度和字符串值的长度正相关，所以它解决的是条件删除的数据传输开销和并发窗口问题，不代表任意大的键都能零成本删除。大体积的配置还是要控制单键大小，同时观察删除操作执行时的延迟分布。

命令返回值怎么验收，别把“未删除”都当成故障

DELEX 的返回值首先回答的是“这次操作有没有成功删掉键”。返回1表示条件命中并完成删除；返回0表示键不存在或者条件没有命中。落到实际业务任务里，还要把条件未命中、键已消失和命令本身不支持这几种情况区分开。

• 返回 1：记录目标键和对应的条件类型，后续确认下游缓存重建动作有没有被正常触发。
• 返回 0：读取当前键状态或者版本日志，判断是新值已经写入、其他任务先执行了删除，还是键本来就不存在。
• UNKNOWN COMMAND：说明当前目标实例不是Redis 8.4及以上版本，走兼容路径之前必须重新评估竞态风险。
• WRONGTYPE：目标键不是字符串类型，不能继续按字符串条件删除，要先修正键的数据模型或者清理策略。

不能把“执行没有报错”当成唯一的成功判断标准。条件删除的核心价值就是允许程序安全拿到“保留当前值”的结果；要是把返回0误报成异常，反而会触发不必要的重试和重复清理。

上线前的兼容与并发检查

先确认每个连接实际落到的服务端

客户端库支持拼装新命令，不代表背后的Redis服务端支持这条命令。灰度期间要在应用实际使用的主节点连接上运行 COMMAND INFO DELEX，同时把结果和Redis版本、代理路由信息一起记录下来。如果连接池里混了旧版本节点，不能只在一台测试实例上确认就直接上线。

把并发测试写成可观察的两个版本

测试流程先写入 v17，让清理任务准备执行删除；之后立刻把键更新为 v18，最后发送针对 v17 的 DELEX IFEQ。预期结果是返回0且 v18 被正常保留。再测试没有更新操作介入的命中路径，预期返回1且键被正常删除。

兼容旧版本时不要假装仍有原子性

旧版本Redis可以继续用Lua或者带条件的事务方案实现同类的删除保护，但不能退化成客户端GET、比较、DEL三步操作，还对外宣称和新命令是等价实现。要是暂时没法升级服务端，要明确记录兼容分支的并发保证范围、脚本超时和回滚方式，等服务端支持 DELEX 之后再切换过去。

常见问题

DELEX 和 GETDEL 有什么区别？

GETDEL 无条件返回键值并删除字符串值；DELEX 只有满足值或者摘要条件才执行删除，适合防止旧任务误删新写入的值。

IFEQ 能比较 JSON 里的某个字段吗？

不能。它会比较整个字符串的全部内容。需要按单个字段做判断的时候，应该提前设计独立的版本键、摘要值，或者改用Lua脚本实现明确的字段级语义。

DELEX 返回 0 就是命令失败吗？

不一定。键不存在或者条件未命中都可能返回0，程序要结合当前键值、版本日志和任务状态判断要不要执行后续动作。

Redis 7.x 能直接使用 DELEX 吗？

不能默认支持。先用 COMMAND INFO DELEX 检查目标实例的能力；不支持的话就用经过充分测试的脚本或者事务兼容实现，同时保留明确的并发验收逻辑。

条件删除的关键不是把 DEL 换成一个新命令，而是让“我当时读到的预期值”成为服务端执行删除的前置条件。小体积值优先用 IFEQ，大值再考虑 DIGEST 配合 IFDEQ；不管走哪条路径，都要把返回1、返回0、键不存在和版本不支持这几种情况分别记日志，清理任务才不会靠重试碰运气。