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 里塞。
3707
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
