先丢一个核心判断：**Redis Streams 的消费者组本身并不提供“高可用”保障**，它仅负责消息的分发与进度追踪。真正的高可用，必须由客户端自行实现容错、重试、PEL 拉取以及消费者重启后的状态恢复。

为什么 XREADGROUP 不能自动保证高可用

痛点在哪里？一旦消费者崩溃，它正在处理但尚未调用 `XACK` 的消息，会直接卡在 PEL（Pending Entries List）中，不会自动转移给其他消费者。Redis 既不会主动检测消费者是否存活，也不会触发重新均衡。这意味着： - `XREADGROUP` 只是一个读命令，不具备心跳或健康检查的语义 - 消费者名称（例如 `c1`）只是纯字符串标识，如果你重复使用相同名称，历史 PEL 会被继承，很可能导致重复处理 - Redis 服务端完全不知道你是“暂时断开”还是“永久退出”——它没有内置的消费者下线通知机制

必须手动处理的三个关键环节

如果想让基于 `XREADGROUP` 的消费逻辑真正扛住故障，以下三点缺一不可。具体拆解为三个操作： - 消费者启动时，先使用 `XCLAIM` 扫描自己在 PEL 中超时未确认的消息（例如设置 `IDLE 60000`），避免消息卡死在那里 - 业务处理逻辑外面必须包裹一层 try/catch，捕获异常后不调用 `XACK`，而是根据策略决定是否通过 `XCLAIM` 重试，或者直接丢弃 - 每个消费者实例必须用唯一、可追溯的名称（例如 `worker-abc123`），千万不要硬编码成 `c1`，更不要复用旧名称

阻塞读 + 超时控制的实际写法

单纯写一句 `XREADGROUP GROUP g1 c1 STREAMS s1 >` 很容易让客户端无限等待。在生产环境中，必须绑定 `BLOCK` 和一个合理的超时值： ```brush:php;toolbar:false; 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` 或直接忽略，而应让它恢复到可被其他消费者领取的状态： 1. 先用 `XPENDING s1 g1 - + 10` 查询待处理消息的 ID 列表 2. 对目标 ID 执行 `XCLAIM s1 g1 new-worker 3600000 IDLE 120000 1527851486781-0`，将其“认领”给新消费者 3. `IDLE 120000` 表示该消息至少空闲 2 分钟才允许被抢占，防止误抢正在处理中的消息 4. 被 `XCLAIM` 之后，原消费者再去调用 `XACK` 会失败（返回 0），这属于正常行为 真正的难点在于判断何时触发 `XCLAIM`——不能等到消费者彻底宕机才发现。一个更可靠的方案是，由独立的 watchdog 进程定期扫描所有消费者的 PEL，监控每条消息的 `IDLE` 时间，再决定是否执行 `XCLAIM`。