根本原因是xack调用太晚、太散、太随意；消息入pel后未在业务真正成功后立即批量确认，且未配合minid安全裁剪stream。
为什么XPENDING查出来一堆消息，但XACK后还是堆积？
根本原因不是没调XACK，而是调得太晚、太散、太随意。调用XREADGROUP后，消息立刻进PEL（Pending Entries List），Redis不等你处理完，也不管你是否崩溃——只要没XACK，它就一直占内存、可被XPENDING查到、还能被XCLAIM抢走。
常见错误包括：
- 在消费逻辑末尾无条件
XACK，但业务失败时跳过了这步（比如DB写入失败、HTTP超时） - 每条消息都单独发一次
XACK，高吞吐下Redis写AOF压力陡增，反而拖慢ACK速度 - 把
XACK放在异步线程里执行，主线程已退出，连接关闭，命令根本没发出去
怎么用XPENDING精准定位卡死的消息？
XPENDING本身不返回消息内容，只给元信息；不加参数等于白查。必须带范围、消费者名和IDLE阈值才能判断是临时卡顿还是彻底失联。
推荐组合命令：
-
XPENDING mystream mygroup - + 10：查所有pending中最新的10条，看ID分布是否集中 -
XPENDING mystream mygroup - + 10 consumerA 60000：只查consumerA中空闲超60秒的消息（避免误判刚启动的消费者） -
XPENDING mystream mygroup（无其他参数）：只返回总量、最小ID、最大ID、消费者数——适合定时巡检，不适合排障
注意：XPENDING在Redis 5.0.5不支持COUNT+TIME联合过滤，客户端得自己筛。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
批量XACK和XCLAIM的参数陷阱
单条XACK在万级TPS场景下会成为瓶颈；但批量操作又容易因参数错位导致部分失败或漏处理。
关键点：
-
XACK mystream mygroup id1 id2 id3：ID必须是XPENDING返回的真实ID格式（如167890123456789-0），不能截断或补零 -
XCLAIM抢消息必须加FORCE（尤其Redis 5.0.5），否则非原消费者调用直接报NOACK -
XCLAIM务必设MIN-IDLE-TIME（如3600000）和RETRYCOUNT，否则可能刚抢过来又被别人抢走，形成震荡 - 别混用
XAUTOCLAIM（Redis 6.2+）和手动XCLAIM，策略冲突会导致pending状态混乱
清理Pending不能只靠XACK，得配合MINID裁剪
XACK只是释放PEL里的条目，但Stream本身还在涨。如果历史消息从未被任何组确认过，MAXLEN会误删未消费消息，而MINID才是安全边界。
操作步骤：
- 对每个消费者组跑
XPENDING mystream mygroup，拿到最小pending ID → 它的前一个ID就是该组“已处理位置” - 取所有组中“已处理位置”的最小值，即全局安全删除点
- 执行
XTRIM mystream MINID ~<safe_id></safe_id>（Redis 6.2+，加~提升性能）
Spring Data Redis不封装XTRIM带MINID的变体，得用redisTemplate.execute()调Lua脚本计算并执行——这点最容易被忽略，硬编码MAXLEN裁剪等于埋雷。
