Redis XACKDEL 怎么确认并删除已处理消息

要在消费成功后同时确认并删除 Redis Stream 消息，Redis 8.2 及以上可以直接使用 XACKDEL。它把原来的 XACK 与条件删除合并为一次原子操作；多消费组场景优先选择 ACKED，这样只有所有消费组都读过并确认的条目才会从 Stream 删除。

官方文档：https://redis.io/docs/latest/commands/xackdel/

XACKDEL 消息是什么

XACKDEL 是 Redis Open Source 8.2 新增的 Streams 命令，语法如下：

# IDS 后先写 ID 数量，再依次写消息 ID
XACKDEL key group [KEEPREF | DELREF | ACKED] IDS numids id [id ...]

命令先针对指定消费组确认这些 ID，再按所选策略尝试删除对应 Stream 条目。它对每个 ID 的处理复杂度为 O(1)，但批量传入多少个 ID，就会返回多少个状态值，因此业务代码必须按位置逐项解释，不能只看数组中的第一个值。

XACKDEL 把确认与条件删除合成一个原子命令

传统写法通常是先执行 XACK，再由应用判断能否执行 XDEL。两条命令之间存在额外的协调窗口，而且在多个消费组共享同一条 Stream 时，应用还要判断其他组是否已经处理完成。XACKDEL 把“确认当前组”和“按策略删除条目”交给 Redis 在一次命令中处理。

注意，确认和删除不是同一个概念。确认会把当前消息从指定消费组的 PEL 中移除；删除则决定原始 Stream 条目是否继续存在。采用不同引用策略时，其他消费组的 PEL 引用可能保留、清除，或成为阻止删除的条件。

快速试用：用 ACKED 安全处理多消费组

下面用两个消费组说明最常见的判断方式。订单消息先被两个组读取，只有两个组都确认后，原始条目才适合删除。

# 创建一条测试消息，并记住返回的消息 ID
msg_id=$(redis-cli --raw XADD orders:events '*' order_id 1001 status paid)

# 从头创建两个独立消费组
redis-cli XGROUP CREATE orders:events billing 0
redis-cli XGROUP CREATE orders:events analytics 0

# 让两个组各自读取这条消息，使其进入各自的 PEL
redis-cli XREADGROUP GROUP billing worker-a COUNT 1 STREAMS orders:events '>'
redis-cli XREADGROUP GROUP analytics worker-b COUNT 1 STREAMS orders:events '>'

# billing 先确认：返回 2 表示已确认，但 analytics 尚未确认，条目暂不删除
redis-cli XACKDEL orders:events billing ACKED IDS 1 "$msg_id"

# analytics 再确认：所有消费组都完成后，返回 1 并删除 Stream 条目
redis-cli XACKDEL orders:events analytics ACKED IDS 1 "$msg_id"

这里的关键不是“第二次调用一定返回 1”，而是返回值必须结合当时的消费组引用状态理解。若条目此前已经不存在，结果会是 -1；若还有未确认引用，ACKED 返回 2，调用方应把它记录为“已确认、等待其他组”，而不是立即重试业务处理。

KEEPREF、DELREF、ACKED 应该怎么选

未显式指定策略时，默认使用 KEEPREF。三种策略的差异集中在“其他消费组引用怎么处理”和“什么时候允许删除原始条目”。

DELREF 还会清理已经不在 Stream 中、但仍残留于消费组 PEL 的悬空引用。这个行为适合明确的强制清理，却也意味着其他组失去继续追踪该消息的机会，不能仅因为“想省内存”就默认使用。

和旧方案 XACK + XDEL 的差别

如果生产环境仍是 Redis 8.0 或更早版本，不能直接发送 XACKDEL，否则会收到未知命令错误。升级前应保留原来的确认与删除逻辑；完成版本升级、客户端兼容检查和灰度验证后，再切换到新命令。

Worker 里怎样判断批量结果

一个批次可以携带多个 ID，IDS numids 中的 numids 必须等于后续 ID 数。返回数组与输入 ID 一一对应，推荐将结果分为“已删除”“等待其他组”“ID 不存在”三类。

# 一次确认并条件删除两个已完成处理的消息
redis-cli XACKDEL orders:events billing ACKED IDS 2 \
  1755870377536-0 1755870387045-0

# 返回示例 [1, 2] 的含义：
# 第一个 ID 已确认并删除；第二个 ID 已确认，但仍等待其他消费组

业务成功必须先于 XACKDEL。若数据库写入、外部 API 或本地状态更新尚未完成就提前调用，消息可能被确认甚至删除，后续故障恢复将失去可靠依据。反过来，命令调用超时也不要盲目重做业务副作用，应先依靠幂等键或业务状态判断这次处理是否已经生效。

采用风险与上线检查

• 版本：确认服务端至少为 Redis 8.2，并核对客户端是否已支持该命令；必要时可使用原生命令接口。
• 策略：多消费组默认考虑 ACKED；只有明确接受悬空引用时才选 KEEPREF，只有确认可清除全部组引用时才选 DELREF。
• 返回值：按 ID 逐项处理 1、2、-1，不要用“数组非空”判断整体成功。
• 业务顺序：先完成可幂等的业务处理，再调用 XACKDEL；为网络超时保留状态核对能力。
• 批量大小：按 Worker 的处理批次控制 ID 数量，避免单次请求过大导致响应数组和网络耗时膨胀。

常见问题

XACKDEL 不写策略时等同于什么？

默认是 KEEPREF：删除 Stream 条目，但保留其他消费组现有的 PEL 引用。

返回 2 需要立刻重试吗？

通常不需要。它表示当前组已经确认，但 ACKED 因仍有其他消费组未完成而没有删除条目；应等待其他组完成自己的处理。

DELREF 能清理已删除条目的悬空引用吗？

可以。即使 ID 已不在 Stream 中，DELREF 仍会尝试从所有消费组的 PEL 中移除对应引用。

能否在 Redis 7.x 使用 XACKDEL？

不能。XACKDEL 从 Redis 8.2.0 开始提供，旧版本需要继续使用 XACK、XDEL 及应用侧协调逻辑。