redis pub/sub 不存在消息堆积，因它仅作内存广播且不存储消息；真需可靠传递应改用 stream，配合消费者组、pel 及 xack/xclaim 等机制保障。
Redis PUB/SUB 本身无法避免消息堆积——它压根不存消息，所谓“堆积”是误用或业务层兜底失败导致的假象。真要解决，必须换工具或换用法。
为什么 PUB/SUB 根本不存在“堆积”这回事
它只是内存广播：一旦 PUBLISH 发出去，没被当时在线的 SUBSCRIBE 客户端收走，就立刻丢弃，不落盘、不排队、不重试。
常见错觉来源：
• 客户端自己缓存了未处理消息，却误以为 Redis 在“堆积”
• 监控看到 PUBSUB NUMSUB channel 返回非零，就以为消息还在，其实连接可能早已断开未清理
• 用 CLIENT LIST 查“未消费数”，结果永远是 0——因为 Redis 真的没地方存
Stream 是唯一能真正解决可靠传递的替代方案
别试图给 PUB/SUB 加“防堆积”补丁，直接切到 Stream，并启用消费者组和 PEL（Pending Entries List）：
• 建流时加 MAXLEN ~ 10000 防无限制膨胀
• 必须先 XGROUP CREATE mystream mygroup $ MKSTREAM（$ 表示从最新开始，不是 0）
• 消费用 XREADGROUP GROUP mygroup consumer1 COUNT 10 STREAMS mystream >（> 表示只读新消息）
• 处理完必须 XACK mystream mygroup <id></id>，否则该消息会一直留在 PEL 中
• 卡住的消息用 XPENDING mystream mygroup - + 10 查，超时可 XCLAIM 转移
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
如果硬要用 PUB/SUB，只能靠外围手段压风险
这不是修复，而是降低丢消息概率的权宜之计：
• 频道命名尽量具体（如 order:paid），避免 PSUBSCRIBE order.* 这类宽泛模式，减少无效广播
• 控制单条消息体积，大字段走 SET + ID 引用，别塞进 PUBLISH
• 客户端必须实现自动重连 + 重订阅逻辑，断连后不能只等下次启动才恢复
• 设置 tcp-keepalive 和合理 timeout，防止僵尸连接占着频道却不收消息
• 用 INFO clients 和 PUBSUB NUMSUB 做简单巡检，但别信它能反映真实消费状态
Stream 的 XPENDING 和 XCLAIM 容易被忽略
很多人建了消费者组、用了 XREADGROUP，却忘了调 XACK，结果 PEL 持续增长，下游反复收到同一条消息；更麻烦的是，PEL 中消息默认永不超时，除非你主动 XCLAIM 或配置消费者组的 IDLE 参数（Redis 7.0+ 支持）。不查 XPENDING，你就永远不知道哪条消息卡住了、卡了多久、被谁卡住。
