XACK 怎样清理待处理消息

Redis Streams 的 XACK key group id [id ...] 用于确认已经完成处理的消息，把这些 ID 从指定消费组的待处理列表 PEL 中移除。它不会删除流里的消息正文，也不会替其他消费组确认。清理 pending 的正确时机是业务处理成功之后，而不是刚收到消息时。

官方地址：https://redis.io/docs/latest/commands/xack/。下文采用独立订单消费场景，按操作任务、对象关系、状态反馈、重试与边界展开。命令是未在本机执行的示例，预期状态说明不代表实测结果。

最小用法：确认处理成功的消息 ID

# 示例 ID 必须替换成业务已完成处理的实际消息 ID。
redis-cli XACK demo:ack:orders billing-workers 1-0

# 查看同一个流和消费组的待处理摘要。
redis-cli XPENDING demo:ack:orders billing-workers

三个关键参数分别是流键、消费组名称和消息 ID。XACK 不接收消费者名称，确认范围由流键与组名共同限定。传入 ID 必须来自这个组已经投递的消息，不能把订单号字段当作 Redis 的流 ID。

返回整数表示本次真正从 PEL 移除的条目数量。单条确认返回 1，才表示这次移除了一个待确认记录；返回 0 可能是已经确认、ID 不在该组 PEL 等情况。返回 0 本身不等于 Redis 执行错误，更不能说明订单是否成功处理。

拆开流数据、消费组和待处理记录

流条目保存 ID 和消息字段；消费组管理自己的投递与确认信息；PEL 保存已投递但尚未确认的记录及其消费者归属。它不是一份独立复制的完整消息队列。消费者通过 XREADGROUP 读取新消息且没有使用 NOACK 时，消息通常会进入该组 PEL。

因此“确认”“删除正文”“删除消费组”是不同操作。不要为了让 pending 数字变小而删除流或重建组，这会改变消费语义。业务目标应是确认已经完成的工作，让未完成工作仍能被定位和恢复。

在独立示例中观察确认前后状态

# 仅在独立测试实例及全新键上执行，创建演示消费组。
redis-cli XGROUP CREATE demo:ack:orders billing-workers 0 MKSTREAM

# 固定 ID 只为方便讲解；生产消息通常使用自动生成 ID。
redis-cli XADD demo:ack:orders 1-0 order_id sample-101 task invoice

# 引号保护大于号，避免被 shell 当作文件重定向。
redis-cli XREADGROUP GROUP billing-workers worker-a COUNT 1 STREAMS demo:ack:orders '>'

# 查看待处理摘要和最多十条明细。
redis-cli XPENDING demo:ack:orders billing-workers
redis-cli XPENDING demo:ack:orders billing-workers - + 10

上述命令要求键全新、消费组尚不存在。若出现 BUSYGROUP，不应把错误当成功忽略后继续套用预期状态；它说明环境已存在，需要使用独立示例键重新准备。固定 1-0 是演示消息 ID，已有流的最大 ID 若不小于它，XADD 会拒绝写入。

读到演示消息后，XPENDING 摘要应能显示它的待处理信息；明细可帮助核对 ID、消费者、空闲时间与投递次数。下面的确认命令应放在业务处理已经成功的位置；演示中没有替用户执行开票、写数据库等业务。

# 完成演示业务处理后再确认；实际应用须先保证业务成功持久化。
redis-cli XACK demo:ack:orders billing-workers 1-0

# 用待处理摘要观察确认状态，流条目仍可单独读取。
redis-cli XPENDING demo:ack:orders billing-workers
redis-cli XRANGE demo:ack:orders 1-0 1-0

# 重复确认同一 ID 用于说明返回计数，不会重新执行订单业务。
redis-cli XACK demo:ack:orders billing-workers 1-0

在没有其他并发消费者和写入的独立示例中，首次确认该消息预期返回 1，重复确认预期返回 0；确认后的 XRANGE 仍可以看到流正文。这组状态说明帮助区分“PEL 清理成功”与“流空间回收”，后者需要另外设计保留策略。

让失败、重试与重复确认有明确反馈

应用应把“业务失败”“业务成功但确认超时”“确认返回零”“消费组不存在”分别呈现给运维人员。监控文字最好同时包含流键、组名和消息 ID，避免只有一个无上下文的红色状态。日志不要输出订单里的敏感字段。

业务失败时保留 pending，按业务重试策略恢复；业务已经持久化但 XACK 响应超时时，客户端无法只凭网络超时确定服务端是否完成确认。确认可以针对同一 ID 再次尝试，但业务副作用也必须具备独立的幂等控制。XACK 不能让“写业务数据库”和“确认 Redis 消息”自动成为跨系统原子事务。

# 读取 worker-a 自己尚未确认的历史记录，0 表示从其待处理列表开头读。
redis-cli XREADGROUP GROUP billing-workers worker-a COUNT 10 STREAMS demo:ack:orders 0

# Redis 6.2+：worker-b 认领空闲至少 60000 毫秒的记录，仅作恢复示例。
redis-cli XAUTOCLAIM demo:ack:orders billing-workers worker-b 60000 0-0 COUNT 10

读取本消费者的历史 pending 与接管其他消费者的超时消息，是不同恢复任务。XAUTOCLAIM 会改变消息归属，不等于业务处理完成，也不能认领后立即批量确认。实际应用需要按返回游标继续扫描，处理成功后才确认对应 ID；示例的 60 秒只是参数说明，应按业务最长正常处理时间调整。

控制批量大小并处理异常边界

XACK 可以一次携带多个 ID，适合确认一批已经成功的工作。应设置合理批次上限，避免一次发送巨大命令；批量返回的是移除总数，不提供每个 ID 的逐项状态。只收集成功消息的 ID，不能因为同一批有一条成功，就把整批未完成的消息一起确认。

使用 NOACK 就不用清 pending 了吗？

它会让读取的新消息不进入 PEL，但这相当于放弃该确认追踪机制。需要失败恢复的业务不能只为消除积压数字而启用 NOACK。

一个组确认后，另一个组也完成了吗？

不会。不同消费组独立管理确认状态，必须分别按各自业务处理结果确认。

XACK 能自动找出所有超时消息吗？

不能，它只处理明确传入的 ID。查找、认领、重试和成功确认需要由应用组合完成，并保留错误及重试上限。

参考资料：XACK https://redis.io/docs/latest/commands/xack/；消费组读取 https://redis.io/docs/latest/commands/xreadgroup/；超时认领 https://redis.io/docs/latest/commands/xautoclaim/。