Redis 6 的 Stream 并非新增类型，而是对 Redis 5.0 引入的 Stream 在消费者组、连接模型和 ACL 权限方面增强，提升可靠性、可运维性与可扩展性；其核心优势在于持久化、唯一ID生成、多消费者组广播、负载均衡及ACK机制，远超Pub/Sub和List。
Stream 在 Redis 6 中不是新增类型（它从 Redis 5.0 就已引入），但 Redis 6 对其消费者组、连接模型和 ACL 权限控制做了增强，实际落地更稳。它解决的不是“能不能用”，而是“怎么用得可靠、可运维、可扩展”。
为什么不用 Pub/Sub 或 List 做消息队列？
直接上 Stream 的核心动因就在这儿：PUB/SUB 不持久、断连丢消息；LPUSH+BRPOP 无法重复消费、无消费进度追踪、无 ACK 机制。而 Stream 天然支持：
- 消息写入即落盘（AOF/RDB 持久化保障）
-
XADD自动生成单调递增 ID（毫秒时间戳 + 序号），无需业务生成全局唯一 ID - 单条消息可被多个消费者组同时读取（广播能力）
- 消费者组内支持负载均衡、失败重试、未确认消息监控（
XPENDING）
真实生产中三个高频场景
不是“理论上能做”，而是你上线后大概率会踩到的点：
-
订单履约链路解耦：支付服务
XADD order_stream *写入订单事件，积分服务、物流服务、风控服务各自用XREADGROUP接入不同消费者组，互不影响；某服务宕机后重启，从上次LAST_DELIVERED_ID继续消费，不丢不重 -
操作审计日志归集：所有修改用户资料的请求，统一
XADD audit_log *记录变更前/后快照；后台定时用XRANGE拉取指定时间段日志做合规检查，或用XTRIM按长度保留最近 100 万条 -
IoT 设备时序数据缓冲：设备端高频上报（如每秒 10 条温湿度），
XADD sensor:123 *追加；聚合服务用XREAD BLOCK 5000 STREAMS sensor:123 $阻塞拉取新数据，避免轮询压 Redis
XREADGROUP 和 XREAD 到底选哪个？
关键区别不在命令本身，而在是否需要「消费协同」：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
XREAD：适合单消费者、无状态、只关心“最新消息”的场景（比如监控告警服务，只要最新一条异常就触发） - 用
XREADGROUP：必须建组（XGROUP CREATE），且每个消费者需声明名字；Redis 自动维护每个消费者的DELIVERED_ID和组内PENDING列表；一旦消费者崩溃，其他成员可通过XAUTOCLAIM接管未 ACK 消息 - 坑点：
XREADGROUP第一次调用必须带>（如STREAMS mystream >），表示“只读新消息”；若填具体 ID，则变成重放历史，容易重复处理
性能与容量边界要注意什么？
Stream 底层是 rax 树，插入/范围查询复杂度 O(log N)，但实际瓶颈常在别处：
- 单个
Stream不建议超过 1000 万条——不是不能存，而是XRANGE全量扫描变慢，XLEN耗时上升（虽然仍是 O(1)） - 用
XTRIM MAXLEN ~1000000主动限流，比等内存爆掉再DEL更可控 - 消费者组数量不宜过多（>50 个），每个组都维护独立游标，增加内存开销；高频写入+多组消费时，优先考虑分片 Stream（如按 user_id % 16 分 stream_0 ~ stream_15）
真正难的不是命令怎么敲，而是设计消费组生命周期、定义消息体结构（建议扁平 JSON，避免嵌套导致 XREAD 解析负担）、以及把 XACK 放在业务逻辑真正完成之后——漏掉这步，消息就会卡在 PENDING 状态里，越积越多。
