Redis 8.8 Streams NACK 如何影响失败消息转交

Redis Streams 里，消费者拿到消息后如果既不能确认成功，又不想让它在 PEL 中等到空闲超时，Redis 8.8 新增的 XNACK 就是针对这个缺口的处理方式。它不会删除 Stream 消息，而是把 pending entry 释放为“可立即转交”，并通过 SILENT、FAIL、FATAL 区分失败责任。

一句话理解：XACK 表示处理成功并移出 PEL，XNACK 表示处理失败但保留消息，让同组其他消费者尽快重新领取。

XNACK 改变的是 PEL 里的归属，不是删除消息

旧流程里，消费者失败后通常只能留下消息，再由其他消费者通过 XPENDING 配合 XCLAIM，或直接使用 XAUTOCLAIM，等消息达到空闲时间后接管。Redis 8.8 的 XNACK 把“我现在处理不了，请交给别人”变成了显式动作，减少了等待空闲阈值的延迟。

最小语法如下。IDS 后的数字是消息 ID 数量，命令返回实际释放回消费组 PEL 的消息数。

#!/usr/bin/env bash
# 将当前消费者无法处理的 pending message 立即释放给同组消费者
redis-cli XNACK orders order-workers FAIL IDS 1 1710000000000-0

# 成功处理后仍使用 XACK；它会从 PEL 移除消息
redis-cli XACK orders order-workers 1710000000000-0

三种模式决定重试计数怎么走

模式选择的关键不是“哪一个更强”，而是这次失败是否应该算作一次有效投递。内部故障或优雅停机一般选 SILENT；当前消费者资源不足、换一个消费者可能成功时选 FAIL；内容损坏、疑似毒消息或恶意输入则选 FATAL，方便后续按最大投递计数识别并进入死信处理。

不要把 FATAL 当成 Redis 自动创建死信队列。它只是写入一个明确的失败信号，死信转存、告警和人工修复仍要由业务消费者实现。

失败消息如何优先交给其他消费者

执行成功后，消息会被标记为无归属，最后投递时间设为 0，并放到 PEL 头部的 NACKed 区域；同一区域内保持 FIFO，之后才是既未 ACK 也未 NACK 的普通 pending 消息。因此它会优先于等待空闲时间的旧消息。

这个优先级只有在接管语义下生效。没有 CLAIM 的 XREADGROUP 仍只读取从未投递的新消息；恢复消费者应明确使用 CLAIM 路径，并保留 XPENDING 作为观察入口。

#!/usr/bin/env bash
# 仅查看消费组 pending 概况，不把输出当成业务成功证明
redis-cli XPENDING orders order-workers

# 读取并接管可领取的 pending message；先处理 XNACKed 区域
redis-cli XREADGROUP GROUP order-workers worker-b COUNT 10 CLAIM 0 STREAMS orders >

上线前先确认版本和托管形态

XNACK 的官方命令文档标注为 Redis Open Source 8.8.0 新增。升级后可以先确认服务端版本，再在灰度消费组中测试返回数、PEL 数量和业务幂等性：

#!/usr/bin/env bash
# 先确认连接到的服务端版本，避免客户端升级但服务端仍旧版本
redis-cli INFO server | awk -F: '/^redis_version:/{print $2}'

# 目标环境确认支持后，再用一条已知 pending ID 做灰度验证
redis-cli XNACK orders order-workers SILENT IDS 1 1710000000000-0

官方资料入口：https://redis.io/docs/latest/commands/xnack/。当前 XNACK 命令页的兼容性表对 Redis Software 与 Redis Cloud 标为不兼容，所以云上或商业发行版不能只看“Redis 8.8”字样，应以目标环境的命令支持矩阵和灰度结果为准。无论选择哪种模式，业务处理都仍需幂等，XNACK 解决的是转交时机和重试语义，不是重复消费的消除。

常见问题

XNACK 会把消息从 Stream 删除吗？

不会。它保留 Stream entry 和 PEL 引用，只解除当前消费者归属；成功处理仍应调用 XACK。

XNACK 后为什么普通 XREADGROUP 读不到消息？

因为普通读取仍面向从未投递的新消息。要恢复 pending 消息，需要走带 CLAIM 的读取或使用 XCLAIM、XAUTOCLAIM。

所有失败都应该用 FAIL 吗？

不应该。停机或消费者自身故障用 SILENT 更能避免无意义地增加投递次数；确认消息本身不可处理时才用 FATAL，并由业务侧负责死信流程。