Redis Streams NACK 释放待处理消息的消费策略

Redis Streams 里常说的“NACK”并不是一个独立命令。更准确的做法是：消费者读取消息后暂时不执行 XACK，让消息留在消费组的 Pending Entries List（PEL）中；当原消费者失联或处理超时，再用 XAUTOCLAIM 把它转给恢复消费者，成功处理后执行 XACK。这样既不会把失败消息误标记为成功，也不会让 pending 消息永远卡在旧消费者名下。

官方地址：https://redis.io/docs/latest/develop/data-types/streams/

先把 NACK 对应到 Redis Streams 的真实状态

消费组通过 XREADGROUP 读取消息时，Redis 会把消息交给某个 consumer，并在该组的 PEL 中留下记录。只有业务完成后调用 XACK，这条记录才会从该组的 PEL 移除。因此，应用里的 NACK 更像一种处理结果：当前消费者不能确认这条消息，后续需要重试或转交，而不是调用一个名为 NACK 的 Redis 命令。

先用下面的命令观察现场。示例中的 orders 是 Stream，order-workers 是消费组。

# 查看消费组 pending 总数、最早和最晚消息
redis-cli XPENDING orders order-workers

# 查看明细：消息 ID、消费者、空闲毫秒数、投递次数
redis-cli XPENDING orders order-workers - + 20

重点看三列：空闲时间持续增长，通常说明原消费者没有继续处理；投递次数增加，说明消息正在反复失败；pending 总数长期不降，则要检查消费逻辑、连接和确认时机。

用 XAUTOCLAIM 接管真正超时的 pending 消息

不要看到 pending 就立即抢走。正常处理中的消息也会短暂存在 PEL，接管条件应至少包含“空闲超过阈值”。Redis 6.2 及以上可以用 XAUTOCLAIM 扫描 PEL，把满足条件的消息转给恢复消费者：

# 从 0-0 开始扫描，接管空闲超过 60 秒的少量消息
redis-cli XAUTOCLAIM orders order-workers repair-1 60000 0-0 COUNT 20

# 业务处理成功后再确认，避免接管成功却提前丢失记录
redis-cli XACK orders order-workers 1710000000000-0

COUNT 不宜一开始就设得很大，否则恢复消费者可能瞬间压垮下游。返回的下一个游标要保存并继续扫描；如果需要处理被删除但仍残留在 PEL 的消息，也要记录返回的删除 ID。对于可能重复投递的订单、扣库存或通知任务，业务层必须用消息 ID、业务单号或幂等表做去重。

把失败消息分成重试、转移和终止三条路径

一次处理失败不应直接把消息从 PEL 删除。更稳妥的策略是先读取投递次数和业务错误类型，再作分流。

这里的“确认”只表示原消费组不再继续追踪这条消息，不代表业务一定成功。死信记录至少带上原始 ID、错误分类、最后消费者和投递次数，后续人工修复后可以用独立流程重新投递。若多个消费组共同使用同一 Stream，某个组的 XACK 不会替其他组确认，不能把一个组的 PEL 当成全局状态。

常见问题

只调用 XACK 能不能当作 NACK？

不建议。XACK 会把消息从当前组的 PEL 移除，适合已经完成或已转入可追踪死信的消息；失败但未留痕就确认，会造成不可恢复的丢失。

XAUTOCLAIM 的空闲阈值应该设多久？

至少要高于正常处理的长尾耗时，再结合消费者心跳和下游超时设置。阈值太短会造成多个消费者重复接管，阈值太长则会延迟故障恢复。

为什么 pending 数量下降了，业务仍可能重复？

接管改变的是消息所有权，不能消除已经发生的投递。消费者崩溃可能发生在业务提交之后、XACK 之前，所以最终仍需幂等处理。

把 NACK 理解成“暂不确认并等待恢复策略”，Redis Streams 的职责边界就清楚了：XPENDING 找出现场，XAUTOCLAIM 恢复所有权，业务幂等保证重复安全，XACK 或死信流程负责收口。