Streams：深入剖析Redis5.0全新数据结构

原创：阿飞的博客

Redis 5.0 全新的数据类型：streams，官方把它定义为：以更抽象的方式建模日志的数据结构。Redis的streams主要是一个append only的数据结构，至少在概念上它是一种在内存中表示的抽象数据类型，只不过它们实现了更强大的操作，以克服日志文件本身的限制。

如果你了解MQ，那么可以把streams当做MQ。如果你还了解kafka，那么甚至可以把streams当做kafka。

另外，这个功能有点类似于redis以前的Pub/Sub，但是也有基本的不同：

streams支持多个客户端（消费者）等待数据（Linux环境开多个窗口执行XREAD即可模拟），并且每个客户端得到的是完全相同的数据。
Pub/Sub是发送忘记的方式，并且不存储任何数据；而streams模式下，所有消息被无限期追加在streams中，除非用于显示执行删除（XDEL）。
streams的Consumer Groups也是Pub/Sub无法实现的控制方式。

streams数据结构

streams数据结构本身非常简单，但是streams依然是Redis到目前为止最复杂的类型，其原因是实现的一些额外的功能：一系列的阻塞操作允许消费者等待生产者加入到streams的新数据。另外还有一个称为Consumer Groups的概念，这个概念最先由kafka提出，Redis有一个类似实现，和kafka的Consumer Groups的目的是一样的：允许一组客户端协调消费相同的信息流！

redis源码中定义streams结构的源码如下，由源码可知，stream的核心数据结构是radix tree：

typedef struct stream {

rax *rax; /* The radix tree holding the stream. */

uint64_t length; /* Number of elements inside this stream. */

streamID last_id; /* Zero if there are yet no items. */

rax *cgroups; /* Consumer groups dictionary: name -> streamCG */

} stream;

源码参考：https://github.com/antirez/redis/blob/5.0.0/src/stream.h；

至于redis对radix tree的实现，参考源码：https://github.com/antirez/redis/blob/5.0.0/src/rax.c 和 https://github.com/antirez/redis/blob/5.0.0/src/rax.h 。网上也有很多radix tree的文章，本篇文章就不做过多的介绍了。下面给出一张从官方源码中的部分截图：

radix tree

streams基础

为了理解streams的目的，以及如何使用它，我们先忽略掉所有高级特性，只把注意力放在数据结构本身，以及那些操作和访问streams的命令。这基本上也是大多数其他Redis数据类型共有的部分，例如Lists，Sets，Sorted Sets等。然而需要注意的是，Lists也有一个更复杂的阻塞式的API，例如BLPOP，BRPOP等。streams这方便的API也没什么不同，只是更复杂，更强大（更牛逼，哈）！

streams命令

废话不多说，先上手玩玩这个全新的数据类型。streams这个数据类型对应有如下13个操作命令，所有命令都以"X"开头：

XADD

用法：XADD key ID field string [field string …]

正如其名，这个命令就是用来添加的，给streams追加（append，前面提到过：streams主要是一个append only的数据结构）一个新的entry（和Java里的Map类似，Redis里的streams中的数据也称为entry）。

key：的含义就是同一类型streams的名称；

ID: streams中entry的唯一标识符，如果执行XADD命令时，传入星号（*），那么，ID会自动生成，且自动生成的ID会在执行XADD后返回，默认生成的ID格式为millisecondsTime+sequenceNumber，即当前毫秒级别的时间戳加上一个自增序号值，例如"1540013735401-0"。并且执行XADD时，不接受少于或等于上一次执行XADD的ID，否则会报错：ERR The ID specified in XADD is equal or smaller than the target stream top item；

field&string：接下来就是若干组field string。可以把它理解为表示属性的json中的key-value。例如，某一streams的key命名为userInfo，且某个用户信息为{"username":"afei", "password":"123456"}，那么执行XADD命令如下：

127.0.0.1:6379> xadd userInfo * username afei password 123456

