Redis XREADGROUP 使用 NOACK 时为什么看不到 Pending 记录

Redis XREADGROUP 使用 NOACK 后，读取到的新消息不会进入 Pending Entries List（PEL），所以再用 XPENDING 查询时看不到这些新增记录。这不是消费组失效，而是 NOACK 把消息视为“读取时立即确认”，主动放弃了 PEL 中的责任追踪。

官方地址：https://redis.io/docs/latest/commands/xreadgroup/

如果消息处理失败后必须重试、需要知道消息由哪个消费者接手，保留默认确认流程；只有在消息允许偶尔丢失、只关心尽快读取而不需要 Pending 状态时，才考虑 NOACK。

先分清 XREADGROUP 读取的两类消息

XREADGROUP 是带消费者组语义的 Stream 读取命令。它至少需要消费组、消费者名称和 Stream 读取位置：

# 读取消费组还没有投递给任何消费者的新消息
XREADGROUP GROUP orders worker-a COUNT 10 STREAMS orders >

# 读取 worker-a 自己已经收到但还没有确认的消息
XREADGROUP GROUP orders worker-a COUNT 10 STREAMS orders 0

这里的 > 表示只取从未投递给其他消费者的新消息；使用具体 ID（例如 0）则是访问当前消费者自己的待处理记录。两条命令都叫 XREADGROUP，但它们查看的消息集合不同。

默认模式为什么能在 XPENDING 中看到记录

不写 NOACK 时，Redis 会把通过新消息路径读到的消息记录到消费组的 PEL。PEL 记录的是“已经投递，但还没有被确认”的消息 ID、所属消费者、空闲时间和投递次数等状态。

因此，默认流程通常是：

# 先读取新消息，Redis 会把消息放入当前消费组的 PEL
XREADGROUP GROUP orders worker-a COUNT 10 STREAMS orders >

# 业务处理成功后再确认，确认会移除对应的 PEL 记录
XACK orders orders-id-123

# 查询当前消费组仍然未确认的消息摘要
XPENDING orders orders

XPENDING 看到的是消费组的待确认状态，不是 Stream 中仍然存在多少条消息。即使消息本体还在 Stream 中，只要已经被 XACK 确认，它就不会继续出现在该消费组的 PEL 摘要里。

这也是默认模式适合可靠消费的原因：应用可以先处理，再确认；如果消费者在确认前退出，其他排障或接管流程仍能根据 PEL 找到这条消息。

NOACK 为什么让新增 Pending 记录消失

NOACK 的语义不是“稍后自动帮你确认”，而是读取时就不把消息加入 PEL。Redis 官方命令说明把它定义为不添加到 PEL，并把消息视为已经确认。

# NOACK 直接读取新消息，不创建对应的 PEL 记录
XREADGROUP GROUP orders worker-a COUNT 10 NOACK STREAMS orders >

# 这里查不到刚才 NOACK 读取消息带来的新增 PEL
XPENDING orders orders

因此，下面这个推断是不成立的：

“XREADGROUP 已经返回消息，但 XPENDING 没有记录，所以 Redis 丢了消息。”

更准确的解释是：消息已经返回给消费者，但 NOACK 选择不建立 Pending 状态。没有 PEL，就没有可供 XPENDING 查询的消费者责任记录，也不需要再用 XACK 删除这条记录。

不要把新消息读取和 Pending 消息读取混在一起

排查时最容易混淆的是：NOACK 影响的是它读取到的消息是否进入 PEL，而不是把已有 PEL 记录从历史中批量删除。

当读取位置不是 > 时，命令访问的是当前消费者已经收到但尚未确认的消息。官方说明中，使用具体 ID 读取自己的 Pending 条目时，BLOCK、NOACK 和 CLAIM 都会被忽略。也就是说，不能靠给历史 PEL 查询加上 NOACK 来改变已经存在的待处理状态。

# 读取 worker-a 自己的待处理消息；这里的 NOACK 不会改变历史 PEL
XREADGROUP GROUP orders worker-a COUNT 10 STREAMS orders 0

# 查看待处理摘要，确认是否仍有未确认消息
XPENDING orders orders

可以用下面的判断表快速定位：

哪些场景适合使用 NOACK

选择 NOACK 前，先问一个具体问题：消费者进程在“收到消息”和“完成业务处理”之间退出时，这条消息是否允许不再被追踪。

• 可以考虑 NOACK：消息是刷新提示、临时统计、可由后续快照重新计算的通知，偶尔少一条不会破坏业务结果。
• 不建议 NOACK：消息代表扣款、库存变化、订单状态或必须补偿的任务，需要知道谁处理过、是否成功以及失败后如何重试。
• 需要谨慎：消息本身看似低价值，但下游操作不可逆时，不能只因为想让 PEL 变小就使用 NOACK。

默认模式的成本是维护 PEL，并要求业务在处理成功后调用 XACK；NOACK 的收益是减少待处理状态和确认动作，代价是失去这条消息的消费组级责任记录。两者不是性能开关，而是可靠性模型的选择。

用三个问题快速判断配置是否正确

1. 读取位置是不是 >？如果是，它通常代表新消息路径；如果是具体 ID，应该按当前消费者的 Pending 路径排查。
2. 命令里是否带了 NOACK？带了就不要期待这些新消息出现在 PEL 或 XPENDING 结果里。
3. 业务是否需要失败重试？需要就保留默认确认流程，把处理成功和 XACK 放在清晰的业务边界上。

总结一下：XPENDING 只能观察进入 PEL 的待确认消息；XREADGROUP ... NOACK 读取新消息时跳过 PEL，所以看不到新增 Pending 记录是预期行为。若消息必须可追踪、可重试或可接管，就不要为了省掉一次确认而使用 NOACK。

相关问题

NOACK 之后还需要调用 XACK 吗？

对 NOACK 读取的新消息，不需要再调用 XACK，因为它没有进入该消费组的 PEL。对已经存在的 Pending 消息，则仍应按业务处理结果决定是否确认。

为什么 Stream 里还有消息，但 XPENDING 是空的？

Stream 保存消息本体，PEL 保存消费组的未确认状态。消息仍在 Stream 中，并不代表它一定属于当前消费组的 Pending 集合；NOACK 读取或已经 XACK 都可能让 XPENDING 不再显示它。

NOACK 能不能防止消息重复处理？

NOACK 只是不建立 PEL，不是通用的幂等或去重机制。是否重复处理还取决于读取位置、消费者重启、业务写入和下游操作的幂等设计。