Redis 消息队列

news2024/9/25 8:44:49

认识消息队列

消息队列（Message Queue）字面意思就是存放消息的队列，最简单的消息队列模型包括 3 个角色

消息队列：存储和管理消息，也被称为消息代理（Message Broker）
生产者：发送消息到消息队列
消费者：从消息队列获取消息并处理

优点：结束耦合，异步操作

Redis 提供了三种不同的方式来实现消息队列

list 结构：基于 List 结构模拟消息队列
PubSub：基本的点对点消息模型
Stream：比较完善的消息队列模型

List

list 数据结构是一个双向链表，很容易模拟出队列效果，队列的人口和出口不在一边，因此我们可以利用，LPUSH 结合 RPOP，或者RPUSH 结合 LPOP 来实现，不过要注意的是，当消息队列中没有消息时 RPOP 或者 LPOP 操作会返回 null ，并不像 JVM 的阻塞队列那样会阻塞并等待消息，因此这里应该使用 BRPOP 或者 BLPOP 来实现阻塞效果，他是在 JVM 以外的独立存储，所以没有存储上限的问题，第二数据安全，redis 支持数据持久化

优点

利用 Redis 存储，不受限于 JVM 内存上限
基于 Redis 的持久化机制，数据安全性有暴政
可以满足消息有序性

缺点

无法避免消息丢失
只支持单个消费者

PubSub

是 Redis 2.0 版本引入的消息传递模型，顾名思义，消费者可以订阅一个或者多个 channel ，生产者向对应 channel 发送消息后，所有订阅者都能收到相关的消息

UBSCRIBE channel [channel] : 订阅一个或者多个频道
PUBLISH channel msg : 向一个频道发送消息
PSUBSCRIBE pattern(通配符) [pattern] : 订阅与 pattern 格式匹配的所有频道 , redis 支持的通配符？模糊单个字符 * 模糊一个或者多个字符 [ab] 指定模糊字符

优点

采用发布订阅模型，支持多生产，多消费

缺点

不支持数据持久化
无法避免消息丢失
消息堆积有上限，超时时数据会丢失

Stream

是 Redis 5.0 引入的一种新数据类型，可以实现一个功能非常完善的消息队列

注意：当我们指定起始 ID 为 $ 时，代表读取最新消息，如果我们处理一条消息的过程中，又有超过 1 条以上的消息达到队列，则下次获取的时也只能获取到最新的一条，会出现漏读消息的情况

特点

消息可回溯
一个消息可以被多个消费者读取
可以阻塞读取
有消息漏读的风险

消费者组

（Consumer Group）将多个消费者划分到一个组中，监听同一列队

特点

消息分流：列队中的消息会分流给组内的不同消费者，而不是重复消费，从而加快消息处理了的速度
消息标示：消费者组会维护一个标示记录最后一个被处理的消息，哪怕消费者宕机重启，还会从标示之后读取消息，确保每一个消息都会被消费，不会出现漏掉消息的情况
消息确认：消费者获取消息之后，消息处于一个 pending 状态，并存入一个 pending-list 。当处理完成后，需要通过 XACK 来确认消息，标记消费已处理，才会从 pending-list 中移除

创建消费者组

XGROUP CREATE key groupName ID [MKSTREAM]

key 队列名称
groupName 消费者组的名称
ID 起始 ID 标示，$ 代表队列中最后一条消息，0 则代表队列中第一个消息
MKSTREAM 列队不存在时自动创建队列

其他命令

从消费者组读取消息

group 消费组名称
consumer 消费者名称，如果消费者不存在，会自动创建一个消费者
count 本次查询的最大数量
BLOCK milliseconds 当没有消息时最大等待时长（毫秒）
NOACK 无需手动 ACK ，获取到消息后自动确认，一般不建议设置
STREAMS key 指定队列名称
ID 获取消息的起始 ID
- > 从下一个未消费的消息开始
- 其他，根据指定的 id 从 pending-list 中获取已消费但是未确认的消息，例如 0 ，是从 pending-list 中的第一个消息开始

XACK

要确认的消息

语法 XACK key group ID [ID ...]

总结

STREAM 类型消息队列的 XREADGROUP 命令特点

消息可回溯
可以多消费者争抢消息，加快消息速度
可以阻塞读取
没有消息漏读的风险

有消息确认机制，确保消息至少被消费一次

	List	PubSub	Stream
消息持久化	支持	不支持	支持
阻塞读取	支持	支持	支持
消息堆积处理	受限于内存空间，可以利用多消费者加速处理	受限于消费者缓冲区	受限于队列长度，可以利用消费者组来提高消费速度，减少堆积
消息确认机制	不支持	不支持	支持
消息回溯	不支持	不支持	支持