因为XGROUP CREATE默认从最新偏移$开始消费，不自动回溯历史消息；需显式指定起始ID 0或用XREADGROUP STREAMS mystream 0补读，且必须及时XACK避免重复分配。
为什么XGROUP CREATE后新消费者收不到旧消息
因为 XGROUP CREATE 默认从最新偏移 $ 开始消费，已存在的历史消息对新加入的消费者不可见。这不是 bug，而是设计：Redis 不自动回溯，必须显式指定起始位置。
实操建议：
- 首次创建 Group 且需处理积压消息：用
XGROUP CREATE mystream mygroup 0 MKSTREAM，0表示从流头开始，MKSTREAM确保 Stream 不存在时自动创建 - 只关心实时写入的新消息：用
XGROUP CREATE mystream mygroup $（推荐默认做法） - 已有 Group 想让新消费者补读：不能只靠
XREADGROUP，必须先用XREADGROUP GROUP mygroup newconsumer COUNT 100 STREAMS mystream 0显式指定起始 ID0；但注意这会干扰 Group 整体的 pending 状态管理，慎用于生产环境
如何避免多个消费者重复消费同一条消息
重复消费几乎总是因为没及时调用 XACK。Redis 不自动标记消息为已处理，所有被 XREADGROUP 返回的消息都会进入 PEL（Pending Entries List），直到你手动确认。
关键点：
- 每成功处理一条消息，立刻执行
XACK mystream mygroup - 不要攒一批再统一
XACK——万一中间崩溃，整批都会重发 - 消费者宕机后，未
XACK的消息在 PEL 中保留，默认 60 秒后可被其他消费者用XCLAIM抢走；这个超时由XREADGROUP的TIMEOUT参数和服务端配置共同影响，但不改变「必须手动XACK」这一前提
COUNT 和 BLOCK 怎么配才不卡死也不空转
COUNT 控制单次最多拉几条，BLOCK 控制无新消息时阻塞多久。配错会导致连接抖动、内存浪费或假死。
常见组合：
- 普通业务消费（如订单处理）：用
COUNT 10+BLOCK 5000（5 秒），平衡吞吐与响应 - 低频事件（如退款审核）：用
COUNT 1+BLOCK 30000（30 秒），减少无效轮询 - 测试/调试时慎用
BLOCK 0——它会让连接永久挂起，直到有新消息或客户端断开，极易卡住脚本或调试器
BLOCK 超时后返回空数组，不是错误，代码里要判断 len(result) == 0 而非抛异常。
Group 名和 Consumer 名有哪些隐性约束
Redis 不校验格式，但命名不当会直接拖垮运维效率。
最常踩的坑：
- 用随机 UUID 当消费者名（如
7f8a2b1e-4c5d...），导致XPENDING输出难以关联到具体实例，查问题时抓瞎 - Group 名含空格、斜杠或特殊字符（如
order/group-v2），在监控脚本或自动化工具里解析失败 - 多个服务共用同一 Group 名但没隔离消费者名，造成
XPENDING混淆、XCLAIM误抢
建议用带业务上下文的短字符串，比如 order_proc_v1 + worker-us-east-1，既可读又易 grep。
