一.基本概念
消息队列(MQ)，字面意思讲就是存放消息的队列，最简单的消息队列包含3个角色:
- 消息队列:存储和管理消息，也被称为消息代理
- 生产者: 发送消息到消息队列
- 消费者: 从消息队列获取消息并处理消息
Redis提供了三种不同的方式来实现消息队列:(实际场景中不会使用)
- list结构:基于List结构模拟消息队列
- PubSub:基于点对点消息模型
- Stream:比较完善的消息队列模型
二.实现消息队列
2.1 基于List实现消息队列
消息队列(Message Queue)，字面意思就是存放消息的队列。而Redis的list数据结构是一个双向链表，很容易模拟出队列效果。
队列是入口和出口不在一边，因此我们可以利用:LPUSH结合RPOP、或者RPUSH结合LPOP来实现。
不过要注意的是，当队列中没有消息时RPOP或LPOP操作会返回null，并不像JVM的阻塞队列那样会阻塞并等待消息。因此这里应该使用BRPOP或者BLPOP来实现阻塞效果。
现在，我们可以阻塞式消费了，但这个消息队列还是太薄弱了，最明显一点，是没有ACK机制，即消费者取消息之后，消息就出队列了，如果消费失败，消息还得想办法放回去。同时，也不支持多人消费。
在消息队列(如RabbitMQ、Kafka、RocketMQ等)中,ACK(Acknowledgement)是消费者在成功处理完一条消息后，向消息中间件发送的一个"确认"信号。这个信号告诉消息队列:"这条消息我已经处理完了，你可以把它从队列中移除。"如果没有ACK机制，消息一旦被消费者取走，就会立即从队列中删除，无论消费者是否成功处理了它。
这里继续做下去的话，有几种方式:
- 先用LRANGE读队列信息，消费完成之后，再POP，但这样消息可能被多个消费者消费，没办法实现一个消费组的逻辑。
- POP之后，扔到另一个队列，消费确认了，就删除该信息，但如果是失败情况，那就将数据放置回队头，这需要用lua来做原子性，这样业务开发实属复杂。
基于List的消息队列有哪些优缺点?
优点:
- 利用Redis存储，不受限于JVM内存上限
- 基于Redis的持久化机制，数据安全性有保证
- 可以满足消息有序性
缺点:
- 无法避免消息丢失
- 只支持单消费者
2.2 基于PubSub的消息队列
PubSub(发布订阅)是Redis2.0版本引入的消息传递模型。顾名思义，消费者可以订阅一个或多个channel,生产者向对应channel发送消息后，所有订阅者都能收到相关消息。
基于PubSub的消息队列有哪些优缺点?
优点:
- 采用发布订阅模型，支持多生产、多消费
缺点:
- 不支持数据持久化.
- 无法避免消息丢失ACK
- 消息堆积有上限，超出时数据丢失
2.3基于Stream的消息队列
Stream是Redis5.0引入的一种新的数据类型，可以实现一个功能非常完善的消息队列；
发送消息的命令XADD:
例如:
读取消息的方式之一XREAD:
XREAD阻塞方式，读取最新的消息:
在业务开发中，我们可以循环调用XREAD阻塞方式来查询最新消息，从而实现持续监听队列的效果，伪代码如下:
java
while(true){
// 尝试读取队列中的消息，最多阻塞2秒
Object msg = redis.execute("XREAD COUNT 1 BLOCK 2000 STREAMS users $");
if(msg == null){
continue;
}
// 处理消息
handleMessage(msg);
}
STREAM类型消息队列的XREAD命令特点:
- 消息可回溯
- 一个消息可以被多个消费者读取
- 可以阻塞读取
- 有消息漏读的风险
2.4 基于Sream的消息队列-消费者组
消费者组(ConsumerGroup):将多个消费者划分到一个组中，监听同一个队列。具备下列特点:
几种方式对比
- List，不需要ACK，不需要消费组，可用
- PUB/SUB，不需要ACK，不需要持久化，可用
- Stream，需要ACK，需要消费组，需要持久化，可用
Stream功能最全，但是相对完备的消息队列中间件比如Kafka，可靠性还是很大差距，不支持至少一次语意，因为Redis本身的数据持久化都是有时间空隙的,如果对数据的可靠要求比较强，还是需要用完整的消息中间件。
Redis这三种，是三种不同功能要求下的消息传递手段，Stream相对来说在轻量级里相对完善。
Redis可以做消息队列吗?什么时候能用Redis做消息队列?
个人认为Redis提供的队列都不是成熟的消息队列，原则上是不推荐的，但是如果真的场景够轻，同时又不想引入消息队列这么重的技术栈，是可以使用Stream做消息队列的，它是Redis中队列场景最为成熟的解决方案。