XREADGROUP 怎样分摊 Stream 消息

如果多个 worker 都要处理同一个 Redis Stream，但每条消息只希望被其中一个 worker 接手，就让它们使用同一个 consumer group，并为每个进程设置不同的 consumer 名称。新消息用 > 读取，处理成功后用 XACK 确认；这样 Redis 才能维护每条消息当前由谁处理。

官方文档：https://redis.io/docs/latest/commands/xreadgroup/

“分摊”不是给每个客户端复制一份消息，而是让同一消费组中的消费者各自取得尚未投递的消息。它也不是严格的轮询调度：Redis 按当前读取请求和可用消息返回结果，业务不要依赖固定的 1、2、3 轮转顺序。

先区分广播读取和消费组分摊

普通 XREAD 适合多个客户端都要看到同一批消息的场景；消费组模式的 XREADGROUP 则把同一个 Stream 的新消息分给组内不同消费者。这个选择决定了消息是“每个客户端都收到”，还是“同一组里由一个消费者接手”。

注意，组内消费者需要使用不同名称。名称相同会让多个进程在 Redis 中表现成同一个 consumer，后续查看 pending 记录和故障恢复都会变得难以区分。

用同一个 group 读取尚未投递的消息

先创建 Stream 和消费组。下面的 '$' 表示从当前末尾开始，适合只接收之后新写入的消息；如果初始化时要消费已有历史，需要根据业务选择起始 ID。

# 创建消费组；'$' 让 group 从创建时的末尾开始关注新消息
redis-cli XGROUP CREATE orders workers '$' MKSTREAM

# 写入两条示例消息；真实项目中的字段应由生产者统一约定
redis-cli XADD orders '*' type paid order_id 1001
redis-cli XADD orders '*' type paid order_id 1002

# consumer-a 和 consumer-b 使用同一个 group，但名称不同
redis-cli XREADGROUP GROUP workers consumer-a COUNT 1 BLOCK 5000 STREAMS orders '>'
redis-cli XREADGROUP GROUP workers consumer-b COUNT 1 BLOCK 5000 STREAMS orders '>'

两条读取命令中的 GROUP workers 相同，consumer 名称不同，> 只请求此前没有投递给任何消费者的新消息。第一条命令拿走一条后，第二条命令不会再拿到同一条作为新的分摊结果。COUNT 是单次读取上限；BLOCK 只控制暂时没有可读消息时最多等待多久。

如果同一个 Stream 绑定了多个 key，消费组也要在每个相关 Stream 上存在同名配置；但对一个普通的单 Stream worker 池，先保持一个 key、一个 group、多个唯一 consumer，更容易排查。

分摊之后要用 XACK 清理 pending

XREADGROUP 读取新消息时，Redis 会把消息放入该消费组的 Pending Entries List，简称 PEL。它表示消息已经投递给某个 consumer，但应用还没有明确告诉 Redis“处理完成”。因此，读取成功不等于业务完成。

# 处理成功后确认；把 ID 替换为 XREADGROUP 返回的真实消息 ID
redis-cli XACK orders workers 1700000000000-0

# 查看消费组的 pending 概况；用于定位未确认消息和消费者归属
redis-cli XPENDING orders workers

# consumer-a 重启后读取自己尚未确认的历史，不会读取全组的新消息
redis-cli XREADGROUP GROUP workers consumer-a COUNT 10 STREAMS orders 0

这里的 0 与 > 语义不同：非 > 的 ID 用于访问当前 consumer 自己的 pending 历史，适合重启恢复。恢复处理成功后仍然要调用 XACK。如果只是把消息重新读出来却不确认，PEL 仍会保留它。

参数怎么选，哪些做法容易误判

最常见的误区是把不同 group 当成“多 worker 分摊”。不同 group 会各自看到一份 Stream 消息；要在同一组内部拆分任务，必须共享 group 名称。另一个误区是把 COUNT 1 当成严格轮询保证。它只限制单次返回数量，不能替你的应用实现公平调度。

常见问题

为什么两个 worker 还是拿到了相同的消息？

先确认两边的 group 名称完全相同、consumer 名称彼此不同，并且读取的是同一个 Stream key。若使用了不同 group，它们本来就会各自读取一份消息；若不是用 >，则可能是在读取各自的 pending 历史。

consumer 重启后为什么看不到之前没处理完的消息？

重启后要继续使用同一个 group 和同一个 consumer 名称读取 pending 历史，并使用非 > 的起始 ID；同时检查 XPENDING 是否显示消息仍属于该 consumer。处理成功后补上 XACK，再切回 > 接收新消息。

归纳起来：同组解决“分摊”，不同 consumer 名称解决“身份”，> 解决“新消息入口”，PEL 与 XACK 解决“处理是否完成”。把这四层关系分开，XREADGROUP 的行为就不会再像随机抢消息。