stream

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

流操作

1. XADD(* 会让系统自动生成ID)(没有这个流,会自动创建)
2. Xrange 获取消息队列(可指定范围),忽略删除的消息
   1. start 表示开始值 -表示最小值
   2. end 表示结束值, + 代表最大值
   3. count代表最多获取多少个值
3. xrevrange 与range区别在,获取消息列表元素的方向是相反的,end在前,start在后
4. XDEL 删除某个流的某条消息
5. XLEN 获取stream队列的消息的长度
6. XTRIM 对Stream 的长度进行截取
   1. MAXLEN 允许的最大长度,对流进行修剪限制长度(留下日期较新的消息)
   2. MINID 允许的最小id,从某个id值开始比该id值小的会被抛弃

消费组

1. XGROUP CREATE 创建消费者组
2. XREADGROUP GROUP
   1. > 表示从第一条尚未被消费的消息开始读取
   2. 同一个信息只能被一个消费组的人读取,其他人读取不到
   3. 不同消费组的人可以消费同一条消息
   4. 消费组目的:让组内的多个消费者共同分担读取消息，所以，我们通常会让每个消费者读取部分消息，从而实现消息读取负载在多个消费者间是均衡分布的
3. XPENDING
   1. 查看每个消费组内所有消费者[已读取,未确认]的消息
   2. 查看某个消费者具体读取了哪些数据
4. XACK 向消息队列确认消息处理已完成,对应的pendlist会减少对应的记录

1问题	基于 Stream 实现的消息队列，如何保证消费者在发生故障或宕机再次重启后，仍然可以读取未处理完的消息？
2	Streams 会自动使用内部队列（也称为 PENDING List）留存消费组里每个消费者读取的消息保底措施，直到消费者使用 XACK 命令通知 Streams“消息已经处理完成”。
3	消费确认增加了消息的可靠性，一般在业务处理完成之后，需要执行 XACK 命令确认消息已经被消费完成

• XINFO 打印Stream\consumer\group的详细信息