redis pub/sub不支持消息堆积，因消息不持久化且未消费即丢失；可靠传递需改用stream并利用pel机制：xreadgroup派发消息入pel，xack确认，xpending监控，xclaim转移超时消息。
Redis PUB/SUB 本身无法处理消息堆积——它压根不存消息，所谓“堆积”只是误用导致的幻觉。真要解决大批量消息可靠传递，必须切换到 Stream，并正确使用其 PEL（Pending Entries List）机制。
为什么 PUB/SUB 根本不存在“堆积”问题
PUB/SUB 是纯内存广播通道，PUBLISH 一发出去，没被即时消费就永远丢失：SUBSCRIBE 客户端掉线、网络抖动、重启，消息全归零。你看到的“堆积”，其实是业务层自己缓存或重试造成的假象，Redis 自身毫无感知。
常见错误现象包括：
- 监控显示
PUBSUB NUMSUB channel有订阅者，但实际收不到消息（可能已断连未清理） - 用
PSUBSCRIBE模式订阅后漏消息（模式匹配不生效或客户端未保持连接） - 试图用
CLIENT LIST查“未消费消息数”——结果永远是 0，因为根本没地方存
Stream 的 PEL 是怎么防止消息丢失的
PEL（Pending Entries List）是每个消费者组（consumer group）内部维护的待确认消息列表，本质是“已派发但未 XACK”的消息队列。只要消息进了 Stream，哪怕消费者宕机，PEL 也会保留它，直到显式确认或超时淘汰。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键行为：
-
XREADGROUP读取消息时，自动将消息加入该 consumer 的 PEL； - 消费者处理完必须调用
XACK stream_name group_name id，否则消息一直留在 PEL； - 可用
XCLAIM把超时未确认的消息转给其他 consumer 继续处理； -
XPENDING能查出所有卡在 PEL 里的消息 ID、所属 consumer、空闲时间等； - PEL 不受
Stream主体过期影响——即使你设置了MAXLEN或用XRANGE清理历史，PEL 中的 pending 消息仍保留。
从 PUB/SUB 切到 Stream 的实操要点
这不是配置开关，而是代码和流程重构。重点不是“怎么写命令”，而是“怎么不丢数据”：
- 生产端：把
PUBLISH channel msg全部替换成XADD stream_name * field value；不要手动生成 ID，用*让 Redis 生成带时间戳的唯一 ID； - 初始化消费者组：用
XGROUP CREATE stream_name group_name $（从最新开始）或0-0（从头开始），别漏掉MKSTREAM参数，否则 stream 不存在会报错； - 消费逻辑必须包含异常兜底：收到消息后先做业务处理，成功再发
XACK；失败则不XACK，靠XPENDING+XCLAIM后续捞回； - 旧 List 队列迁移时，务必等
LLEN old_queue返回0且所有新消息都经 Stream 稳定流转 24 小时以上，再下线旧路径； - 监控项要加两条：
XPENDING stream_name group_name的返回长度（判断积压）、XINFO GROUPS stream_name中pel-count字段（确认 PEL 总量）。
容易被忽略的 PEL 边界情况
PEL 看似可靠，但几个细节不注意就会绕回“消息丢失”老路：
- 消费者进程崩溃前没来得及
XACK，重启后若没调用XREADGROUP带NOACK，会重复消费——但这是设计使然，不是 bug； -
XCLAIM需指定最小空闲时间（MINIDLE），设太小会导致频繁争抢，设太大又拖慢故障恢复； - 一个 consumer 在 PEL 里积压太多消息，可能触发 Redis 内存警戒线，需配合
MAXLEN ~控制 Stream 总长度，但 PEL 不受此限； - 没有消费者组的
XREAD模式不产生 PEL，也就没有消息保障——必须用XREADGROUP。
真正难的不是命令怎么敲，而是把“消息必须被某人处理一次”这个语义，完整映射到 XGROUP / XREADGROUP / XACK / XPENDING 这整套协作逻辑里。少一个环节，就回到 PUB/SUB 的裸奔状态。
