Redis XREADGROUP怎样读取消息但不写入 pending

我在给一条 Redis Stream 接入旁路统计时，最先遇到的不是消息读不出来，而是消费组的 pending 数量不断增长。这个场景只需要“读到就算处理过”，并不需要客户端崩溃后再恢复消息，继续使用普通的 XREADGROUP 就会让 PEL 留下一堆没有必要的记录。

如果你的任务允许偶尔丢失，可以在读取新消息时加上 NOACK。它会把本次读取视为已经确认，不把消息加入消费者组的 Pending Entries List（PEL）。但这不是更可靠的确认方式，而是主动放弃 pending 恢复能力。

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

想让 XREADGROUP 读取消息后不写入 pending，核心写法是 XREADGROUP GROUP group consumer COUNT n NOACK STREAMS stream >。只有在读取“从未投递的新消息”时，NOACK 才承担这个作用；读取具体 pending ID 时，它会被忽略。

普通 XREADGROUP 为什么会产生 pending

消费组使用 > 读取新消息时，Redis 会记住“哪一个 consumer 收到了哪一条消息”。这份投递记录进入 PEL，处理成功后由客户端发送 XACK 删除。这样做的价值是：客户端在处理过程中崩溃，其他消费者可以通过 pending 查询和认领流程继续接手。

# 普通读取：新消息进入当前消费者的 PEL，处理成功后再确认
redis-cli XREADGROUP GROUP workers consumer-a COUNT 2 STREAMS stream:orders '>'

# 业务处理成功后删除对应的 pending 记录
redis-cli XACK stream:orders workers 1710000000000-0

这里的 pending 不是“消息已经从 Stream 删除”，而是消费组维护的一份未确认投递清单。只要业务仍需要重试、超时转移或故障恢复，普通的 XREADGROUP + XACK 就是更合适的模型。

用 NOACK 读取不需要恢复的消息

NOACK 的含义很直接：读到的消息不加入 PEL，可以把它理解成“读取时立即视为确认”。它适合日志观察、指标旁路、临时通知这类任务：主业务已经把可靠投递交给其他链路，当前消费者只想顺手读取一份数据。

# NOACK 只对新消息读取生效；消息不会进入消费组 PEL
redis-cli XREADGROUP GROUP metrics consumer-a COUNT 10 NOACK STREAMS stream:orders '>'

使用它时要接受一个明确代价：如果客户端拿到消息后马上崩溃，Redis 不会因为 PEL 中没有记录而帮你找回这条消息。也就是说，NOACK 解决的是 pending 膨胀和无意义确认开销，不是处理失败重试。

区分 >、具体 ID 与 BLOCK 的边界

很多“NOACK 不生效”的问题，其实是读取 ID 用错了。STREAMS 后面的 > 表示“只要从未投递给其他消费者的新消息”；而 0 或其他具体 ID 表示访问当前消费者自己的 pending 历史，返回 ID 大于给定值的待处理记录。

# 读取从未投递的新消息：NOACK 可以跳过 PEL
redis-cli XREADGROUP GROUP workers consumer-a NOACK STREAMS stream:orders '>'

# 读取当前消费者自己的 pending 历史：这里是补读，不是新消息消费
redis-cli XREADGROUP GROUP workers consumer-a NOACK STREAMS stream:orders 0-0

第二条命令中的 NOACK 不会把已有 pending 变成“无 pending”，因为具体 ID 读取本来就是访问当前消费者自己的 PEL。官方命令语义还规定，在这种读取方式下，BLOCK、NOACK 和 CLAIM 都会被忽略。

因此可以用下面这张边界图快速判断：

BLOCK 和 CLAIM 应该怎样理解

在 > 新消息读取上，BLOCK 只是让客户端在暂时没有消息时等待；它不会改变是否进入 PEL。你可以把它和 NOACK 组合，用于持续监听但不维护待确认清单。

# 持续等待新消息，同时不把旁路读取写入 PEL
redis-cli XREADGROUP GROUP metrics consumer-a BLOCK 5000 NOACK COUNT 10 STREAMS stream:orders '>'

CLAIM 则是另一类语义：它用于从消费组中取得空闲时间达到条件的 pending 消息。当前文章只需要记住一个边界：当 CLAIM 读取的是已存在的 pending 条目时，NOACK 不会替你改变这类历史条目的处理逻辑。不要把“新消息不入 PEL”和“接管旧 pending”混成一件事。

怎样按可靠性选择写法

我自己的判断是：只要团队还在讨论“这条消息失败后由谁补偿”，就不要为了让 pending 数字好看而加 NOACK。只有当消息本身就是可丢失的观察副本，或者可靠链路已经在别处完成，NOACK 才是清晰的设计选择。

常见问题

NOACK 会删除 Stream 中的消息吗？

不会。它只是不把本次投递记录加入消费组的 PEL，不等同于 XDEL，也不会改变 Stream 的保留策略。

加了 NOACK 后还要执行 XACK 吗？

对同一批按 > 读取且使用 NOACK 的新消息，不需要再执行 XACK，因为它们没有进入 PEL。对普通读取产生的 pending，仍然需要 XACK。

为什么用了 NOACK，pending 还是有？

先确认是不是读取了具体 ID，或者 PEL 中本来就有旧记录。NOACK 不会清理历史 pending；要处理历史记录，应按恢复策略读取、确认或转移。

什么时候不应该使用 NOACK？

只要消息丢失会造成业务状态不一致、任务无法补偿或审计链路断裂，就应保留普通的 PEL 与 XACK 机制。

一句话总结：NOACK 是“读取新消息时不建立待确认记录”，不是“让所有 pending 自动消失”。先确定消息是否允许丢失，再选择 XREADGROUP + NOACK 或普通的 XREADGROUP + XACK。