认领超时消息
Stream 的消费者组会为每条已投递但未确认的消息登记一条 pending 记录，消费者一旦崩溃，这些消息就卡在那里没人处理。XAUTOCLAIM（Redis 6.2 起）按最小空闲时间把满足条件的 pending 消息批量转交给当前消费者，是消费者故障恢复的常用手段，比逐个 XCLAIM 省往返。
基本信息
| 语法 | XAUTOCLAIM key group consumer min-idle-time start [COUNT count] [JUSTID] |
|---|---|
| 返回 | 下一次的起始游标、被认领的消息、已清理的无效 ID（7.0 起） |
| 版本 | Redis 6.2 起 |
| 配套命令 | XPENDING 观察积压，XACK 确认处理完成 |
典型使用场景
- 消费者进程崩溃或重启后，把超时未确认的消息接过来继续处理
- 定时任务扫描 pending 积压，做补偿消费
- 扩容消费者后重新分配旧消费者遗留的消息
- 用 JUSTID 只取消息 ID，避免既拉取值体又用不上
- 配合 XPENDING 判断积压规模，决定每轮认领的批量
认领与观察
认领与观察
# 把空闲超过 60 秒的 pending 消息转交给当前消费者，一批最多 100 条
redis-cli XAUTOCLAIM orders g1 worker-b 60000 0 COUNT 100
# 只取消息 ID（不返回值体），适合先统计再按需读取
redis-cli XAUTOCLAIM orders g1 worker-b 60000 0 COUNT 100 JUSTID
# 认领前先看积压，认领后再看计数是否下降
redis-cli XPENDING orders g1
redis-cli XPENDING orders g1 - + 10返回值读法
| 返回项 | 含义 | 注意点 |
|---|---|---|
| 游标 | 下一次认领的起始 ID | 回到 0-0 表示这一轮已扫完 |
| 消息列表 | 本次成功认领的消息 | 加 JUSTID 时只有 ID，没有字段与值 |
| 清理的 ID 列表 | 已从 pending 移除的无效消息 | Redis 7.0 起才会返回这一项 |
| min-idle-time | 至少空闲多久才会被认领 | 设太小容易抢走正在处理的消息 |
| COUNT | 单次最多认领条数 | 不设时默认值较小，通常需要显式指定 |
认领只是把消息归属改成新消费者，消息仍在 pending 列表里；处理完必须 XACK，否则下一轮还会被再次认领，形成反复处理。
COUNT 给得过大，会瞬间把大量消息灌给单个消费者，容易把它压垮；按消费者的实际吞吐设一个上限，用循环代替一次拉满。