"1540014082060-0"

由于命令中ID字段的值是星号，所以自定生成ID，1540014082060-0就是自动生成的ID。 XADD命令也支持显示指定ID，例如：XADD streamname 0-2 foo bar。

时钟回拨

需要注意的是，ID的时间戳部分是部署Redis服务器的本地时间，如果发生时钟回拨会怎么样？如果发生始终回拨，生成的ID的时间戳部分就是回拨后的时间，然后加上这个时间的递增序列号。例如当前时间戳1540014082060，然后这时候发生了时钟回拨，且回拨5ms，那么时间戳就是1540014082055。假设以前已经生成了1540014082055-0，1540014082055-1，那么这次由于时钟回拨，生成的ID就是1540014082055-2。所以允许自动生成的ID在发生时钟回拨时少于上次的ID，但是不允许显示指定一个少于上次的ID。

XDEL

用法：XDEL key ID [ID …]

和XADD相反，这是命令用来从streams中删除若干个entry，并且会返回实际删除数，这个删除数可能和参数ID个数不等，因为某些ID表示的消息可能不存在。执行命令如下，第二个参数ID是不存在的，所以XDEL的返回结果是1：

127.0.0.1:6379> XDEL userInfo "1540014379642-0" "1540014379642-1"

(integer) 1

XLEN

用法：XLEN key

很好理解，这个命令就是用来返回streams中有多少个entry。执行如下：

127.0.0.1:6379> XLEN userInfo

(integer) 2

streams三种查询模式

redis提供了三种查询streams数据的模式：

范围查询：因为streams的每个entry，其默认生成的ID是基于时间且递增的；
监听模式：类比linux中的tailf命令，实时接收新增加到streams中的entry（也有点像一个消息系统，事实上笔者认为它就是借鉴了kafka）；
消费者组：即Consumer Groups，特殊的监听模式。从一个消费者的角度来看streams，一个streams能被分区到多个处理消息的消费者，对于任意一条消息，同一个消费者组中只有一个消费者可以处理（和kafka的消费者组完全一样）。这样还能够横向扩容消费者，从而提升处理消息的能力，而不需要只让把让一个消费者处理所有消息。

接下里分别介绍这三种模式。

XRANGE

用法：XRANGE key start end [COUNT count]

这个命令属于第1种模式，即基于范围查询。这个命令用来返回streams某个顺序范围下的元素，start参数是更小的ID，end参数是更大的ID。有两个特殊的ID用符号"-"和"+"表示，符号"-"表示最小的ID，符号"+"表示最大的ID：

127.0.0.1:6379> XRANGE userInfo "1540014096298-0" "1540014477236-0"

1) 1) "1540014096298-0"

2) 1) "username"

2) "root"

3) "password"

4) "666666"

2) 1) "1540014477236-0"

2) 1) "username"

2) "test"

3) "password"

4) "111111"

127.0.0.1:6379>

127.0.0.1:6379> XRANGE userInfo - +

1) 1) "1540014082060-0"

2) 1) "username"

2) "afei"

3) "password"

4) "123456"

2) 1) "1540014096298-0"

2) 1) "username"

2) "root"

3) "password"

4) "666666"

3) 1) "1540014477236-0"

2) 1) "username"

2) "test"

3) "password"

4) "111111"

4) 1) "1540014493402-0"

2) 1) "username"

2) "u1"

3) "password"

4) "111111"

XRANGE还能实现遍历某个范围区间的功能，例如我想遍历2018-10-20号新增的用户信息。首先得到2018-10-20 00:00:00对应的时间戳为1539964800000，再得到2018-10-20 23:59:59对应的时间戳为1540051199000，然后执行如下命令：

127.0.0.1:6379> XRANGE userInfo 1539964800000-0 1540051199000-0 COUNT 5

1) 1) "1540014082060-0"

2) 1) "username"

2) "afei"

3) "password"

4) "123456"

... ...

5) 1) "1540014496505-0"

