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的文章,本篇文章就不做过多的介绍了。下面给出一张从官方源码中的部分截图:
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:
"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"
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 userInfo XRANGE还能实现遍历某个范围区间的功能,例如我想遍历2018-10-20号新增的用户信息。首先得到2018-10-20 00:00:00对应的时间戳为1539964800000,再得到2018-10-20 23:59:59对应的时间戳为1540051199000,然后执行如下命令:
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"
# 需要注意的是,接下来再遍历的start参数是上一次遍历结果最大的ID加1,即"1540014496505-0"加1就是"1540014496505-1"。
XRANGE userInfo 1540014496505-1 1540051199000-0 COUNT 5
1) 1) "1540014499863-0"
2) 1) "username"
2) "u3"
3) "password"
4) "111111"
XRANGE userInfo 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更大的元素。
这个命令的使用方式如下:
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监听到的消息。
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的功能。
XREAD BLOCK 0 STREAMS userInfo $
1) 1) "userInfo"
2) 1) 1) "1540042613437-0"
2) 1) "u7"
2) "p7"
# 说明BLOCK为0表示一致等待知道有新的数据,否则永远不会超时。并且ID的值我们用特殊字符`$`表示,这个特殊字符表示我们只获取最新添加的消息。
XREAD COUNT 此外,XREAD还支持同时监听多个streams,用法如下所示:
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 BLOCK 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三种命令构成了消费者组相关的操作命令,下面是消费者组一些操作示例:
# 创建一个消费者组
XGROUP CREATE userInfo GRP-AFEI $
OK
# 需要注意的是,目前XGROUP CREATE的streams必须是一个存在的streams,否则会报错:
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的历史消息:
XREADGROUP GROUP mygroup zhangsan COUNT 1 BLOCK 0 STREAMS userInfo >
# 名为lisi的消费者:
XREADGROUP GROUP mygroup lisi COUNT 1 BLOCK 0 STREAMS userInfo >
# 接下来分别添加两条信息,一条就会被zhangsan消费,另一条被lisi消费:
XADD userInfo * username u102102 password p102102
"1540081873370-0"
XADD userInfo * username u102103 password p102103
"1540081890919-0"
#现在消费者lisi有一条消息:
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这条消息:
XACK userInfo mygroup 1540081890919-0
(integer) 1
# 再看消费者lisi的pending队列,已经为空:
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]
作用是改变消费者组中消息的所有权,用法参考:
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的消息的所有权转给它:
XCLAIM userInfo mygroup zhangsan 360 1540083266293-0
1) 1) "1540083266293-0"
2) 1) "username"
2) "u102107"
3) "password"
4) "p102107"
# 现在zhangsan有两条消息了
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"
XREADGROUP GROUP mygroup zhangsan COUNT 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。