新消费者收不到旧消息是因为XGROUP CREATE默认从最新偏移（$）开始消费，不自动回溯；需显式指定起始ID 0或用XREADGROUP STREAMS mystream 0补读，且必须及时XACK避免重复分配。
Consumer Group 创建后为什么新消费者收不到旧消息
Redis Streams 的 Consumer Group 不会自动回溯历史消息，XGROUP CREATE 时若未指定 $ 或 0，默认从最新偏移（$）开始消费——这意味着已写入的旧消息对新加入的消费者不可见。
实操建议：
- 首次创建 Group 且需处理积压消息：用
XGROUP CREATE mystream mygroup 0，从流头开始 - 只关心实时消息：用
XGROUP CREATE mystream mygroup $（推荐默认做法） - 已有 Group 想让新消费者补读：必须用
XREADGROUP GROUP mygroup newconsumer COUNT 100 STREAMS mystream 0，显式指定起始 ID0；但注意这会干扰 Group 整体的pending状态管理
多个消费者调用 XREADGROUP 时如何避免重复消费
重复消费不是因为命令本身，而是没正确处理「消息确认」。Redis 不自动标记消息为已处理，必须显式调用 XACK，否则该消息会一直留在 PENDING 列表里，下次 XREADGROUP 可能再次分配给任意消费者。
关键点：
- 每次成功处理一条消息后，立刻执行
XACK mystream mygroup <message_id> - 不要在批量处理完再统一
XACK——万一中间崩溃，整批都会重发 - 消费者宕机时，未
XACK的消息会在XPENDING中保留，默认 60 秒后可被其他消费者用XCLAIM抢走；这个超时由XREADGROUP的TIMEOUT和服务端配置共同影响，但不改变「必须手动XACK」这一前提
XREADGROUP 的 COUNT 和 BLOCK 怎么配才不卡死也不空转
COUNT 控制单次最多拉几条，BLOCK 控制无新消息时阻塞多久。配得不合理会导致：太小 → 频繁轮询、连接抖动；太大 → 内存占用高、处理延迟上升；BLOCK 为 0 → 连接永久挂起（除非有新消息或客户端断开）。
实操建议：
- 普通业务消费：用
COUNT 10+BLOCK 5000（5 秒），平衡吞吐与响应 - 低频事件（如订单状态变更）：
COUNT 1+BLOCK 30000，减少无效请求 - 测试/调试时慎用
BLOCK 0—— 它会让连接永远等待，容易卡住脚本或调试器 - 注意：
BLOCK超时后返回空数组，不是错误，代码里要判断len(result) == 0而非抛异常
Consumer Group 的名字和消费者名字有什么实际约束
Group 名和消费者名只是字符串标识，Redis 不校验格式，但会影响运维和排查效率。最常踩的坑是：用随机 UUID 当消费者名，导致 XPENDING 输出难以关联到具体实例；或者 Group 名含特殊字符（如空格、斜杠），在监控脚本里解析出错。
建议规则：
- Group 名用业务语义命名，如
payment-processor、notification-sender - 消费者名体现部署维度，例如
worker-us-east-1a-01，别用consumer_12345 - 避免在名字里用
.、/、空格——虽然 Redis 允许，但部分客户端库或 Prometheus exporter 会截断或报错 - 消费者名不必唯一，但同 Group 内重复名会导致
XPENDING统计混乱，应确保部署时生成唯一标识
真正麻烦的从来不是命令怎么写，而是谁在什么时候漏了 XACK，或者以为 Group 自动 rewind 结果一批消息反复重放。这些地方没有魔法，只有日志和 XPENDING 查得勤。
