redis streams消费者组不提供高可用，需客户端实现容错：崩溃消息滞留pel、无自动再均衡、须xclaim转移超时消息、用唯一consumer名、block+count合理配置，并由watchdog监控idle时间触发xclaim。
Redis Streams 的消费者组本身不提供“高可用”保障，它只负责消息分发与进度跟踪；真正的高可用必须由客户端自己实现容错、重试、PEL 拉取和消费者重启后的状态恢复。
为什么 XREADGROUP 不能自动保证高可用
消费者崩溃后，它正在处理但尚未 XACK 的消息会滞留在 PEL（Pending Entries List）中，不会自动转给其他消费者。Redis 不会主动检测消费者是否存活，也不会触发再均衡。这意味着：
-
XREADGROUP只是读命令，不带心跳或健康检查语义 - 消费者名称（如
c1）是纯字符串标识，重复使用相同名会导致历史 PEL 被继承，可能引发重复处理 - 没有内置的“消费者下线通知”机制，服务端无法区分“暂时断连”和“永久退出”
必须手动处理的三个关键环节
要让基于 XREADGROUP 的消费逻辑真正扛住故障，这三件事缺一不可：
- 消费者启动时，先用
XCLAIM扫描自身在 PEL 中超时未确认的消息（例如设置IDLE 60000），避免消息卡死 - 业务处理逻辑外层包一层 try/catch，并在捕获异常后不调用
XACK，而是根据策略决定是否XCLAIM重试或丢弃 - 每个消费者实例必须使用唯一、可追溯的名称（如
worker-abc123），禁止硬编码为c1或复用旧名
阻塞读 + 超时控制的实际写法
单纯写 XREADGROUP GROUP g1 c1 STREAMS s1 > 容易让客户端无限等待，生产环境应始终绑定 BLOCK 和合理超时：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
XREADGROUP GROUP g1 worker-7f3a BLOCK 5000 COUNT 10 STREAMS s1 >
注意点：
-
BLOCK 5000表示最多阻塞 5 秒，超时返回(nil)，此时应主动 sleep 后重试，而非直接 panic -
COUNT 10不是越多越好：批量太大可能单条失败导致整批回滚；建议 1–5 条为宜 - 若 stream 尚未创建，
XREADGROUP会报错NOGROUP No such key，需前置确保XGROUP CREATE s1 g1 $ MKSTREAM已执行
PEL 消息如何安全重入队列
当某条消息反复处理失败，不能只靠 XACK 或忽略，得让它回到可被其他消费者领取的状态：
- 先用
XPENDING s1 g1 - + 10查出待处理消息 ID 列表 - 对目标 ID 执行
XCLAIM s1 g1 new-worker 3600000 IDLE 120000 1527851486781-0，把它“认领”给新消费者 -
IDLE 120000表示该消息至少空闲 2 分钟才可被抢占，防止误抢正在处理中的消息 - 被
XCLAIM后，原消费者再调XACK会失败（返回 0），这是正常行为
真正难的是判断什么时候该 XCLAIM：不能等消费者彻底宕机才发现，最好由一个独立的 watchdog 进程定期扫描所有消费者 PEL 的 IDLE 时间并决策。
