Redis 5.0引入的Stream是近年Redis新增数据结构中最受关注的一个。它并非简单地把List升级一下，而是从设计之初就瞄准了消息队列和事件流场景，提供了消息ID、消费组、确认机制等此前只有专门消息中间件才具备的能力。Stream在Redis内部被实现为一个仅追加的日志结构，每个条目都包含一个全局唯一的ID和一组字段值，ID由毫秒时间戳加序列号组成，保证了消息的顺序性。这种设计让Stream既能像日志一样持久化存储，又能像Kafka一样支持多消费者协同工作，同时依然保持了Redis的内存操作速度和极低的复杂度。

要理解Stream的价值，先看它和List的本质区别。List虽然也能用LPUSH/RPOP实现简单的生产者消费者模型，但有几个硬伤：没有消息ID，不支持消费组，没有确认机制，消费失败后消息会丢失，而且阻塞弹出的方式只能一对一。Stream解决了这些问题，它的每条消息都有唯一ID，消费者可以通过XACK确认处理完成，未确认的消息可以在消费者崩溃后重新投递给其他消费者。同时Stream支持多消费者组，每个组独立维护消费进度，组内多个消费者可以并行消费，实现了类似Kafka的负载均衡和容错能力。这些特性让Redis从此可以承担更多实时数据管道的职责，而不仅仅是缓存。

Stream的内部结构与消息ID

Stream的底层采用了一种混合数据结构：Radix Tree（基数树）用于索引消息ID，Listpack（紧凑列表）用于存储同一条消息的字段和值。每个Stream本质上是一个Rax树，树的节点按消息ID排序，叶子节点指向一个Listpack，里面存放该消息的所有字段-值对。这种设计既保证了按ID范围查询的效率，又大幅减少了内存碎片和指针开销。在Redis 5.0中，Stream的每个条目最多可以包含数百万个字段，但实际使用时不建议一个消息过大，否则会影响Rax树的平衡和内存回收效率。

消息ID是Stream的核心概念，格式为millisecondsTime-sequenceNumber，例如1526569495631-0。毫秒时间戳部分由服务器本地时间生成，序列号用于区分同一毫秒内的多条消息。如果客户端用*代替ID，Redis会自动生成；也可以指定时间戳部分，保留序列号为空，Redis会自动补0。消息ID必须是递增的，否则XADD命令会报错，这一约束保证了Stream内消息的全局有序性。需要注意的是，时间戳基于Redis服务器的系统时钟，如果时钟发生回拨，新生成的ID可能小于已有ID，此时Redis会使用当前最大ID的时间戳继续递增，避免ID冲突。

Stream的内存管理上有一个重要机制：消息删除。与List不同，Stream中的消息不能单独删除某一条，只能通过XDEL标记删除，但不会立即释放内存，只有在该消息所在的Listpack整体被裁剪时才会真正回收。更常用的做法是通过MAXLEN参数或XTRIM命令限制Stream的长度，例如XADD mystream MAXLEN 1000 * field value会在添加新消息后自动修剪到只保留最新的1000条。这种截断操作是按整个Listpack为单位进行的，因此可能存在少量超额，但Redis保证了近似长度控制，适合大多数流式场景。

核心命令与消息消费模式

向Stream写入消息使用XADD命令，格式为XADD key [NOMKSTREAM] [MAXLEN|MINID [=|~] threshold] <*|id> field value [field value ...]。最简形式是XADD mystream * sensor_id 1234 temperature 19.8，返回生成的消息ID。如果希望消息不重复，可以指定ID，比如XADD mystream 1526569495631-0 sensor_id 1234。生产环境通常使用*自动生成ID，并配合MAXLEN ~ 10000做近似裁剪，既能控制内存，又避免频繁精确裁剪带来的性能损耗。

读取消息有三个层次的命令。XRANGE和XREVRANGE用于按ID范围查询，例如XRANGE mystream - + COUNT 5返回最早的5条消息。XREAD支持阻塞读取，可以监听多个Stream的新消息，典型用法是XREAD BLOCK 0 STREAMS mystream $，其中$表示从最新的下一条开始，阻塞等待新消息到达。这种模式适合实现一个简单的尾随消费者，但如果有多个消费者，需要使用消费组。XREADGROUP配合XGROUP CREATE才能实现组内竞争消费和消息确认。下面是一个完整的消费者组使用示例：

# 创建消费者组
XGROUP CREATE mystream mygroup $
# 消费者1读取一条未分配给其他消费者的消息
XREADGROUP GROUP mygroup consumer1 COUNT 1 STREAMS mystream >
# 处理完成后确认消息
XACK mystream mygroup 1526569495631-0
# 查看消费者组状态
XINFO GROUPS mystream

注意XREADGROUP中的>符号表示只读取从未投递过的消息。如果消费者处理失败，可以不发送XACK，然后使用XPENDING查看未确认的消息，并通过XCLAIM将超时的未确认消息转移给其他消费者。这一套机制让Redis Stream拥有了可靠的至少一次投递语义，虽然不保证完全去重，但配合业务层的幂等处理，可以构建相当稳定的消息管道。

