redis stream消息堆积主因是未设清理边界和未管好ack时机；xreadgroup后消息即入pel，不调xack则永久占用内存，且需用minid而非maxlen安全裁剪，批量xack可降压。
Redis Stream 消息堆积不是“处理太慢”导致的，而是“没设清理边界”+“没管好 ACK 时机”共同造成的。不改这两点，加机器、调线程都白搭。
为什么 XREADGROUP 不 ACK 就会堆积 pending 消息
调用 XREADGROUP 后，消息立刻进入该消费者组的 Pending Entries List（PEL），哪怕你根本没开始处理。Redis 不关心你是否崩溃、卡住或忘记确认——只要没调 XACK，这条消息就永远留在 PEL 里，且持续占用内存。
- PEL 中的消息仍可被
XPENDING查到，也能被XCLAIM转交，但不会自动释放 - 同一个消息 ID 可能被重复分配给不同消费者（比如超时未 ACK），加剧混乱
-
XPENDING mystream mygroup - + 10能查出卡住的消息，但查出来不处理，等于没监控
建消费者组时漏掉 $ 或 0 导致全量重放
执行 XGROUP CREATE mystream mygroup $ MKSTREAM 是生产环境唯一安全的起点。用 0 表示从头读，上线瞬间可能拉出几万条历史消息，压垮下游服务。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
$表示“从创建组之后的新消息开始”，避免历史数据冲击 - 如果真要回溯，应先用
XINFO STREAM mystream看当前最小 ID，再用XGROUP SETID mystream mygroup <id></id>精准定位 - Spring Boot 中通过
StreamOperations.createGroup()创建时，必须显式传入StreamOffset.fromStart()或StreamOffset.latest()，别依赖默认值
清理不能只靠 MAXLEN，得用 MINID + 定期裁剪
MAXLEN 是兜底手段，不是主策略。它按数量删，不管消息是否已被所有消费者 ACK，误删风险高；MINID 才是真正安全的清理方式——它按 ID 删除所有“已确认完成”的旧消息。
- 先查各组进度：
XPENDING mystream mygroup返回最老 pending ID，该组“已处理到的位置”就是这个 ID 的前一个 - 全局安全删除点 = 所有消费者组中“已处理位置”的最小值
- 执行
XTRIM mystream MINID ~<safe_id></safe_id>（Redis 6.2+），注意加~提升性能 - 若用 Spring Data Redis，需封装原生命令，
redisTemplate.execute()调用 Lua 脚本计算并裁剪
ACK 不批量、不延时，Redis 压力翻倍
每条消息单独调一次 XACK，在高吞吐场景下会显著拖慢消费速度，还可能触发 Redis 频繁写 AOF。
- 推荐每 10–50 条消息 batch 一次
XACK，用XACK mystream mygroup id1 id2 id3... - 延迟 ACK 更适合容错要求高的场景：处理完先暂存 ID 列表，由独立线程定时批量确认
- 别在消费逻辑里嵌套
XACK后立刻XRANGE查状态——这是典型循环依赖，容易锁死
真正卡住系统的，往往不是消息量大，而是没人定期检查 XPENDING 输出里的最小 pending ID，也没人把 XTRIM ... MINID 写进运维脚本。工具可以自动化，但边界判断必须人来定。
