Redis5.0增加新数据结构Stream,是一个强大的支持多播的可持久化的消息队列,如下图所示
是一个消息列表,将所有加入的消息都串起来,每个消息都有唯一的Id和对应的内容,消息持久化。Stream的唯一名称是Key,在我们首次xadd指令追加消息时自动创建。
1、每个Stream可以挂多个消费组,每个消费组都有一个last_delivered_id在Stream上向前移动,代表当前消费组已经消费到哪条消息,消费组不会自动创建,需要单独执行xgroup create进行创建,而且需要指定从Stream某个消息ID开始消费,该ID用来初始化last_delivered_id变量
2、每个消费组的状态都是独立的,互不影响
3、同一个消费组 (Consumer Group) 可以挂接多个消费者 (Consumer),这些消费者之间是竞争关系,任意一个消费者读取了消息都会使游标last_delivered_id往前移动。每个消费者有一个组内唯一名称
4、消费组内部有一个状态变量pengding_ids,记录了当前已经被客户端读取的消息,但是开始时没有ack,如果客户端没有ack,这个变量的消息ID越来越多,一旦某个消息给ack,他就开始减少,官方称pengding_ids为PEL,确保消息至少被消费一次
5、消息ID
消息 ID 的形式是timestampInMillis-sequence,例如1527846880572-5,表示当前的消息在毫米时间戳1527846880572时产生,并且是该毫秒内产生的第 5 条。可以由服务器自动产生,也可以由客户端指定
6、操作命令
1)xadd 追加消息
2)xdel 删除消息,这里的删除仅仅是设置了标志位,不影响消息总长度
3)xrange 获取消息列表,会自动过滤已经删除的消息
4)xlen 消息长度
5)del 删除 Stream
7、独立消费
# 删除整个 Stream 127.0.0.1:6379> del codehole |
不定义消费组可以独立消费,,当Stream没有消息时,可以阻塞等待。Redis设计了一个单独消费指令xread,将其当成普通的消息队列list来使用,如下:
# 从 Stream 头部读取两条消息 127.0.0.1:6379> xread count 2 streams codehole 0-0 1) 1) "codehole" 2) 1) 1) 1527851486781-0 2) 1) "name" 2) "laoqian" 3) "age" 4) "30" 2) 1) 1527851493405-0 2) 1) "name" 2) "yurui" 3) "age" 4) "29" # 从 Stream 尾部读取一条消息,毫无疑问,这里不会返回任何消息 127.0.0.1:6379> xread count 1 streams codehole $ (nil) # 从尾部阻塞等待新消息到来,下面的指令会堵住,直到新消息到来 127.0.0.1:6379> xread block 0 count 1 streams codehole $ # 我们从新打开一个窗口,在这个窗口往 Stream 里塞消息 127.0.0.1:6379> xadd codehole * name youming age 60 1527852774092-0 # 再切换到前面的窗口,我们可以看到阻塞解除了,返回了新的消息内容 # 而且还显示了一个等待时间,这里我们等待了 93s 127.0.0.1:6379> xread block 0 count 1 streams codehole $ 1) 1) "codehole" 2) 1) 1) 1527852774092-0 2) 1) "name" 2) "youming" 3) "age" 4) "60" (93.11s) |
如果想顺序读取,要记住前面的消息ID
8、创建消费者
Stream 通过xgroup create指令创建消费组 (Consumer Group),传递起始消息 ID 参数用来初始化last_delivered_id变量
# 表示从头开始消费 127.0.0.1:6379> xgroup create codehole cg1 0-0 OK # $ 表示从尾部开始消费,只接受新消息,当前 Stream 消息会全部忽略 127.0.0.1:6379> xgroup create codehole cg2 $ OK # 获取 Stream 信息 127.0.0.1:6379> xinfo stream codehole 1) length 2) (integer) 3 # 共 3 个消息 3) radix-tree-keys 4) (integer) 1 5) radix-tree-nodes 6) (integer) 2 7) groups 8) (integer) 2 # 两个消费组 9) first-entry # 第一个消息 10) 1) 1527851486781-0 2) 1) "name" 2) "laoqian" 3) "age" 4) "30" 11) last-entry # 最后一个消息 12) 1) 1527851498956-0 2) 1) "name" 2) "xiaoqian" 3) "age" 4) "1" # 获取 Stream 的消费组信息 127.0.0.1:6379> xinfo groups codehole 1) 1) name 2) "cg1" 3) consumers 4) (integer) 0 # 该消费组还没有消费者 5) pending 6) (integer) 0 # 该消费组没有正在处理的消息 2) 1) name 2) "cg2" 3) consumers # 该消费组还没有消费者 4) (integer) 0 5) pending 6) (integer) 0 # 该消费组没有正在处理的消息 |
9、消费
Stream 提供了 xreadgroup 指令进行消费组的组内消费,需要提供消费组名称、消费者名称和起始消息 ID。它同 xread 一样,也可以阻塞等待新消息。读到新消息后,消息 ID 进入消费者的 PEL(正在处理的消息) 里,客户端处理完毕后发送 xack 指令通知服务器,服务器接收到后,该消息 ID 就会从 PEL 中移除。
# > 号表示从当前消费组的 last_delivered_id 后面开始读 # 每当消费者读取一条消息,last_delivered_id 变量就会前进 127.0.0.1:6379> xreadgroup GROUP cg1 c1 count 1 streams codehole > 1) 1) "codehole" 2) 1) 1) 1527851486781-0 2) 1) "name" 2) "laoqian" 3) "age" 4) "30" 127.0.0.1:6379> xreadgroup GROUP cg1 c1 count 1 streams codehole > 1) 1) "codehole" 2) 1) 1) 1527851493405-0 2) 1) "name" 2) "yurui" 3) "age" 4) "29" 127.0.0.1:6379> xreadgroup GROUP cg1 c1 count 2 streams codehole > 1) 1) "codehole" 2) 1) 1) 1527851498956-0 2) 1) "name" 2) "xiaoqian" 3) "age" 4) "1" 2) 1) 1527852774092-0 2) 1) "name" 2) "youming" 3) "age" 4) "60" # 再继续读取,就没有新消息了 127.0.0.1:6379> xreadgroup GROUP cg1 c1 count 1 streams codehole > (nil) # 那就阻塞等待吧 127.0.0.1:6379> xreadgroup GROUP cg1 c1 block 0 count 1 streams codehole > # 开启另一个窗口,往里塞消息 127.0.0.1:6379> xadd codehole * name lanying age 61 1527854062442-0 # 回到前一个窗口,发现阻塞解除,收到新消息了 127.0.0.1:6379> xreadgroup GROUP cg1 c1 block 0 count 1 streams codehole > 1) 1) "codehole" 2) 1) 1) 1527854062442-0 2) 1) "name" 2) "lanying" 3) "age" 4) "61" (36.54s) # 观察消费组信息 127.0.0.1:6379> xinfo groups codehole 1) 1) name 2) "cg1" 3) consumers 4) (integer) 1 # 一个消费者 5) pending 6) (integer) 5 # 共 5 条正在处理的信息还有没有 ack 2) 1) name 2) "cg2" 3) consumers 4) (integer) 0 # 消费组 cg2 没有任何变化,因为前面我们一直在操纵 cg1 5) pending 6) (integer) 0 # 如果同一个消费组有多个消费者,我们可以通过 xinfo consumers 指令观察每个消费者的状态 127.0.0.1:6379> xinfo consumers codehole cg1 # 目前还有 1 个消费者 1) 1) name 2) "c1" 3) pending 4) (integer) 5 # 共 5 条待处理消息 5) idle 6) (integer) 418715 # 空闲了多长时间 ms 没有读取消息了 # 接下来我们 ack 一条消息 127.0.0.1:6379> xack codehole cg1 1527851486781-0 (integer) 1 127.0.0.1:6379> xinfo consumers codehole cg1 1) 1) name 2) "c1" 3) pending 4) (integer) 4 # 变成了 5 条 5) idle 6) (integer) 668504 # 下面 ack 所有消息 127.0.0.1:6379> xack codehole cg1 1527851493405-0 1527851498956-0 1527852774092-0 1527854062442-0 (integer) 4 127.0.0.1:6379> xinfo consumers codehole cg1 1) 1) name 2) "c1" 3) pending 4) (integer) 0 # pel 空了 5) idle 6) (integer) 745505 |
10、Stream消息太多
Redis提供一个定长Stream功能,xadd指令有一个定长长度maxlent,可以将老的消息删掉,确保最多不超过指定的长度
127.0.0.1:6379> xlen codehole (integer) 5 127.0.0.1:6379> xadd codehole maxlen 3 * name xiaorui age 1 1527855160273-0 127.0.0.1:6379> xlen codehole (integer) 3 |
12、分区 Partition
Redis 的服务器没有原生支持分区能力,如果想要使用分区,那就需要分配多个 Stream,然后在客户端使用一定的策略来生产消息到不同的 Stream。
Kafka 的客户端也存在 HashStrategy ,因为它也是通过客户端的 hash 算法来将不同的消息塞入不同分区的。另外,Kafka 还支持动态增加分区数量的能力,但是这种调整能力也是很蹩脚的,它不会把之前已经存在的内容进行 rehash,不会重新分区历史数据。这种简单的动态调整的能力 Redis Stream 通过增加新的 Stream 就可以做到。
13、补充
Stream 的消费模型借鉴了 Kafka 的消费分组的概念,它弥补了 Redis Pub/Sub 不能持久化消息的缺陷。但是它又不同于 kafka,Kafka 的消息可以分 partition,而 Stream 不行。如果非要分 parition 的话,得在客户端做,提供不同的 Stream 名称,对消息进行 hash 取模来选择往哪个 Stream 里塞。