2) 1) "username"

2) "u2"

3) "password"

4) "111111"

127.0.0.1:6379>

# 需要注意的是，接下来再遍历的start参数是上一次遍历结果最大的ID加1，即"1540014496505-0"加1就是"1540014496505-1"。

127.0.0.1:6379> XRANGE userInfo 1540014496505-1 1540051199000-0 COUNT 5

1) 1) "1540014499863-0"

2) 1) "username"

2) "u3"

3) "password"

4) "111111"

XREVRANGE

用法：XREVRANGE key end start [COUNT count]

这个命令也属于第1种模式，且和XRANGE相反，返回一个逆序范围。end参数是更大的ID，start参数是更小的ID。执行示例如下：

XREVRANGE userInfo "1540014477236-0" "1540014096298-0"

XREAD

用法：XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key …] ID [ID …]

很明显，这个命令就是用来实现第2个模式，即监听模式。其作用是返回streams中从来没有读取的，且比参数ID更大的元素。

这个命令的使用方式如下：

127.0.0.1:6379> XREAD COUNT 10 BLOCK 60000 STREAMS userInfo "1540041139268-0"

1) 1) "userInfo"

2) 1) 1) "1540041264182-0"

2) 1) "u2"

2) "p2"

(9.26s)

# "1540041264182-0"这条消息时通过XADD添加的然后被XREAD监听到的消息。

127.0.0.1:6379> XREAD COUNT 2 STREAMS userInfo 0

1) 1) "userInfo"

2) 1) 1) "1540014082060-0"

2) 1) "username"

2) "afei"

3) "password"

4) "123456"

2) 1) "1540014096298-0"

2) 1) "username"

2) "root"

3) "password"

4) "666666"

# 这条命令实现类似XRANGE的功能。

127.0.0.1:6379> XREAD BLOCK 0 STREAMS userInfo $

1) 1) "userInfo"

2) 1) 1) "1540042613437-0"

2) 1) "u7"

2) "p7"

# 说明BLOCK为0表示一致等待知道有新的数据，否则永远不会超时。并且ID的值我们用特殊字符`$`表示，这个特殊字符表示我们只获取最新添加的消息。

此外，XREAD还支持同时监听多个streams，用法如下所示：

127.0.0.1:6379> XREAD BLOCK 0 STREAMS userInfo_01 userInfo_02 userInfo_03 userInfo_04 $ $ $ $

1) 1) "userInfo_03"

2) 1) 1) "1540043348287-0"

2) 1) "u1"

2) "p1"

(3.49s)

# 监听userInfo_01~userInfo_04这4个streams的新的消息。

XREAD除了COUNT和BLOCK，没有其他选项了。所有XREAD是一个非常基本的命令。更多高级特性可以往下看接下来要介绍的XREADGROUP。

XREADGROUP

用法：XREADGROUP GROUP group consumer [COUNT count] [BLOCK milliseconds] STREAMS key [key …] ID [ID …]

很明显，这就是第三种模式：消费者组模式。

如果你了解kafka的消费者组，那么你就也了解了streams的消费者组。如果不了解也没关系，笔者简单解释一下，假设有三个消费者C1，C2，C3。在streams中总计有7条消息：1， 2， 3， 4， 5， 6， 7，那么消费关系如下所示：

1 -> C1

2 -> C2

3 -> C3

4 -> C1

5 -> C2

6 -> C3

7 -> C1

消费者组具备如下几个特点：

同一个消息不会被投递到一个消费者组下的多个消费者，只可能是一个消费者。
同一个消费者组下，每个消费者都是唯一的，通过大小写敏感的名字区分。
消费者组中的消费者请求的消息，一定是新的，从来没有投递过的消息。
消费一个消息后，需要用命令（XACK）确认，意思是说：这条消息已经给成功处理。正因为如此，当访问streams的历史消息时，每个消费者只能看到投递给它自己的消息。

消费者组抽象的想象成如下这个样子：

