Redis队列Stream、Redis多线程详解（一）

Redis队列与Stream

Redis5.0 最大的新特性就是多出了一个数据结构 Stream，它是一个新的强大的支持多播的可持久化的消息队列，作者声明Redis Stream地借鉴了 Kafka 的设计。

Redis Stream 的结构如上图所示,每一个Stream都有一个消息链表，将所有加入的消息都串起来，每个消息都有一个唯一的 ID 和对应的内容。消息是持久化的，Redis 重启后，内容还在。

每个 Stream 都有唯一的名称，它就是 Redis 的 key，在我们首次使用xadd指令追加消息时自动创建。

每个 Stream 都可以挂多个消费组，每个消费组会有个游标last_delivered_id在 Stream 数组之上往前移动，表示当前消费组已经消费到哪条消息了。每个消费组都有一个 Stream 内唯一的名称，消费组不会自动创建，它需要单独的指令xgroup create进行创建，需要指定从 Stream 的某个消息 ID 开始消费，这个 ID 用来初始化last_delivered_id变量。

每个消费组 (Consumer Group) 的状态都是独立的，相互不受影响。也就是说同一份 Stream 内部的消息会被每个消费组都消费到。

同一个消费组 (Consumer Group) 可以挂接多个消费者 (Consumer)，这些消费者之间是竞争关系，任意一个消费者读取了消息都会使游标last_delivered_id往前移动。每个消费者有一个组内唯一名称。

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

消息 ID 的形式是timestampInMillis-sequence，例如1527846880572-5，它表示当前的消息在毫米时间戳1527846880572时产生，并且是该毫秒内产生的第 5 条消息。消息 ID 可以由服务器自动生成，也可以由客户端自己指定，但是形式必须是整数-整数，而且必须是后面加入的消息的 ID 要大于前面的消息 ID。

消息内容就是键值对，形如 hash 结构的键值对，这没什么特别之处。

常用操作命令

生产端

xadd 追加消息

xdel 删除消息，这里的删除仅仅是设置了标志位，不会实际删除消息。

xrange 获取消息列表，会自动过滤已经删除的消息

xlen 消息长度

del 删除 Stream

xadd streamtest * name mark age 18

 

streamtest 表示当前这个队列的名字，也就是我们一般意义上Redis中的key，* 号表示服务器自动生成 ID，后面顺序跟着“name mark age 18”，是我们存入当前streamtest 这个队列的消息，采用的也是 key/value的存储形式

返回值1626705954593-0 则是生成的消息 ID，由两部分组成：时间戳-序号。时间戳时毫秒级单位，是生成消息的Redis服务器时间，它是个64位整型。序号是在这个毫秒时间点内的消息序号。它也是个64位整型。

为了保证消息是有序的，因此Redis生成的ID是单调递增有序的。由于ID中包含时间戳部分，为了避免服务器时间错误而带来的问题（例如服务器时间延后了），Redis的每个Stream类型数据都维护一个latest_generated_id属性，用于记录最后一个消息的ID。若发现当前时间戳退后（小于latest_generated_id所记录的），则采用时间戳不变而序号递增的方案来作为新消息ID（这也是序号为什么使用int64的原因，保证有足够多的的序号），从而保证ID的单调递增性质。

如果不是非常特别的需求，强烈建议使用Redis的方案生成消息ID，因为这种时间戳+序号的单调递增的ID方案，几乎可以满足全部的需求，但ID是支持自定义的。

 

xrange streamtest - +

其中-表示最小值 , + 表示最大值

 或者我们可以指定消息 ID 的列表：

 xdel streamtest 1626706380924-0

xlen streamtest

 

del streamtest 删除整个 Stream

 消费端

单消费者

虽然Stream中有消费者组的概念，但是可以在不定义消费组的情况下进行 Stream 消息的独立消费，当 Stream 没有新消息时，甚至可以阻塞等待。Redis 设计了一个单独的消费指令xread，可以将 Stream 当成普通的消息队列 (list) 来使用。使用 xread 时，我们可以完全忽略消费组 (Consumer Group) 的存在，就好比 Stream 就是一个普通的列表 (list)。

xread count 1 streams stream2 0-0

