Redis高级特性之Pub/Sub与Stream

在Stream之前，Redis PUB/SUB亦可可实现消息的传递及广播，但消息不支持持久化，不记录消费端状态，并且“Fire and Forgot”，可靠性无法保证。

stream与pub/sub的比较：

1.stream简介

Redis Stream借鉴了Kafka的设计，支持多播和消费群组机制，支持消息持久化。底层基于基数树(radix-tree)和listpack实现，保证高效的内存利用及消息获取。另外，Stream机制不仅对消息进行持久化，对消费组状态也有持久化及主备同步，即使发生服务重启或主备切换，消费组的状态也能持续。

Redis Stream对应的命令字如下：

2、主要数据结构

2.1. 消息ID streamID

消息ID是一个time-seq的结构，时间戳是毫秒的时间，seq是在同一毫秒内消息的seq。

2.2. 消息队列stream

stream消息队列用stream结构表示，队列名字就是db里面的key。

2. 3消费组 streamCG

2.4 消费者streamConsumer

2.5

Stream的结构如上图所示，消息内容存储在消息链表里，每个消息都有一个唯一的streamID及消息内容。Stream都有唯一的名称，也就是Redis的key，在第一次使用xadd指令时自动创建。在调用xadd的指令时可以指定stream消息队列最大长度maxlen。当消息数量超过maxlen，会将老的消息淘汰掉，以确保Stream的消息链表不会过长。

Stream都可以挂多个消费组，每个消费组会有游标last_id表示当前消费组已经消费到哪条消息了。消费组名称唯一，需要使用xgroup create进行创建，需要指定从哪个消息ID开始消费，并用这个ID用来初始化last_id变量。

每个消费组内可以有多个消费者(Consumer)，同组内的消费者之间是竞争关系，每个消费者消费的消息是不同的，任意一个消费者读取了消息都会使游标last_id往前移动。

消费者(Consumer)内部的pending_list，记录了已经被读取但没有ACK的消息。如果客户端没有ack，这个变量里面的消息ID会越来越多，一旦某个消息被ack，它就开始减少。这个pending_ids变量在Redis官方被称之为PEL，也就是Pending Entries List，这是一个很核心的数据结构，它用来确保客户端至少消费了消息一次，而不会在网络传输的中途丢失了没处理