xreadgroup 漏消息或重复消费的根本原因是消费者未正确处理 ack 或消费组初始化起始 id 设置错误；redis streams 仅保证“至少交付一次”，不提供“至少一次”或“恰好一次”语义。
为什么 XREADGROUP 会漏消息或重复消费
根本原因在于消费者没正确处理 ACK，或者消费组初始化时没设对起始 ID。Redis Streams 的消费组本身不保证“至少一次”或“恰好一次”，它只保证“至少交付一次”，漏或重全看你怎么用。
常见错误现象：XRANGE 能查到消息，但 XREADGROUP 死活读不到；重启消费者后突然收到一堆旧消息；不同消费者收到同一条消息。
- 创建消费组时，用
XGROUP CREATE mystream mygroup $表示从最新开始——此前已进 stream 的消息不会被分配 - 想回溯历史消息，得用
0-0（不是0），否则会跳过第一条 - 每条消息必须被显式
XACK，否则它始终在PENDING列表里，下次XREADGROUP还可能分给你 - 消费者崩溃前没
XACK？得靠XPENDING+XCLAIM主动捞回来，别指望自动重发
如何避免消费者饿死或消息堆积
Streams 没内置限流，全靠客户端控制读取节奏。一个消费者疯狂 XREADGROUP 不停歇，可能把内存打满；另一个慢消费者卡住，PENDING 消息越积越多，最后拖垮整个组。
使用场景：订单履约系统里，库存扣减服务比支付通知慢得多，但不能让通知队列堵死。
- 每次
XREADGROUP加COUNT参数，比如COUNT 10，别默认无限读 - 设置合理
BLOCK时间（如BLOCK 5000），避免空轮询耗 CPU - 监控
XPENDING返回的 idle 时间，超过阈值（比如 60s）就触发告警或自动XCLAIM - 别在消费逻辑里做同步 HTTP 调用或长事务，阻塞会导致本 consumer 的 pending 消息无法释放
Stream ID 怎么选：自动生成 vs 手动指定
Stream ID 决定消息顺序和可追溯性。用错 ID 类型，轻则乱序，重则丢数据。
参数差异：* 让 Redis 自动生成 ms-sequencenumber 格式 ID；手动指定如 1678901234567-0 可控但风险高。
- 绝大多数场景用
*就行，Redis 保证严格递增、全局有序 - 只有需要“按业务时间戳归档”或“合并多个来源消息到同一流”时才手动 ID，且必须确保毫秒部分 ≥ 上一条，否则
XADD报错ERR The ID specified in XADD is equal or smaller than the target stream top item - 手动 ID 的序列号部分（
-N）别瞎填，填错会导致同毫秒内多条消息覆盖——Redis 不校验序列号连续性，只比大小
消费组里多个消费者怎么公平分消息
Redis 不搞“轮询”或“权重”，而是用“谁先调 XREADGROUP 谁拿”，表面看是随机，实际依赖网络延迟和客户端调度，容易偏斜。
性能影响：如果某个消费者响应快、重试勤，它可能长期霸占大部分消息，其他消费者闲着。
- 用
NOACK选项绕过 ACK 流程？不行——这会让消息永久丢失，XPENDING里都找不到 - 真正解法是客户端加一层本地队列 + 工作线程池，把
XREADGROUP当成“批量拉取”，再内部均衡分发 - 别依赖
RETRYCOUNT或TIMEOUT自动转移 pending 消息——这些是XCLAIM的辅助参数，不是消费组原生能力 - 上线新消费者时，先让它空跑几分钟，等
XPENDING分布稳定了再切流量
最麻烦的点其实是：Stream 没有“死信队列”概念，所有失败消息都卡在 pending 里，得自己实现超时判定和转发逻辑。没人帮你兜底。
