Redis XACK/PEL 到底怎么收口：消费组 ACK、pending 与重试边界

很多线上事故里，消息没“丢”，而是“卡在 pending”被重复消费。用 Redis Stream 时，消费组里的 ACK 不只是一个语义操作，它决定了消息从未确认队列里能否安全下线。很多实现里正是因为误把 ACK 当“删队列”来理解，导致重放风控和重复补偿失控。

消费端只要拿到同一条消息，只要最后没有成功清理 PEL 与消费组状态，消息就还没完成流转；确认边界比代码重试策略更关键。

模式定位：ACK 与“删除”不是一回事

先建立一个边界。XREADGROUP GROUP g c COUNT 1 BLOCK 2000 STREAMS events > 这类消费命令把消息派发给消费者，消息会进入该消费者所属组的 pending 状态。真正从消费组完成语义上“确认”的是 XACK stream g id1 id2 ...。

XGROUP CREATE events workers $ MKSTREAM
XADD events * action order.create order_id 99001
XREADGROUP GROUP workers w1 COUNT 1 STREAMS events >
# 假设拿到 id 为 1735000000-0
XACK events workers 1735000000-0
XPENDING events workers - + 10

这里最容易出问题的是把 XACK 当成“删消息”而不是“状态切换”。实际上，消息历史仍在 Stream 中，只是消费组内确认状态变化。生产者要保留日志、回放、审计时，这一点非常正常；要做幂等保护时也是这条线的基础。

PEl 与重试窗口：不看 PEL 就像没看 pending queue

一个未被 ACK 的 ID 通常会在 PEL 里可见，尤其在消费者异常退出、阻塞或超时后。用如下命令可以看清是否真被卡住：

XPENDING events workers - + 20
XPENDING events workers 1735000000-0 1735000000-0 1
XCLAIM events workers w2 30000 1735000000-0

XPENDING 给出未确认数量、最小/最大 idle、consumer 分布和每条消息交付次数。只看未确认总数，会漏掉“某个消费者长期不提交但总量不大”的问题。线上修复时应按空闲时长与交付次数两根轴判断：是单点抖动，还是消费链路停摆。

常见误区与上线前检查

误区一：以为 ACK=删除。实际需要同时确认业务 side-effect 与 ACK。业务落库失败但先 ACK，会产生“消费完成但未处理”。误区二：只看一个消费者。消费者重启后，消息会转移到另一个客户端；只看单实例日志会误判失败率。

• 消费者退出前要确保本次处理与提交一致，必要时把状态写入同一事务边界。
• 定期运行 XPENDING 与 XINFO CONSUMERS，监控 idle 上线。
• 对重复投递场景，所有写库动作按幂等键保护，防止 ACK 成功后再次投递导致重复扣减。
• 重试不应无限进行：设置可恢复上限与回退队列，超过上限转入人工或补偿工位。

相关问题

是不是所有消息都必须 ACK？

只要通过消费组读取的消息都应在业务成功提交后 ACK；未成功提交可保留在 PEL，避免被盲目吞掉。

ACK 不掉但业务成功了怎么办？

先按 ID 回放验证幂等状态；若确认为幂等成功且已写入补偿记录，可在安全窗口后手工清理或重新设计处理策略。

能否用 XPENDING 定位“长期空转”问题？

可以。持续增大的 idle 与高消费次数通常说明消费者实例/分组内存在积压，需要结合日志和消费者健康一起排查。

小结

Redis Stream 的消费组确认不是简单“删消息”，而是由 pending、delivery count、ack 与业务幂等共同组成的边界系统。能否稳定投递，不取决于你有没有写 XACK，而在于是否把“未确认状态”和业务副作用放在同一条闭环里监控。