XACK 后消息仍在 Pending List 是因未显式调用或调用失败，需在 finally/defer 中确保执行并检查返回值；重复消费需固定 consumer 名并配合 XPENDING 扫描。
为什么 XACK 之后消息还在 Pending List 里
因为 XACK 只在消费者显式调用时才标记消息为“已确认”，而 Redis Streams 不会自动帮你调用它——哪怕你已经处理完消息、甚至程序都退出了。没调 XACK，消息就一直留在 PENDING 状态，下次用 XREADGROUP 拉取时还可能被重新分发。
- 常见错误现象：
XPENDING返回大量未确认消息，但业务日志显示“已处理完成” - 根本原因：消费逻辑里漏掉
XACK调用，或只在成功路径里调用、异常分支没兜住 - 正确姿势：把
XACK放在 finally 块（Java/Python）或 defer（Go），确保无论成功失败都至少尝试一次确认 - 注意：如果消费者崩溃前没来得及发
XACK，消息仍会超时回到 pending，这是设计使然，不是 bug
如何避免重复消费：Group + Consumer + XACK 的配合逻辑
Streams 的“不丢失”不等于“不重复”，它靠的是「至少一次」语义。真正控制重复的关键，在于消费者组（GROUP）、消费者名（CONSUMER）和 XACK 的三者绑定关系。
- 每个消息在 group 内有唯一 pending 记录，包含所属 consumer 和最后交付时间
- 同一个 consumer 名反复拉取消息，Redis 会优先返回它自己 pending 中未 ack 的旧消息（防止饥饿）
- 不同 consumer 名之间互不影响，所以别用随机名或进程 PID 当 consumer 名，否则每次重启都变成新消费者，pending 消息永远没人认领
- 推荐做法：固定 consumer 名（如
"worker-01"），并在服务启动时先XPENDING扫描残留消息，再决定是否重试或跳过
XACK 失败的几种情况和应对方式
XACK 不是“发了就完事”，它可能静默失败——比如消息 ID 根本不在该 group 的 pending 列表中，Redis 就直接返回 0，不报错也不提示。
- 典型错误现象：
XACK返回 0，但业务以为确认成功，后续发现消息被重复投递 - 原因包括：消息已被其他 consumer
XACK、ID 写错、group 名或 stream 名拼错、消息已过期被自动清理（MAXLEN或MAXLEN ~触发） - 实操建议：检查
XACK返回值，非 1 就要记录告警；不要依赖“发送即成功”，尤其在高并发多 worker 场景下 - 兼容性注意：Redis 6.2+ 支持
XACK批量操作（一次确认多个 ID），但老版本只能单条调用，性能差且网络开销大
消息“真丢失”的边界在哪
Streams 本身不保证磁盘持久化级别的不丢失，它只保证内存中已写入 stream 的消息不因崩溃而消失——前提是你的 Redis 配置了 appendonly yes 且 aof-fsync 策略足够严格。
- 如果 Redis 没开 AOF，或用了
no/everysec策略，宕机可能丢掉最后几秒消息 - 如果 stream 设置了
MAXLEN，新消息写入时老消息会被强制裁剪，这不是故障，是预期行为 - 最常被忽略的一点：consumer group 创建时没指定
START，默认从 stream 末尾开始读，之前所有消息对它不可见——这不是丢失，是“压根没订阅到” - 真正能靠
XACK控制的，只是“已投递但未确认”的那一小段窗口；更上游的可靠性，得靠 AOF + RDB + 监控 + 重放机制一起兜底