+----------------------------------------+

| consumer_group_name: afeigroup |

| consumer_group_stream: somekey |

| last_delivered_id: 1292309234234-92 |

| |

| consumers: |

| "consumer-1" with pending messages |

| 1292309234234-4 |

| 1292309234232-8 |

| "consumer-42" with pending messages |

| ... (and so forth) |

+----------------------------------------+

XACK

用法：XACK key group ID [ID …]

这是消费者组相关的另一个重要的命令。标记一个处理中的消息为已被正确处理，如此一来，这条消息就会被从消费者组的pending消息集合中删除，类似MQ中的ack。

XGROUP

用法：XGROUP [CREATE key groupname id-or-$] [SETID key id-or-$] [DESTROY key groupname] [DELCONSUMER key groupname consumername]

这也是消费者组的一个重要命令，这个命令用来管理消费者组，例如创建，删除等。

XREADGROUP，XACK，XGROUP三种命令构成了消费者组相关的操作命令，下面是消费者组一些操作示例：

# 创建一个消费者组

127.0.0.1:6379> XGROUP CREATE userInfo GRP-AFEI $

# 需要注意的是，目前XGROUP CREATE的streams必须是一个存在的streams，否则会报错：

127.0.0.1:6379> XGROUP CREATE userinfo GRP-AFEI $

(error) ERR The XGROUP subcommand requires the key to exist. Note that for CREATE you may want to use the MKSTREAM option to create an empty stream automatically.

# 名为zhangsan的消费者，需要注意的是streams名称userInfo后面的特殊符号`>`表示这个消费者只接收从来没有被投递给其他消费者的消息，即新的消息。当然我们也可以指定具体的ID，例如指定0表示访问所有投递给该消费者的历史消息，指定1540081890919-1表示投递给该消费者且大于这个ID的历史消息：

127.0.0.1:6379> XREADGROUP GROUP mygroup zhangsan COUNT 1 BLOCK 0 STREAMS userInfo >

# 名为lisi的消费者：

127.0.0.1:6379> XREADGROUP GROUP mygroup lisi COUNT 1 BLOCK 0 STREAMS userInfo >

# 接下来分别添加两条信息，一条就会被zhangsan消费，另一条被lisi消费：

127.0.0.1:6379> XADD userInfo * username u102102 password p102102

"1540081873370-0"

127.0.0.1:6379> XADD userInfo * username u102103 password p102103

"1540081890919-0"

#现在消费者lisi有一条消息：

127.0.0.1:6379> XREADGROUP GROUP mygroup lisi COUNT 5 BLOCK 0 STREAMS userInfo 0

1) 1) "userInfo"

2) 1) 1) "1540081890919-0"

2) 1) "username"

2) "u102103"

3) "password"

4) "p102103"

#然后通过命令ack这条消息：

127.0.0.1:6379> XACK userInfo mygroup 1540081890919-0

(integer) 1

# 再看消费者lisi的pending队列，已经为空：

127.0.0.1:6379> XREADGROUP GROUP mygroup lisi COUNT 5 BLOCK 0 STREAMS userInfo 0

1) 1) "userInfo"

2) (empty list or set)

XPENDING

用法：XPENDING key group [start end count] [consumer]

返回streams中消费者组的pending消息，即消费者接收到但是还没有ack的消息，用法参考：

# 查看消费者组下总计最多10条pending消息

127.0.0.1:6379> XPENDING userInfo mygroup - + 10

1) 1) "1540083260408-0"

2) "zhangsan"

3) (integer) 183551

4) (integer) 1

2) 1) "1540083266293-0"

2) "lisi"

3) (integer) 177666

4) (integer) 1

# 查看消费者组下zhangsan这个消费者总计最多10条pending消息

127.0.0.1:6379> XPENDING userInfo mygroup - + 10 zhangsan

1) 1) "1540083260408-0"

2) "zhangsan"

3) (integer) 187006

4) (integer) 1

