Redis 8.8 的 XNACK 对事件驱动应用恢复意味着什么

Redis Streams 的消费者组过去遇到处理失败，通常只有两条路：留下消息，让它继续停在 Pending Entries List（PEL）里等待空闲时间；或者由其他消费者用 XPENDING、XCLAIM、XAUTOCLAIM 接手。Redis 8.8 增加 XNACK 后，消费者可以明确告诉 Redis：“这条消息我现在不能完成，请把它释放出来。”

它真正带来的变化不是“失败自动重试”，而是把失败消息从当前消费者手中立即释放，并按失败性质保留不同的重试计数语义。幂等、重试上限和死信队列仍需由应用负责。

Redis 8.8 把 Stream 失败处理从“等一等”变成“明确释放”

官方把 XNACK 定义为 Redis Open Source 8.8.0 起可用的 Streams 命令，语法是 XNACK key group SILENT|FAIL|FATAL IDS numids id ...。它不会像 XACK 那样把消息从 PEL 删除，而是让消息继续被消费组跟踪，同时解除当前 owner，使其他消费者可以重新投递。

这对事件驱动应用的意义在于：恢复动作不必完全依赖“消息空闲了多久”。例如消费者准备退出时，能够把尚未处理完的消息主动交回；外部依赖短暂不可用时，也不必把消息留给超时扫描器。这是恢复延迟的改进，不是业务成功率的保证。

XNACK 先改变的是 PEL 里的恢复顺序

被释放的消息会进入 PEL 头部的 XNACKed 区域，最后消费者被清空、最后投递时间置为 0，并在 claim 时优先于没有被显式释放的 pending。于是，XREADGROUP 读取新消息的行为仍保持原样；只有带 claim 语义的恢复路径，才会优先看到这些待重投消息。

可以把它理解成“释放所有权”，而不是“重新生产一条消息”。消费者仍应使用消息 ID 做幂等键，避免原处理已经完成但确认丢失时产生副作用。

三种模式对应三类失败，而不是三个重试按钮

一个最小的命令侧闭环可以这样表达：

# 当前消费者处理失败，但消息属于当前消费者自身的瞬态问题
XNACK orders worker-group SILENT IDS 1 1710000000000-0

# 当前实例资源不足，让同组其他消费者立即尝试
XNACK orders worker-group FAIL IDS 1 1710000000001-0

# 识别为毒消息，后续由应用依据极大重试计数转入死信流程
XNACK orders worker-group FATAL IDS 1 1710000000002-0

命令只释放 PEL 中存在的 ID；它不会替应用判断消息是否真的有毒，也不会自动创建死信队列。生产代码要把异常分类、最大重试次数、死信写入和人工复核记录放在同一套策略里。

采用前先看恢复延迟和重复副作用

建议先在一个消费组灰度：记录从失败到再次被 claim 的延迟、PEL 中 XNACKed 消息数量、各模式的 delivery counter 分布，以及同一业务键的重复执行次数。若恢复延迟下降但重复副作用上升，问题通常不在 XNACK 本身，而在确认时机、幂等表或外部接口重试。

还要注意版本与部署边界：命令文档标明 XNACK 自 Redis Open Source 8.8.0 提供，Redis Software 与 Redis Cloud 的兼容性不能仅凭开源命令存在就推断。上线前应以目标发行版的命令支持矩阵和实际灰度结果为准。

相关问题

XNACK 和 XACK 有什么区别？

XACK 表示处理完成并从 PEL 移除；XNACK 表示处理未完成但释放当前所有权，消息仍由消费组跟踪并等待重新投递。

什么时候应该用 FATAL？

只有在消息本身无法通过换消费者解决时才用，例如结构损坏或确定的毒消息。普通网络超时不应直接标记为 FATAL。