Redis XREADGROUP 怎样阻塞等待消费者消息

Redis Streams 中想让消费者“没有消息就等一会儿”，关键不是给客户端加 sleep，而是在 XREADGROUP 中使用 BLOCK。它控制本次读取最多等待多少毫秒；写成 BLOCK 0 就会持续阻塞，直到有可读消息或连接被关闭。

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

下面只围绕消费者组读取新消息这一条路径展开：先建组，再用 > 和 BLOCK 等待，最后用 XACK 结束消息的 Pending 状态。

先看阻塞语义：BLOCK 等的是一次读取

BLOCK milliseconds 是 XREADGROUP 的可选参数，单位是毫秒。没有数据时，Redis 最多等待指定时间；例如 BLOCK 5000 等五秒，仍没有符合条件的消息就返回空结果。BLOCK 0 没有超时点，因此更适合由外层连接生命周期负责停止的常驻消费者。

这里的“阻塞”只描述当前命令，不代表消息已经被处理，也不代表消费者会自动重试。拿到消息后仍要执行业务逻辑，并根据结果决定是否确认。多个消费者在同一个组内读取时，Redis 会把新消息分配给组内的不同消费者，而不是让每个消费者都收到一份。

准备消费者组：用 > 表示等待新消息

消费之前要先有 Stream 和消费者组。下面的命令把组的起点设为 0，并在 Stream 不存在时创建它；实际生产环境也可以根据是否需要读取历史消息选择起点。

# 创建 Stream 消费组；MKSTREAM 允许 key 尚不存在时先建立空 Stream
redis-cli XGROUP CREATE orders order-workers 0 MKSTREAM

# 检查组是否已经存在；重复执行 CREATE 时应把 BUSYGROUP 当作已初始化处理
redis-cli XINFO GROUPS orders

读取新消息时，STREAMS orders > 中的 > 有特殊含义：只取从未投递给任何消费者的新消息。如果改成具体 ID，例如 0，语义就变成读取当前消费者自己的 Pending 列表，而不是继续等待新消息。

最小消费命令：GROUP、COUNT、BLOCK 要一起看

常驻消费者可以把一次读取写成下面这样。COUNT 10 限制单个 Stream 一次最多返回十条，BLOCK 5000 让没有消息时等待五秒；如果五秒内没有新消息，脚本拿到空结果后继续下一轮。

# worker-1 使用独立 consumer 名称，等待 orders 中的新消息
redis-cli XREADGROUP GROUP order-workers worker-1 COUNT 10 BLOCK 5000 STREAMS orders >

# 处理成功后确认消息，避免它一直留在 Pending Entries List
redis-cli XACK orders order-workers 1710000000000-0

客户端代码通常会循环调用这条命令：返回空数组代表本次等待超时，不应当当成消费失败；返回消息数组才进入业务处理。处理失败时不要为了“让命令继续阻塞”直接确认，应该保留 Pending 状态，再按业务策略重试或转移。

四个边界：超时、消息、Pending 和退出

超时空结果。使用有限的 BLOCK 时，如果等待期内没有新消息，返回空结果是正常分支。循环应继续等待，并在外层增加退避、日志或退出信号。

收到消息。使用 > 读到新消息后，消息会进入该消费者组的 Pending Entries List。业务成功后调用 XACK；只读到消息不等于消息已经完成。

读取 Pending。要补处理当前 consumer 已经拿到但尚未确认的消息，改用具体 ID 读取 Pending，而不是继续使用 >。这两种游标要分开设计，避免把历史补偿误当成新消息等待。

安全退出。BLOCK 0 会一直等，部署停止时必须关闭连接或使用客户端支持的取消机制；如果需要定期检查停止信号，使用有限的 BLOCK 通常更容易管理。

结论与常见问题

记住一条最小规则：GROUP group consumer ... BLOCK milliseconds STREAMS key > 负责等待新消息，COUNT 控制单次批量，XACK 负责确认处理结果。把组名、consumer 名称和读取游标固定下来，阻塞消费就不会和 Pending 补偿混在一起。

为什么一直返回空？先确认 Stream 中确实有新消息、消费者组存在，并且读取新消息时使用的是 >；如果消息已经投递过但未确认，它不再属于“从未投递的新消息”。

BLOCK 0 适合所有服务吗？不一定。长连接常驻 worker 可以使用，但需要明确连接关闭和进程退出策略；需要定期刷新配置或检查停止信号时，有限的 BLOCK 更直观。