XPENDING 与 XCLAIM 是什么
消息被某个消费者读走但还没确认时，会记录在消费组的待处理列表（PEL）里，归属到读它的那个消费者名下。待处理列表是 Stream 可靠性的核心：它让「已投递但未处理完成」这件事变得可观测、可干预。XPENDING 用来查看积压情况，XCLAIM 把空闲超过指定时长的消息转交给另一个消费者重试，XAUTOCLAIM 则可以一次批量认领多条，适合做僵尸消费者的兜底清理。
基本信息
| 概览查询 | XPENDING key group，返回总数、最小与最大 ID、各消费者未确认数 |
|---|---|
| 明细查询 | XPENDING key group - + 10，列出具体消息与空闲时长 |
| 单条认领 | XCLAIM key group consumer <min-idle-time> <id> |
| 批量认领 | XAUTOCLAIM key group consumer <min-idle-time> <start> COUNT n |
| 确认 | XACK key group id，处理完成后把消息从待处理列表中移除 |
典型使用场景
- 消费者崩溃恢复：把宕机消费者的未确认消息转交给在线的消费者重试
- 僵尸消费者清理：消费者下线但记录仍在，用批量认领把消息收回到可用节点
- 积压监控：把待处理总数与最老消息的空闲时长接入监控，积压出现即告警
- 长耗时任务保护：设置足够的空闲阈值，避免把仍在处理中的消息抢走
- 上线变更后的核对：确认消费者换名或缩容后没有遗留无法归属的消息
查看与认领
查看与认领
redis-cli XPENDING orders g1 # 总览：总数、ID 范围、各消费者未确认数
redis-cli XPENDING orders g1 - + 10 # 前 10 条明细与空闲时长
redis-cli XCLAIM orders g1 consumer2 60000 1730020000000-0 # 空闲超 1 分钟后认领单条
redis-cli XAUTOCLAIM orders g1 consumer2 60000 0-0 COUNT 10 # 批量认领，游标从 0-0 开始
redis-cli XACK orders g1 1730020000000-0 # 处理完成后确认
redis-cli XINFO GROUPS orders # 各组 pending 数量与最后投递 ID认领参数的含义
| 参数 | 含义 | 取值建议 |
|---|---|---|
| min-idle-time | 只认领空闲超过该毫秒数的消息 | 必须大于单条消息的最长处理时间 |
| start 游标 | XAUTOCLAIM 的起始 ID | 首次用 0-0，后续用返回的新游标 |
| COUNT | 单次认领上限 | 按消费者吞吐设置，避免一次抢太多 |
| JUSTID | 只返回 ID，不返回消息体 | 只做转发或计数时更省带宽 |
空闲阈值是防误抢的关键：min-idle-time 表示「这条消息已经被读出多久没有被确认」，设置得比正常处理耗时长，就不会把正在处理中的消息抢走。阈值一旦设置过短，会出现两个消费者同时处理同一条消息的重复执行。
待处理列表会持续占用内存：未确认的消息不会自动清理，长期积压既是内存问题也是业务问题——意味着有消息没有被处理完。监控应同时看总数与最老消息的空闲时长，只关注总数会漏掉「少量消息长期卡住」的情况。