XCLAIM

用法：XCLAIM key group consumer min-idle-time ID [ID …] [IDLE ms] [TIME ms-unix-time] [RETRYCOUNT count] [FORCE] [JUSTID]

作用是改变消费者组中消息的所有权，用法参考：

127.0.0.1:6379> XREADGROUP GROUP mygroup zhangsan COUNT 5 BLOCK 0 STREAMS userInfo 0

1) 1) "userInfo"

2) 1) 1) "1540083260408-0"

2) 1) "username"

2) "u102106"

3) "password"

4) "p102106"

# zhangsan本来有1条消息，现在将另一条本来属于lisi的消息的所有权转给它：

127.0.0.1:6379> XCLAIM userInfo mygroup zhangsan 360 1540083266293-0

1) 1) "1540083266293-0"

2) 1) "username"

2) "u102107"

3) "password"

4) "p102107"

# 现在zhangsan有两条消息了

127.0.0.1:6379> XREADGROUP GROUP mygroup zhangsan COUNT 5 BLOCK 0 STREAMS userInfo 0

1) 1) "userInfo"

2) 1) 1) "1540083260408-0"

2) 1) "username"

2) "u102106"

3) "password"

4) "p102106"

2) 1) "1540083266293-0"

2) 1) "username"

2) "u102107"

3) "password"

4) "p102107"

XINFO

用法：XINFO [CONSUMERS key groupname] [GROUPS key] [STREAM key] [HELP]

其作用是得到streams和消费者组的一些信息，使用参考：

127.0.0.1:6379> XINFO CONSUMERS userInfo mygroup

1) 1) "name"

2) "lisi"

3) "pending"

4) (integer) 0

5) "idle"

6) (integer) 201086

2) 1) "name"

2) "zhangsan"

3) "pending"

4) (integer) 2

5) "idle"

6) (integer) 701954

127.0.0.1:6379> XINFO STREAM userInfo

1) "length"

2) (integer) 22

3) "radix-tree-keys"

4) (integer) 1

5) "radix-tree-nodes"

6) (integer) 2

7) "groups"

8) (integer) 2

9) "last-generated-id"

10) "1540082298051-0"

11) "first-entry"

12) 1) "1540014082060-0"

2) 1) "username"

2) "afei"

3) "password"

4) "123456"

13) "last-entry"

14) 1) "1540082298051-0"

2) 1) "username"

2) "u102105"

3) "password"

4) "p102105"

XTRIM

用法：XTRIM key MAXLEN [~] count

修剪streams到一个确定的size。Trims the stream to (approximately if '~' is passed) a certain size，用法参考：

# streams只保留10条消息，其返回结果表示被剪去多少条消息：

127.0.0.1:6379> XTRIM userInfo MAXLEN 10

(integer) 14

说明：streams目前的修剪策略比较简单，比如连根据ID范围修剪都没有实现。根据具体某一个ID删除，可以通过XDEL实现。

持久化，复制以及消息安全性

和其他数据类型一样，streams也会异步复制到slave，并也会持久化到AOF和RDB文件中。然而，消费者组的全部状态是被传播（propagated ）到AOF，RDB和slave中。

需要注意的是，Redis的streams和消费者组使用Redis默认复制进行持久化和复制，因此：如果消息的持久性在您的应用程序中很重要，则必须将AOF与强fsync策略一起使用。

默认情况下，异步复制不保证能复制每一个数据添加或使用者组状态更改：在故障转移之后，可能会丢失某些内容，具体取决于slave从master接收数据的能力。

长度为0的streams

这是streams和其他redis数据类型的不同，其他数据类型，例如Lists，Sets等，如果所有元素都被删除，那么key也不存在。而streams允许所有entry都被删除。

存在这种不对称性的原因是因为streams可能具有关联的消费者组，并且我们不希望由于streams中不再有任何entry而丢失消费者组定义的状态。目前，即使没有关联的消费者群体，也不会删除该streams。