Redis Stream消费组重试需手动干预：XPENDING加范围与消费者参数定位卡点，XCLAIM配FORCE和MIN-IDLE-TIME安全转移消息，XACK须在业务真正成功后调用，Redis 5.0.5需自行轮询XPENDING实现自动重试。
Redis Stream 的消费组重试不是自动发生的，必须靠 XPENDING + XCLAIM 主动干预，否则失败消息会永远卡在 PEL 里。
XPENDING 查不到具体消息内容？加参数才能定位卡点
只跑 XPENDING mystream mygroup 只返回 pending 总数、最小/最大 ID 和各 consumer 占比，根本看不出哪条消息卡了多久、被谁拿了几次。真正有用的命令是带范围和消费者名的完整形式：
-
XPENDING mystream mygroup - + 10：查全部 pending 消息中最近 10 条，含 ID、consumer 名、空闲毫秒数、分发次数 -
XPENDING mystream mygroup - + 10 workerA 60000：只查workerA名下空闲超 60 秒的消息（注意：Redis 5.0.5 不支持该 TIME 过滤，得客户端自己筛） - 重点关注第三列（空闲时间）持续增长 → 原 consumer 已失联；第四列 ≥ 3 → 已重试多次，该转移了
XCLAIM 转移消息时 FORCE 和 MIN-IDLE-TIME 必须配对用
XCLAIM 不是“拿过来就完事”，它默认只认原 consumer 提交的 pending 消息。没加 FORCE 就直接抢，Redis 5.0.5 会报 NOGROUP 或 NOACK 错误。同时，不设 MIN-IDLE-TIME 容易把刚卡住 2 秒的正常消息也抢走，引发震荡：
- 正确写法：
XCLAIM mystream mygroup newworker 3600000 1710234567890-0 RETRYCOUNT 1 FORCE -
3600000是毫秒值，表示只抢空闲超 1 小时的消息，避免误操作 -
RETRYCOUNT 1显式重置重试计数，否则新 consumer 处理失败后可能直接进死信（如果业务逻辑依赖 retry_count 判断） - 漏掉
FORCE或MIN-IDLE-TIME，XCLAIM 就只是个摆设
重试不等于无限循环，XACK 必须在业务真正成功后调用
很多堆积问题根源不在重试机制，而在 XACK 调用时机错误。常见反模式：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 把
XACK放在 try 块末尾，但 DB 写入失败抛异常，XACK根本没执行 → 消息一直留在 PEL - 消费逻辑里发起远程 HTTP 调用，耗时超过 60 秒 → IDLE 时间一到就被系统标记为“卡死”，触发重复投递
- 没做幂等，
XCLAIM抢过来又处理一遍，结果重复扣款或发两条短信
可靠做法是：DB 写入成功 → 更新本地状态 → 最后发 XACK；所有外部依赖必须设超时，且重试逻辑收口在应用层，别指望 Redis 替你兜底。
Redis 5.0.5 没有 XAUTOCLAIM，轮询 XPENDING 得自己写脚本
Redis 6.2+ 才有 XAUTOCLAIM 自动转移长期 idle 的消息。如果你用的是 5.0.5（当前生产环境仍很常见），就得自己定时执行：
- 用
XPENDING mystream mygroup - + 100扫描 pending 列表 - 过滤出空闲 > 300000（5 分钟）、retry_count
- 对每条 ID 调用
XCLAIM转给备用 consumer，并加FORCE和RETRYCOUNT - 脚本频率建议 30–60 秒一次，太密加重 Redis 负担，太慢导致堆积恶化
最容易被忽略的是：这个脚本必须独立部署，不能跟 consumer 进程耦合——否则 consumer 宕机，脚本也停了，pending 消息就真锁死了。
