Redis XPENDING 怎样查看消费组待处理消息的责任人

Redis Stream 消费组出现积压时，先要回答一个很具体的问题：哪些消息还在 Pending Entries List（PEL）里，它们当前由哪个消费者负责？XPENDING 专门读取消费组的待处理消息信息，不会替你确认、删除或接管消息。

官方地址：https://redis.io/docs/latest/commands/xpending/

最实用的判断顺序是：先用两参数形式看总量和消费者范围，再用四参数范围查询读取具体消息，最后用 IDLE 或消费者名缩小排查范围。

先用摘要确认消费组是否真的有积压

XPENDING 的完整语法是：

# 先查看消费组的 Pending 摘要，不修改 Stream 数据
redis-cli XPENDING orders-stream order-workers

摘要返回四个关键信息：待处理消息总数、最小消息 ID、最大消息 ID，以及当前拥有 Pending 消息的消费者列表。它适合做第一轮判断：总数为 0 时，当前消费组没有未确认条目；总数大于 0 时，再进入明细查询。

这里的“待处理”指消息已经投递给消费者、但尚未通过 XACK 确认。它不等于 Stream 中的全部消息，也不等于某个消费者当前正在执行的全部业务。

用范围查询读取具体消息和责任人

要查看每条 Pending 记录，给出起始 ID、结束 ID 和数量：

# 使用 - 和 + 覆盖整个 Pending ID 范围，最多返回 10 条
redis-cli XPENDING orders-stream order-workers - + 10

明细结果通常包含四列：消息 ID、所属消费者、空闲时间（毫秒）和投递次数。责任人就是第二列的消费者名；空闲时间越大，说明该消息距离上次投递或重新分配的时间越久。count 不是“总积压量”，而是本次最多返回的条数。

生产排查时不建议一次请求过大的数量。可以先取少量样本确认消费者分布，再按消息 ID 范围分页。这样既能看到最早积压，也避免一次响应过大影响排查工具。

按消费者或空闲时间缩小范围

如果摘要显示某个消费者长期没有确认，可以把消费者名放在最后：

# 只看 worker-2 负责的 Pending 消息
redis-cli XPENDING orders-stream order-workers - + 20 worker-2

# 只看空闲时间至少 60000 毫秒的 Pending 消息
redis-cli XPENDING orders-stream order-workers IDLE 60000 - + 20

两个过滤条件的含义不同：消费者过滤回答“谁名下有这些消息”，IDLE 过滤回答“哪些消息已经超过指定空闲时间”。它们都只是读取 PEL 的诊断条件，不能替代 XCLAIM 或 XAUTOCLAIM 的接管动作。

如果使用 Go 客户端，建议把 XPENDING 的结果先映射成结构体，再由业务层决定是否告警或补偿，不要在读取诊断结果时直接执行接管：

type PendingMessage struct {
	ID           string
	Consumer     string
	IdleMillis   int64
	Deliveries   int64
}

func needsAttention(item PendingMessage, idleLimit int64) bool {
	// 空闲时间达到阈值时只标记为待排查，不在这里修改消息归属。
	return item.IdleMillis >= idleLimit
}

看到结果后怎样做下一步判断

可以按下面的速查表处理：

要点只有一个：XPENDING 负责告诉你“谁持有、多久没确认、投递了几次”，后续动作仍要根据业务幂等性和故障原因谨慎选择。

常见问题

XPENDING 能直接读取消息正文吗？ 不能。它返回 Pending 元数据和消息 ID；需要正文时，再使用消息 ID 查询 Stream 内容。

为什么 XPENDING 总数和 Stream 总长度不一样？ Stream 长度包含所有消息，而 XPENDING 只统计已经投递给某个消费组、尚未确认的消息。

IDLE 过滤会不会自动接管消息？ 不会。IDLE 只是筛选空闲时间达到条件的 Pending 条目，接管要由单独的命令和明确的恢复策略完成。