stream
由来
为了抢消息队列的饭碗
原理
| 1 | Message Content | 消息内容 |
|---|---|---|
| 2 | Consumer group | 消费组，通过XGROUP CREATE 命令创建，同一个消费组可以有多个消费者 |
| 3 | Last_delivered_id | 游标，每个消费组会有个游标 last_delivered_id，任意一个消费者读取了消息都会使游标 last_delivered_id 往前移动。 |
| 4 | Consumer | 消费者，消费组中的消费者 |
| 5 | Pending_ids | 消费者会有一个状态变量，用于记录被当前消费已读取但未ack的消息Id，如果客户端没有ack，这个变量里面的消息ID会越来越多，一旦某个消息被ack它就开始减少。这个pending_ids变量在Redis官方被称之为 PEL(Pending Entries List)，记录了当前已经被客户端读取的消息，但是还没有 ack (Acknowledge character：确认字符），它用来确保客户端至少消费了消息一次，而不会在网络传输的中途丢失了没处理 |
特殊符号
- -/+ 最小和最大可能出现的id
- $ $表示只消费新的消息,当前流中最大的id,可用于将要到来的消息
- > 用于用于XREADGROUP命令，表示迄今还没有发送给组中使用者的信息，会更新消费者组的最后ID
- * 用于XADD命令中，让系统自动生成id
流操作
- XADD(* 会让系统自动生成ID)(没有这个流,会自动创建)
- Xrange 获取消息队列(可指定范围),忽略删除的消息
- start 表示开始值 -表示最小值
- end 表示结束值, + 代表最大值
- count代表最多获取多少个值
- xrevrange 与range区别在,获取消息列表元素的方向是相反的,end在前,start在后
- XDEL 删除某个流的某条消息
- XLEN 获取stream队列的消息的长度
- XTRIM 对Stream 的长度进行截取
- MAXLEN 允许的最大长度,对流进行修剪限制长度(留下日期较新的消息)
- MINID 允许的最小id,从某个id值开始比该id值小的会被抛弃
消费组
- XGROUP CREATE 创建消费者组
- XREADGROUP GROUP
- > 表示从第一条尚未被消费的消息开始读取
- 同一个信息只能被一个消费组的人读取,其他人读取不到
- 不同消费组的人可以消费同一条消息
- 消费组目的:让组内的多个消费者共同分担读取消息，所以，我们通常会让每个消费者读取部分消息，从而实现消息读取负载在多个消费者间是均衡分布的
- XPENDING
- 查看每个消费组内所有消费者[已读取,未确认]的消息
- 查看某个消费者具体读取了哪些数据
- XACK 向消息队列确认消息处理已完成,对应的pendlist会减少对应的记录
| 1问题 | 基于 Stream 实现的消息队列，如何保证消费者在发生故障或宕机再次重启后，仍然可以读取未处理完的消息？ |
|---|---|
| 2 | Streams 会自动使用内部队列（也称为 PENDING List）留存消费组里每个消费者读取的消息保底措施，直到消费者使用 XACK 命令通知 Streams“消息已经处理完成”。 |
| 3 | 消费确认增加了消息的可靠性，一般在业务处理完成之后，需要执行 XACK 命令确认消息已经被消费完成 |
- XINFO 打印Stream\consumer\group的详细信息