
Redis系列15:使用Stream实现消息队列(精讲版)
1 介绍
我们上一篇介绍了如何使用List实现消息队列么,但是我们也看到很多局限性,如下:
- 不支持消息确认机制,没有很好的ACK应答
- 不支持消息回溯,无法排查问题和做消息分析
- List遵循FIFO机制,所以存在消息堆积的风险。
- 查询效率低,作为线性结构,List中定位一个数据需要进行遍历,O(N)的时间复杂度。
- 不存在消费组(Consumer Group)的概念,无法进行分组消费和批量消费
Redis中有三种消息队列模式:
名称 | 简要说明 |
List | 不支持消息确认机制(Ack),不支持消息回朔 |
pubSub | 不支持消息确认机制(Ack),不支持消息回朔,不支持消息持久化 |
stream | 支持消息确认机制(Ack),支持消息回朔,支持消息持久化,支持消息阻塞 |
可以看出,作为Redis 5.0 引入的专门为消息队列设计的数据类型,Stream 功能更加健全,更适合做消息队列分发。
Stream 可以包含 0个 到 n个元素的有序队列,并根据ID的大小进行排序。
Stream类型消息队列的具备以下命令特点:
- 可以序列化生成消息ID,方便索引、排序
- 消息可回朔
- 支持Consumer Groups 消费组:多消费者消息争抢,加快消费速度
- 可以阻塞读取消息和非阻塞读取消息
- 没有消息漏读风险
- 有ACK消息确认机制,保证消息至少被消费一次
- 支持多播模式:可以让队列从逻辑上分组进行隔离消费
这些特性,基本达到了一个消息中间件的基本能力,比如:
- 类似 Kafka 的 Consumer Groups 的概念,它也具备了消费组的能力。
- 类似 Rocket MQ的持久化能力,以及高可用的文件存储机制,它也具备了消息的持久化和主从复制机制,可以记录访问位置,方便后续其他时间段继续访问,避免数据丢失。
详细的stream操作见官网文档:https://redis.io/docs/data-types/streams-tutorial/
2 XADD 消息写入
即讲消息添加到队列中,语法如下:
注释比较清楚,以下举例说明:
不指配*,这可以直接指定顺序Id
队列的消息ID 由两部分组成:
- 毫秒级别的当前时间的时间戳;
- 顺序编号。从 0 为起始值,用于区分同一时间内产生的多个ID,如果同一个时间戳内生成多ID,按序号顺序增长,这种方式可解决顺序识别和时间回拨问题。
通过这种时间戳 + 顺序编号的模式,变成数据Append的模式,这种流式记性数据顺序推送的方式符合MQ的基本消费逻辑,也为后面的有序性消费提供基本条件。
2 XREAD 消息阅读
即讲消息从队列中读取出来(消费),语法如下:
注释比较清楚,以下举例说明:
如何顺序性消费:我们每次读取之后都会返回消息Id和序号,比如上面的 1680926230000-0
,所以在下一次调用的时候,可以用上一次返回的ID序号作为参数,就可以从指定位置上进行消费。
问题:XREAD之后数据并没有删除,所以没记住读取的位置,下次可能重复阅读,造成重复消费。所以需要消费确认机制(即ACK)。
3 消费者组模式(Consumer Group)
消息队列很重要的一个能力就是分组消费(Consumer Group),无论是Kafka 还是 RabbitMQ。他允许队列从逻辑上进行分组来保证隔离消费。
这是典型的多播模,如下图所示:
它有如下特点:
- Redis Stream 实际结构是一个链式的队列,一个消息由消息Id和消息内容组成,消息Id具有唯一性;
- 消费组的状态是独立的,像图中的GroupA、GroupB、GroupC,Stream 消息可以被这几个组消费;
- 同时一个消费者组可以有多个消费者,但是他们的竞选关系,任意消费者消费之后就会导致
last_deliverd_id
偏移,这样避免了重复消费。 - 每个消费者都携带pending_ids 变量,记录读取但还未消费(未被ack)的消息,来保证消息有且仅有一次被消费。
消费组实现的消息队列主要有3类指令,如下:
- XGROUP:用于创建消费群组,包括注销和其他管理职能。
- XREADGROUP:消费者群组,通过这些组从流中有序读取数据。
- XACK:通过该命令,消费者将处理的完的消息标记为已正确完成。
3.1 写入队列数据
咱们先做一下数据准备,创建队列,并往里面写入一些数据,如下:
3.2 创建消费者群组
这个的做法就是在队列中创建消费者组,然后指定消费的位置。
语法如下:
下面是具体实现示例,为队列 stream_user 创建了消费组1(consumer_group1)和 消费组2(consumer_group2):
3.3 读取消费组信息
消费队列消息的语法如下:
实现示例:消费组 consumer_group1
的消费者 consumer1
从 stream_user
中以阻塞的方式读取一条消息:
这边需要主意的是,同一个消费组内,消息只能单次消费,如果被消费组内消费过了,就不会被同组的其他消费组读取到。
如下:
上面 user_name 为 brand 的数据已经被consumer1消费了,所以consumer2 就读不到了,只能读取到下一条 user_name 为 jay 的数据。
多个消费者可以达到流量分摊的目的,为大业务流量的场景做负载和分流。如下图,多个消费者相对平均的进行消息消费。
3.4 XPENDING 检查已读取但未ACK的数据
有时候会出现这种情况,就是消费者组或者消费者发生了故障,甚至整个消费者都故障重启了,那么如何避免消息丢失呢,那就是将读取到的但是还没消费的数据进行暂存。
Redis在Stream内部实现了一个待决队列(pending List),消费者读取之后且没有进行ACK的数据都保存在这里。
这种情况就是:
- 消费者使用
XREADGROUP
读取消息 - 读取完成之后,发生故障或者异常,没有给 Stream 发送
XACK
命令,消息依然保留在Stream 的 pending List中。
比如查看 stream_user
中的 消费组 consumer_group1
中各个消费者已读取未确认的消息信息:
3.5 消息消费完成之后确认(ACK)
正如3.4中所说的相关内容消费完之后,需要 ACK 通知 Streams,然后Stream除消息。否则就会造成消息变成待决队列中,可能造成重复消费的情况。
执行命令语法如下:
ack的本意就是对消费完成的消息进行确认,业务处理没有问题之后进行一个check的过程,代表这个消息已经被消费完了。流程如下:
4 使用Redission实现Stream队列能力
4.1 添加maven依赖 和 配置基本连接
4.2 Java程序实现
5 总结
相对List,Stream的能力有比较大的提升:
- 支持消息确认机制(ACK应答确认)
- 支持消息回溯,方便排查问题和做消息分析
- 存在消费组(Consumer Group)的概念,可以进行分组消费和批量消费,可以负载多个消费实例
文章转载自公众号: 架构与思维
