XREADGROUP能自动负载均衡，因Redis服务端按轮询策略将新消息分发给组内不同消费者，确保同条消息仅投递一次；未ACK消息超时后可被其他消费者XCLAIM接管，实现故障转移。

Pub/Sub 本身不支持负载均衡——它只是广播，所有订阅者收到相同消息，没法分摊压力。真要实现多消费者负载均衡，得换用 Stream + Consumer Group，不是在 Pub/Sub 上修修补补。

为什么 XREADGROUP 能自动负载均衡

Redis 对每个消费者组维护一个内部游标（group’s last delivered ID），新消息进来时按轮询策略分发给组内不同消费者。只要调用 XREADGROUP 时指定不同 consumer 名，Redis 就会确保同一条消息只投递给一个消费者。

• 消息分配不依赖客户端逻辑，服务端直接控制，避免竞争条件
• 消费者宕机后，其 PEL（Pending Entries List）中未 XACK 的消息，在超时后可被其他消费者用 XCLAIM 接管
• 没有“抢占式重平衡”，但通过 XPENDING + XCLAIM 实现故障转移

XGROUP CREATE 时用 0 还是 $ 决定能否读到旧消息

新创建的消费者组默认从 $（最新消息）开始消费，历史消息对后续加入的消费者不可见。这不是 bug，是设计选择。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 想消费已有全部消息：用 XGROUP CREATE mystream mygroup 0
• 只关心实时流：用 XGROUP CREATE mystream mygroup $（推荐，默认行为）
• 组已存在，又想让新消费者补读积压：必须显式 XREADGROUP GROUP mygroup newconsumer STREAMS mystream 0，但注意这会把整条流重放，且可能干扰 PEL 状态

重复消费的根本原因不是 Stream，而是漏掉 XACK

XREADGROUP 只是“分发”，不是“交付完成”。消息一旦被读出，就进入该消费者的 PEL，直到你手动 XACK 才真正移出。

• 每次成功处理一条消息后，立刻执行 XACK mystream mygroup <message_id>
• 不要攒一批再 XACK——中间崩溃会导致整批重发
• 没 XACK 的消息会在 XPENDING 中保留，默认 60 秒后可被其他消费者 XCLAIM
• XPENDING 输出里的 idle 字段就是空闲时长，超时即触发再分配

COUNT 和 BLOCK 参数配不好，消费就卡死或空转

XREADGROUP 的 COUNT 和 BLOCK 不是越大越好，得看业务节奏。

• COUNT 1：适合强顺序、低吞吐场景（如订单状态机），但频繁调用增加连接抖动
• COUNT 10–50 + BLOCK 5000：通用平衡点，兼顾吞吐与延迟
• BLOCK 0：慎用！连接会永久挂起，调试时极易卡住脚本
• BLOCK 超时返回空数组，不是错误，代码里必须判断 len(result) == 0

实际部署中最容易被忽略的是消费者名的可运维性——用随机字符串当 consumer 名，出问题时根本没法从 XPENDING 输出里定位到具体实例。命名最好带服务名+主机名+进程ID，哪怕多几个字符，排查时能省半小时。