“count 1”表示从 Stream 读取1条消息，缺省当然是头部，“streams”可以理解为Redis关键字，“stream2”指明了要读取的队列名称，“0-0”指从头开始

 

xread count 2 streams stream2 1626710882927-0

也可以指定从streams的消息Id开始(不包括命令中的消息id)

 

xread count 1 streams stream2 $

$代表从尾部读取，上面的意思就是从尾部读取最新的一条消息,此时默认不返回任何消息

 

所以最好以阻塞的方式读取尾部最新的一条消息，直到新的消息的到来

xread block 0 count 1 streams stream2 $

block后面的数字代表阻塞时间，单位毫秒

 此时我们新开一个客户端，往stream2中写入一条消息

 可以看到阻塞解除了，返回了新的消息内容，而且还显示了一个等待时间，这里我们等待了127.87s

 一般来说客户端如果想要使用 xread 进行顺序消费，一定要记住当前消费到哪里了，也就是返回的消息 ID。下次继续调用 xread 时，将上次返回的最后一个消息 ID 作为参数传递进去，就可以继续消费后续的消息。

消费组

创建消费组

Stream 通过xgroup create指令创建消费组 (Consumer Group)，需要传递起始消息 ID 参数用来初始化last_delivered_id变量。

xgroup create stream2 cg1 0-0

“stream2”指明了要读取的队列名称，“cg1”表示消费组的名称，“0-0”表示从头开始消费

 

xgroup create stream2 cg2 $

$ 表示从尾部开始消费，只接受新消息，当前 Stream 消息会全部忽略

 

现在我们可以用xinfo命令来看看stream2的情况：

xinfo stream stream2

 xinfo groups stream2

 消息消费

有了消费组，自然还需要消费者，Stream 提供了 xreadgroup 指令可以进行消费组的组内消费，需要提供消费组名称、消费者名称和起始消息 ID。

它同 xread 一样，也可以阻塞等待新消息。读到新消息后，对应的消息 ID 就会进入消费者的PEL(正在处理的消息) 结构里，客户端处理完毕后使用 xack 指令通知服务器，本条消息已经处理完毕，该消息 ID 就会从 PEL 中移除。

xreadgroup GROUP cg1 c1 count 1 streams stream2 >

“GROUP”属于关键字，“cg1”是消费组名称，“c1”是消费者名称，“count 1”指明了消费数量，> 号表示从当前消费组的 last_delivered_id 后面开始读，每当消费者读取一条消息，last_delivered_id 变量就会前进

 

前面我们定义cg1的时候是从头开始消费的，自然就获得Stream2中第一条消息

再执行一次上面的命令

 

自然就读取到了下条消息。

我们将Stream2中的消息读取完

xreadgroup GROUP cg1 c1 count 2 streams stream2 >

很自然就没有消息可读了， xreadgroup GROUP cg1 c1 count 1 streams stream2 >

 

然后设置阻塞等待

xreadgroup GROUP cg1 c1 block 0 count 1 streams stream2 >

 

我们新开一个客户端，发送消息到stream2

xadd stream2 * name lison score 98

 回到原来的客户端，发现阻塞解除，收到新消息

 

我们来观察一下观察消费组状态

 

如果同一个消费组有多个消费者，我们还可以通过 xinfo consumers 指令观察每个消费者的状态

xinfo consumers stream2 cg1

可以看到目前c1这个消费者有 5 条待ACK的消息，空闲了441340 ms 没有读取消息。

如果我们确认一条消息

xack stream2 cg1 1626751586744-0

就可以看到待确认消息变成了4条

 xack允许带多个消息id，比如

 

同时Stream还提供了命令XPENDIING 用来获消费组或消费内消费者的未处理完毕的消息，每个Pending的消息有4个属性：

消息ID

所属消费者

IDLE，已读取时长

delivery counter，消息被读取次数

命令XCLAIM用以进行消息转移的操作，将某个消息转移到自己的Pending列表中。需要设置组、转移的目标消费者和消息ID，同时需要提供IDLE（已被读取时长），只有超过这个时长，才能被转移。

更多的Redis的Stream命令请大家参考Redis官方文档：

https://redis.io/topics/streams-intro

Commands | Redis

同时Redis文档中，在每个命令的详情页右边会显示“Related commands”，可以通过这个列表快速了解相关的命令和进入具体命令的详情页。