redis stream 比 pub/sub 更适合做持久化队列，因其支持消息持久化、消费者组、ack 机制、唯一消息id和按位置回溯；pub/sub纯内存广播，无存储、无堆积能力。
Redis Stream 为什么比 PUB/SUB 更适合做持久化队列
PUB/SUB 根本不存消息，客户端掉线就丢，根本谈不上“堆积”——它压根没地方堆。Stream 才是 Redis 里唯一带持久化、有游标、能回溯的发布订阅式数据结构。
关键区别在于：PUB/SUB 是纯内存广播，Stream 是带日志语义的有序队列。你不是在“修复堆积”，而是在“换掉不适合的工具”。
-
XADD写入时自动持久化到 AOF/RDB，重启不丢 -
XREADGROUP支持消费者组 + ACK 机制，未确认消息可重读 - 每个消息有唯一
ID（如1698765432100-0），天然支持按时间/位置定位 - Stream 可设最大长度（
MAXLEN），防止无限制膨胀，但需主动配，不设就无限存
如何用 XREADGROUP 实现“不丢消息”的消费逻辑
别用 XREAD，它没消费者组概念，无法标记谁读了哪条。必须上 XREADGROUP，且首次读前得先 XGROUP CREATE 建组。
常见错误：建组时漏掉 START 参数，导致新消费者从头开始拉取——线上一建组就刷出几万条历史消息，直接把下游打挂。
- 建组命令：
XGROUP CREATE mystream mygroup $ MKSTREAM（$表示从最新开始，0才是从头） - 消费命令：
XREADGROUP GROUP mygroup consumer1 COUNT 10 STREAMS mystream >（>表示只读新消息） - 处理完必须调
XACK mystream mygroup <id></id>，否则同一条会反复推给该消费者 - 不
XACK的消息会在XPENDING中累积，可用XPENDING mystream mygroup - + 10查看卡住的消息
消息堆积了怎么安全清理或限流
Stream 不像 Kafka 有自动过期，它靠 MAXLEN 或手动裁剪。但直接 XTRIM 会丢数据，得看场景选策略。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
如果业务允许丢老消息（比如监控指标），建 Stream 时就加 MAXLEN ~；如果不能丢，就得靠消费者组 + XACK 推进读取位置，让 Redis 自动释放已确认段。
- 建流时限制长度：
XADD mystream MAXLEN ~ 10000 * field value（~表示近似裁剪，性能更好） - 运行中裁剪：
XTRIM mystream MAXLEN 5000，注意这会强制删除最老的，不管是否被 ACK - 查堆积量：
XINFO STREAM mystream看length和groups下各组的pending数 - 消费者处理慢？别硬扛，加
COUNT限单次拉取条数，再用循环+延时控制节奏
PHP/Python 客户端连 Stream 容易踩的坑
官方 redis-py 和 predis 都支持 Stream，但默认不启用新命令别名，有些旧版本甚至没实现 XREADGROUP。
PHP 用 predis 要确认版本 ≥ 1.1.9；Python 用 redis-py 要 ≥ 3.5.0，且别用 redis.Redis().xread() 这种老接口——它不支持消费者组。
- Python 正确写法：
r.xreadgroup('mygroup', 'c1', {'mystream': '>'}, count=1) - PHP 正确写法：
$redis->xreadgroup('mygroup', 'c1', ['mystream' => '>'], 1) - 所有客户端调
XACK前，必须确保消息 ID 是从本次XREADGROUP返回的，别自己拼ID - 网络中断后重连，别直接继续
XREADGROUP，先用XPENDING拿未确认 ID，补XACK或重试
Stream 的“堆积”本质是消费进度落后，不是数据本身有问题。真正难的不是写入或读取，而是让每个消费者稳定推进自己的 last_delivered_id，并且在故障时知道该从哪 resume —— 这部分逻辑得自己兜底，Redis 不替你记。