消费组机制与故障恢复

消费组是Stream区别于其他Redis数据结构的关键设计。每个消费组记录了组内所有消费者的最后投递消息ID、待确认消息列表（PEL）以及组内消费者名称。当使用XREADGROUP GROUP gname cname STREAMS key >时，Redis会从组的待投递ID开始扫描，跳过已经分配给其他消费者但尚未确认的消息，将新的消息分配给当前消费者，并把该消息ID加入消费者的PEL。这种设计天然支持多条消息并行处理，且不会重复投递给同一个消费者（除非显式使用XCLAIM）。

故障恢复的场景非常经典：假设消费者在读取消息后崩溃，消息留在PEL中未确认。另一个消费者或原消费者恢复后，可以通过XPENDING key group start end count查看未确认消息的详情，包括空闲时间。如果空闲时间超过阈值，可以使用XCLAIM key group consumer min-idle-time id将消息的所有权转移给自己，然后重新处理。这比简单的阻塞队列健壮得多，几乎可以等同于Kafka的消费者组重平衡机制，只是实现更加轻量，不需要额外的协调节点。

# 查看未确认消息
XPENDING mystream mygroup - + 10
# 将空闲超过60秒的消息转移给consumer2
XCLAIM mystream mygroup consumer2 60000 1526569495631-0
# 查看整个组的信息
XINFO GROUPS mystream
XINFO CONSUMERS mystream mygroup

需要留意的是，消费组的进度保存在Redis内部，占用少量内存。如果一个消费组长期不消费，消息会积压在Stream中，除非使用MAXLEN裁剪，否则内存会持续增长。因此生产环境建议为每个Stream设置合理的MAXLEN，或者定期执行XTRIM。如果多个消费组订阅同一个Stream，它们各自的消费进度独立，一条消息可以被多个组各自消费一次，但组内只有一个消费者会收到，这是与Kafka分区模型略有不同的地方——Redis Stream没有分区，所有消费者共读一个Stream，靠组内分配实现并行，消息量特别大时单Stream可能成为瓶颈。

实际应用与性能调优建议

Redis Stream最典型的应用场景包括轻量级消息队列、事件溯源、日志收集和实时数据管道。比如一个物联网平台可以用Stream存储设备上报的时序数据，通过消费者组将数据分流到实时告警、历史存储和数据分析等多个下游。由于Stream支持阻塞读取，前端可以直接用XREAD做一个长轮询接口，替代传统轮询数据库的方式，大幅降低延迟和无效请求。另一个常见用法是作为任务队列，生产者XADD任务描述，多个消费者通过XREADGROUP竞争获取任务，完成任务后XACK确认，实现分布式任务调度。

性能方面，Stream的XADD操作时间复杂度是O(1)（忽略Rax树可能的节点分裂，实际接近O(log N)但常数极小），XREAD也是O(M)（M为返回消息数），单实例每秒可以处理数十万条消息写入。但有两个性能陷阱需要注意：一是不要频繁使用精确MAXLEN（不带~），因为精确裁剪需要遍历并删除旧的Listpack，成本随删除条目数线性增长，而近似裁剪MAXLEN ~ n仅删除整个Listpack节点，非常高效；二是避免在Stream中存储超大消息，单个消息过大时会撑大Listpack，导致内存碎片和Rax树查找变慢，建议将大文件或二进制数据放在对象存储，Stream中只保留元数据或引用。

与专门的消息中间件相比，Redis Stream的优势在于部署简单、响应快、和Redis其他数据结构无缝集成，适合中小规模、对延迟敏感的场景。对于需要万亿级消息持久化、严格顺序保证或跨数据中心复制的场景，Kafka或RabbitMQ仍然是更合适的选择。Redis 7.0对Stream做了一些优化，但本文讨论的5.0版本已经包含了Stream最核心的功能，后续版本主要增加了更高效的内部表示和更多统计命令。理解Stream的底层设计和消费组机制，可以帮助开发者在架构选型时做出更精准的判断，避免把Redis当作万能的消息队列滥用。

最后给一个生产环境配置文件片段作为参考，展示Stream结合Lua脚本和过期时间的用法：

-- 原子性地添加消息并设置消息TTL
local stream_key = KEYS[1]
local id = redis.call('XADD', stream_key, 'MAXLEN', '~', 10000, '*', 'data', ARGV[1])
redis.call('PEXPIRE', stream_key, 3600000)
return id

这个脚本将消息写入Stream的同时设置了整个Key的过期时间，适用于保留最近一小时数据的场景。注意Lua脚本中的MAXLEN ~ 10000是近似裁剪，性能更好。整体而言，Redis Stream填补了Redis在消息领域的空白，让开发者可以用一套基础设施解决缓存、队列和流处理多种需求。