Redis XDELEX 的 KEEPREF 和 DELREF 有什么区别

Redis Streams 删除消息时，真正要先判断的不是“这条 entry 要不要删”，而是消费组的 Pending Entries List（PEL）引用要不要一起清理。KEEPREF 只删除 Stream 中的 entry，默认仍保留各消费组的待处理引用；DELREF 则连这些引用一起删除。需要保留后续恢复、重试线索时选 KEEPREF；消息已经确认不再处理、希望清理全部痕迹时选 DELREF。

KEEPREF 和 DELREF 实际改动的是哪一层

Redis Stream entry 和消费组 PEL 是两层数据。消费者通过消费组读取后，消息 ID 会进入 PEL，直到被确认或被转移处理。删除 entry 并不会自动等价于删除 PEL 引用，这正是两个参数容易混淆的原因。

KEEPREF 的语义是“删消息体，留引用”。它适合仍要保留待处理线索的场景，例如消费者暂时故障、后续还要通过 ID 做恢复判断。DELREF 的语义是“删消息体，也删所有消费组引用”，即使 Stream 中已经找不到该 ID，仍可能清除残留的 dangling reference。

最小命令配方：只删 entry 还是连引用一起删

命令格式中的 IDS 后面先写 ID 数量，再写一个或多个 Stream entry ID。下面用同一批 ID 展示两种策略，注释说明的是选择理由，不代表文章包在本机执行过这些命令。

# KEEPREF：删除 Stream entry，但保留消费组 PEL 引用
redis-cli XDELEX orders KEEPREF IDS 2 1710000000000-0 1710000000001-0

# DELREF：删除 Stream entry，并清理所有消费组对这些 ID 的 PEL 引用
redis-cli XDELEX orders DELREF IDS 2 1710000000000-0 1710000000001-0

# 用 XPENDING 检查目标消费组仍有哪些待处理 ID
redis-cli XPENDING orders order-workers

如果服务端未显式写策略，按官方文档会采用 KEEPREF。不要把命令返回的 -1 当成“PEL 一定为空”：它首先表示给定 key 中不存在该 entry。返回 1 才表示该 ID 的 entry 被删除；2 主要用于 ACKED 策略下仍有引用、或没有消费组等未删除情况。

按业务目标选择删除策略

实际选择可以归结为一句话：消息还可能被恢复、补偿或追责，就先用 KEEPREF；已经过了保留期，并且业务确认不能再恢复时，才使用 DELREF。对于清理脚本，建议先记录待删除 ID，再执行命令，避免把可恢复窗口一次性抹掉。

用 XPENDING 和返回值做一次边界复核

复核时分两层看：第一层确认返回数组中目标 ID 是 1 还是 -1；第二层检查消费组 PEL。KEEPREF 下，Stream 中虽然查不到 entry，但 PEL 仍可能有对应待处理 ID，这种状态不能直接当作删除失败。DELREF 下，如果目标 ID 不再出现在 PEL，才符合“引用也清理”的预期。

如果目标消息已经由其他流程先删除，再用 DELREF 处理残留引用，官方语义仍允许它清理 dangling reference。生产清理建议按消费组范围记录 XPENDING 前后结果，并保留本次 ID 清单，便于区分“原本不存在”和“本次已删除”。

常见问题

XDELEX 不写 KEEPREF 或 DELREF 时默认是什么

默认是 KEEPREF。也就是删除 Stream entry，但保留消费组 PEL 中已有的引用。

DELREF 会不会只清理当前消费组

不会。DELREF 面向该 Stream 的所有消费组引用，不是只针对执行命令的客户端或某一个消费组。

为什么 XDELEX 返回 -1

通常表示给定 Stream key 中没有对应 ID；它不单独证明 PEL 中没有残留引用，仍应执行 XPENDING 复核。