Redis XREADGROUP 读不到新消息时怎么区分组游标和阻塞参数

Redis Streams 消费组里，XREADGROUP 读不到“新消息”时，先别急着把 BLOCK 调大。真正决定读哪一类消息的是 STREAMS 后面的 ID：> 请求这个组尚未投递给其他消费者的消息，数字 ID（常用 0）读取当前消费者还没确认的 pending 历史；BLOCK 只负责在暂时没有可返回消息时等待多久。

先把 >、0 和 BLOCK 分成三件事

可以把一次读取拆成“从哪里选消息”和“没有消息时等多久”。Redis 官方文档把 > 定义为组尚未投递给其他消费者的消息；传入真实数字 ID 后，读取范围变成当前消费者自己的 pending 历史。BLOCK 5000 只表示最多等待 5000 毫秒，不会推动组游标，也不会替消费者认领别人的消息。

因此，下面两条命令的目的不同。第一条要接收组尚未分发的消息；第二条只回看名为 worker-a 的消费者还未确认的历史：

redis-cli XREADGROUP GROUP orders worker-a COUNT 10 BLOCK 5000 STREAMS order-events >

# 数字 ID 读取 worker-a 自己的 pending 历史，不会请求组的新消息
redis-cli XREADGROUP GROUP orders worker-a COUNT 10 STREAMS order-events 0

用一组最小命令判断消息卡在哪里

排查时先看状态，再改读取参数。XPENDING 的摘要能告诉你消费组有多少条 pending、最早和最晚的消息 ID，以及涉及多少消费者；这比盲目增加 BLOCK 更直接。

# 查看 orders 组的 pending 摘要，先判断是否存在未确认消息
redis-cli XPENDING order-events orders

# 查看每个消费者的 pending 归属与空闲时间
redis-cli XPENDING order-events orders - + 20

# 只回读 worker-a 的历史，确认数字 ID 是否有可读内容
redis-cli XREADGROUP GROUP orders worker-a COUNT 20 STREAMS order-events 0

可以按这个顺序判断：XPENDING 为零且 > 返回空，通常是组暂时没有新的未投递 entry；有 pending 但数字 ID 为空，说明消息不属于当前消费者；有 pending 且数字 ID 能读到，说明问题在处理后没有确认，或消费者在处理过程中退出。

处理成功后用 XACK 真正移出 pending

读取到消息并不等于处理完成。消费组会把已投递但未确认的 entry 放入 PEL。应用只有在业务写入、事务提交或下游调用成功后，才应对同一个消息 ID 执行 XACK。XACK 移除的是消费组的 pending 引用，Stream 中的原始 entry 仍然是另一件事。

# 业务处理成功后确认同一条 ID；ID 不要用下一条消息替代
redis-cli XACK order-events orders 1710000000000-0

# 再从当前消费者的历史读取，已确认的 ID 不应继续出现在 PEL
redis-cli XREADGROUP GROUP orders worker-a COUNT 10 STREAMS order-events 0

如果先 XACK 再写数据库，进程在两步之间崩溃可能造成消息丢失；如果永不确认，pending 会持续增长。实际项目应把确认点放在“业务结果已经可接受”的位置，并让处理逻辑具备幂等性。

故障接管时不要把 BLOCK 当重试机制

消费者 A 宕机后，消息仍属于 A 的 pending。此时用 XREADGROUP ... > 只能继续请求组的新消息，不能自动拿走 A 的历史。应先用 XPENDING 找到空闲时间达到阈值的 entry，再由消费者 B 用 XAUTOCLAIM 接管；老版本或需要精确指定 ID 时可使用 XCLAIM。

# 将空闲超过 60 秒的 pending 转给 worker-b；0-0 是扫描起点
redis-cli XAUTOCLAIM order-events orders worker-b 60000 0-0 COUNT 20

# 接管后仍要在业务处理成功时确认
redis-cli XACK order-events orders 1710000000000-0

BLOCK 可以让正常消费者少轮询，但它不负责故障检测、重试、确认或所有权转移。把这几种职责拆开后，读不到新消息通常只需回答三个问题：读取 ID 选的是新消息还是历史？当前消费者是否持有 pending？没有消息时等待边界是否符合客户端调用方式？

常见问题

把 0 改成 > 后仍然为空，说明什么？

通常表示这个组当前没有尚未投递的新 entry；先确认生产者是否真的写入该 Stream，再用 XPENDING 区分是否只是旧消息未确认。

XPENDING 有消息，为什么另一个消费者读不到？

pending 默认属于原消费者。另一个消费者要先用 XAUTOCLAIM 或 XCLAIM 接管，不能只把 BLOCK 调大。

XACK 会删除 Stream 里的消息吗？

不会。它移除的是指定消费组的 pending 引用；Stream entry 是否保留由独立的保留、裁剪或删除策略决定。

Redis 官方的 Streams 文档、XREADGROUP 命令说明和 XPENDING 命令说明可作为参数和状态语义的进一步依据。