XPENDING用于查询消费者组中已读取但未确认的消息，仅返回元信息（如ID、消费者、空闲时长），不包含消息内容；需配合XCLAIM或XREADGROUP获取实际数据，且必须加参数（如范围、消费者名、IDLE阈值）才能准确定位异常。
怎么用 XPENDING 查未确认的消息？
直接执行 XPENDING 是最快速定位堆积的入口，但它不返回消息内容，只告诉你“谁卡住了、卡了多久、卡了多少条”。必须配合 XCLAIM 或 XREADGROUP 才能捞出实际数据。
常见错误是只跑一次 XPENDING stream:logs mygroup 就以为完事了——它只显示 pending 总量和最小/最大 ID，没看到具体消费者和消息积压时长，根本没法判断是网络抖动还是消费者彻底挂了。
- 加参数才能看清全貌：
XPENDING stream:logs mygroup - + 10 consumerA，表示查 consumerA 最近 10 条未 ACK 的消息（ID 范围从最小到最大） - 加上
_IDLE参数可筛选“卡住超过 60 秒”的消息：XPENDING stream:logs mygroup - + 10 consumerA 60000 - 注意：Redis 5.0.5 不支持
XPENDING的COUNT+TIME组合过滤，得靠客户端二次过滤
为什么不能只靠 XACK 解决堆积？
XACK 是清理 pending 的必要操作，但不是充分条件。很多团队加了 XACK 还是堆积，问题出在“确认时机”和“确认前提”上。
典型场景：消费者拿到消息后先写 DB，再发 XACK；但 DB 写入失败或超时，XACK 没发出去，消息就永远留在 PEL 里，还会被 XAUTOCLAIM（Redis 6.2+）或手动 XCLAIM 反复重发。
- 必须确保
XACK在业务逻辑真正成功后才调用，不能放在 try 块末尾就完事——异常分支可能跳过 - 不要在消费逻辑里做耗时操作（如远程 HTTP 调用），否则
IDLE时间一到就被系统认为“卡死”，触发重复投递 - Redis 5.0.5 没有
XAUTOCLAIM，得自己定时轮询XPENDING+XCLAIM，否则宕机消费者的消息会一直锁死
如何安全地把卡住的消息转给其他消费者？
用 XCLAIM 抢消息本质是“强占”，不是协作。搞错参数容易导致消息被重复处理，甚至丢失 ACK 状态。
最容易踩的坑是忽略 MIN-IDLE-TIME 和 RETRYCOUNT ——前者决定“等多久才允许抢”，后者影响是否清空 retry 计数。这两个值不设好，可能刚抢过来又被另一个消费者立刻抢走，形成震荡。
- 推荐命令：
XCLAIM stream:logs mygroup newconsumer 3600000 167890123456789-0 RETRYCOUNT 1 FORCE -
3600000表示只抢 IDLE 超过 1 小时的消息，避免误抢刚卡住的正常消息 -
FORCE必须加，否则 Redis 5.0.5 会拒绝非原消费者发起的 claim（报错NOGROUP或NOACK） - 抢完别忘了立刻
XACK，否则下一轮又会被抢
监控 pending 消息时，前端加载策略怎么配才不崩？
百万级 pending 消息直接 XPENDING ... + 10000 会拖慢 Redis 主线程，且前端渲染卡死。Tiny RDM 那套“按需加载 + 虚拟滚动”不是炫技，是刚需。
真实线上环境里，一个消费者组 pending 上万条很常见，但你永远不该一次性拉全。重点不是“看到全部”，而是“快速定位异常区间”。
- 自动刷新间隔别设太短（比如 1s），
XPENDING频繁扫描 PEL 会放大主线程压力 - “加载更多”按钮背后应限制每次最多取 50 条，并按
IDLE降序排，优先看最老的几条 - 如果发现某消费者 pending 数持续 > 1000 且
IDLE中位数 > 5min，基本可以判定它已失联，该下线重启，而不是继续喂消息
事情说清了就结束。Redis 5.0.5 的 Stream 没有自动重平衡、没有 auto-claim、PEL 状态也不对外暴露时间戳字段——所有“智能”都得你自己补。别指望一条命令解决堆积，得把 XPENDING 当成听诊器，而不是手术刀。
