Redis XNACK 如何快速交回 Pending 消息：消费者退出与重投优先级

Redis Streams 的消费者准备退出时，最怕的是手里还有一批 Pending 消息：直接断开会让它们继续挂在消费组里，其他消费者通常要等到空闲时间达到阈值后才能接管。Redis 8.8 提供的 XNACK 专门解决这个交回动作：消息仍留在 PEL 中，但会立刻变成可重新投递的状态。

XNACK 适合“消息还没处理完，但当前消费者不再适合继续持有”的场景；它不是确认成功的 XACK，也不是替其他消费者接管消息的 XAUTOCLAIM。

先划清 XNACK、XACK 与 XAUTOCLAIM 的职责

先看消息是否已经处理完成。处理成功就用 XACK；还没完成但当前消费者要退出、遇到资源压力或发现无法继续处理，可以用 XNACK；消息已经长时间空闲、需要由另一个消费者接管，则更接近 XAUTOCLAIM 或 XCLAIM。

这里有一个容易混淆的点：XNACK 不会把消息重新写入 Stream，也不会替你完成业务重试。它改变的是消费组 PEL 里的持有关系。图中的消费组边界表示这些命令都围绕同一个消费组工作，消息生命周期则表示消息记录、PEL 和重新投递之间的静态关系。

用 PEL 状态判断什么时候该交回消息

XNACK key group mode IDS numids id [id ...] 只处理已经存在于消费组 PEL 的消息 ID。成功交回后，消息会被标记为无 owner，最后投递时间变成 0，并排在 PEL 的 XNACK 区域前端，所以后续的重新投递不必等待原来的 idle-timeout。

这并不代表消息已经成功消费。实际排障时，先用 XPENDING 找到消息 ID、当前消费者和空闲信息，再决定是否交回。若 ID 根本不在该组的 PEL 中，XNACK 会忽略它，返回计数也不会把它算作成功。

图中的PEL 状态、交回标记和重投入口是判断依据：它们都属于消息恢复边界，不要把空闲为 0 误解成业务处理完毕。

把优雅退出接到 XNACK 调用

退出处理的关键不是“把所有 Pending 都清掉”，而是只交回当前消费者仍持有、且没有完成业务动作的那部分消息。应用需要保存消息 ID、Stream 名称和消费组名称，在退出钩子中批量调用 XNACK，再记录整数返回值。

# 伪代码：退出前交回当前消费者尚未完成的消息
pending_ids = list_unfinished_pending("orders", "workers", "consumer-a")
if pending_ids:
    result = redis.xnack("orders", "workers", "FAIL", pending_ids)
    log.info("xnack released=%s", result)

SILENT、FAIL 和 FATAL 是交回意图的标记，具体使用要和团队的失败分类保持一致。无论选择哪种模式，都不能在 XNACK 前先执行 XACK，否则消息已经从 PEL 移除，后续就没有可交回的对象。

优雅退出后，另一个消费者可通过 XREADGROUP 读取可重新投递的消息；也可以由 XAUTOCLAIM 处理仍保持空闲的其他消息。Redis 只负责让消息回到组内的可投递范围，业务层仍需用订单号、事件 ID 等字段做幂等。

用 XPENDING 和重投结果做回归检查

上线前至少覆盖三种情况：正常退出、资源不足、传入一个不在 PEL 中的消息 ID。检查顺序可以压缩成一张小清单：

• XNACK 返回值是否等于实际交回的 Pending 数量；
• XPENDING 中消息 owner 是否变为空、空闲状态是否符合重新投递条件；
• 重投后业务处理是否成功，最终是否由 XACK 完成确认；
• 重复投递时，幂等键是否能阻止重复扣款、重复发货等副作用。

如果返回 0，不要立即判定 Redis 异常。优先检查消息 ID 是否属于正确的 Stream、消费组和 PEL；如果返回数量正确但业务仍重复，问题通常在消费端幂等，而不是 XNACK 的交回语义。

常见问题

XNACK 会删除 Redis Stream 里的消息吗？

不会。它只改变消费组 PEL 中消息的持有状态，消息记录仍在 Stream 里，后续还要由消费者处理并用 XACK 确认。

XNACK 和 XAUTOCLAIM 能互相替代吗？

不能。XNACK 是当前持有者主动交回；XAUTOCLAIM 是其他消费者按空闲条件接管。一个解决退出路径，一个解决超时恢复。

XNACK 返回成功后还要做什么？

用 XPENDING 核对 PEL 状态，再观察消息是否被重新读取，最后用业务幂等和 XACK 结束这次处理。