Redis实现消息队列

Redis消息队列实现异步秒杀

1. jvm阻塞队列问题

java使用阻塞队列实现异步秒杀存在问题：

1. jvm内存限制问题：jvm内存不是无限的，在高并发的情况下，当有大量的订单需要创建时，就有可能超出jvm阻塞队列的上限。
2. 数据安全问题：jvm的内存没有持久化机制，当服务重启或宕机时，阻塞队列中的订单都会丢失。或者，当我们从阻塞队列中拿到订单任务，但是尚未处理时，如果此时发生了异常，这个订单任务就没有机会处理了，也就丢失了。

2. 什么是消息队列

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

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

（正常下单，我们需要将订单消息写入数据库。但由于秒杀并发访问量大，数据库本身并发处理能力不强，因此，在处理秒杀业务时，可以将部分业务在生产者这边做校验，然后将消息写入消息队列，而消费者处理该消息队列中的消息，从而实现双方解耦，更快的处理秒杀业务）

3. Redis实现消息队列

我们可以使用一些现成的mq，比如kafka，rabbitmq等等，但是呢，如果没有安装mq，我们也可以直接使用redis提供的mq方案，降低我们的部署和学习成本。Redis提供了三种不同的方式来实现消息队列：

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

1. 基于List结构模拟消息队列

消息队列（Message Queue），字面意思就是存放消息的队列。而Redis的list数据结构是一个双向链表，很容易模拟出队列效果。

队列是入口和出口不在一边，因此我们可以利用：LPUSH 结合 RPOP、或者 RPUSH 结合 LPOP来实现。

不过要注意的是，当队列中没有消息时RPOP或LPOP操作会返回null，并不像JVM的阻塞队列那样会阻塞并等待消息。因此这里应该使用BRPOP或者BLPOP来实现阻塞效果。

操作

命令介绍如下

优缺点

优点：

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

缺点：

• 无法避免消息丢失（如果消费者获取消息后，然后立马就宕机了，这个消息就得不到处理，等同于丢失了）
• 只支持单消费者（1个消息只能被1个消费者取走，其它消费者会收不到此消息）

2. 基于PubSub发布订阅的消息队列

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

• SUBSCRIBE channel [channel] ：订阅一个或多个频道
• PUBLISH channel msg ：向一个频道发送消息
• PSUBSCRIBE pattern [pattern] ：订阅与pattern格式匹配的所有频道
  • ?匹配1个字符：h?llo subscribes to hello, hallo and hxllo
  • *匹配0个或多个字符：h*llo subscribes to hllo and heeeello
  • []指定字符：h[ae]llo subscribes to hello and hallo, but not hillo

操作

优缺点

优点：

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

缺点：

• 不支持数据持久化（如果发送消息时，这个消息的频道没有被任何人订阅，那这个消息就丢失了，也消息就是不会被保存）
• 无法避免消息丢失（发完了，没人收，直接就丢了）
• 消息堆积有上限，超出时数据丢失（当我们发送消息时，如果有消费者在监听，消费者会有1个缓存区去缓存这个消息数据，如果消费者处理的慢，那么客户端的缓存区中的消息会不断堆积，而这个缓存区是有大小限制的，如果超出了就会丢失）

spring 结合redis的pubsub使用示例