Redis——实现消息队列

前言

基于List结构模拟消息队列

基于List实现消息队列优缺点

基于PubSub（订阅者）实现消息队列

示例

基于PubSub的消息队列的优缺点

基于Stream的消息队列

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

基于Stream的消息队列-消费者组

基于消费者监听消息的基本思路：

stream类型消息队列的xreadgroup命令特点：

Redis消息队列总结

前言

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

以下就是基于Redis结构特性来实现消息队列

基于List结构模拟消息队列

Redis的list数据结构是双向链表，很容易模拟出消息队列的效果

对于Redis的list数据结构操作方法LPUSH,RPOP,RPUSH,LPOP这些方法。可以利用这些方法来实现消息队列。

如果不知道这些方法怎么使用找到redis的客户端使用和help + 对应操作方法就可以展现出相关文档使用

基于List实现消息队列优缺点

优点：

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

缺点：

无法避免消息丢失（从消息队列中取出一条消息还没来得及处理就出现异常，这条消息就会丢失，remove出一条消息，list中就没有了）
只支持单消费者（发送一条消息remove移除了，其他消费者就拿不到了）

基于PubSub（订阅者）实现消息队列

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

PubSub设计之初本来就是用来作消息频道的，有人订阅就会接收，没人接收就不会保存到PubSub直接丢失

示例

基于PubSub的消息队列的优缺点

优点：

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

缺点：

不支持数据持久化（pusub本来就是用作消息队列的不像list本来就是数据结构数据存储，发布消息没人订阅的化消息丢失）
无法避免消息丢失
消息堆积有上限，超出时数据丢失（发送消息有人订阅，会在消费者那里缓存，缓存空间有上限，连续发很多消息就会消息丢失）

基于Stream的消息队列

Stream是Redis5.0引入的一种新的数据类型，可以实现一个功能非常完善的消息队列。

发送消息的命令：（也就是往消息队列添加一条消息）

例如：

读取消息的方式之一：xread

示例：

在业务开发中，我们可以循环的调用xread阻塞方式来查询最新的消息，从而实现持续监听队列的效果，伪代码如下：

whlie(true){//尝试读取队列中的消息，最多阻塞2s
Object msg = redis.execute("xread count 1 block 2000 streams users $");
if(msg == null){continue;
}
//处理消息handleMessga（mag）;

注意：

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

1.消息可回溯（消息读取完之后不消失）

2.一个消息可以被多个消费者读取

3.可以阻塞读取

4.有漏读风险

基于Stream的消息队列-消费者组

消费者组（consumer Group）：将多个消费者划分到一个组中，监听同一个队列。具备一下特点：消息分流，消息标识，消息确认

创建消费者组：

其他常见命令：

一般情况下不需要自己去添加消费者，当我们从这个组中指定一个消费者并且监听消息的时候，如果发现消费者不存在自动帮我们创建出来，并不需要手动去创建

从消费者组读取消息：

基于消费者监听消息的基本思路：

  while (true){//尝试监听队列，使用阻塞模式，最长等待2秒Object msg = redis.call("xreadgroup group g1 c1 count 1 block 2 streams s1 >");if(msg == null){continue;}try {//处理消息，完成后一定要ackhandleMassage(msg);}catch (Exception e){while (true){Object msg = redis.call("xreadgroup group g1 c1 count 1 block 2 streams s1 0");if(msg == null){continue;}try {//说名没有异常消息，再次处理handleMassge(msg);}catch (Exception e){//再次出现异常，记录日志，继续循环continue;}}}