文章目录
Redis消息队列实现异步秒杀
1. jvm阻塞队列问题
java使用阻塞队列实现异步秒杀存在问题：
- jvm内存限制问题：jvm内存不是无限的，在高并发的情况下，当有大量的订单需要创建时，就有可能超出jvm阻塞队列的上限。
- 数据安全问题：jvm的内存没有持久化机制，当服务重启或宕机时，阻塞队列中的订单都会丢失。或者，当我们从阻塞队列中拿到订单任务，但是尚未处理时，如果此时发生了异常，这个订单任务就没有机会处理了，也就丢失了。
2. 什么是消息队列
消息队列 （M essage 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?llosubscribes tohello,halloandhxllo - *匹配0个或多个字符：
h*llosubscribes tohlloandheeeello - \[\]指定字符：
h[ae]llosubscribes tohelloandhallo,but nothillo
- ?匹配1个字符：
操作
优缺点
优点：
- 采用发布订阅模型，支持多生产、多消费
缺点：
- 不支持数据持久化（如果发送消息时，这个消息的频道没有被任何人订阅，那这个消息就丢失了，也消息就是不会被保存）
- 无法避免消息丢失（发完了，没人收，直接就丢了）
- 消息堆积有上限，超出时数据丢失（当我们发送消息时，如果有消费者在监听，消费者会有1个缓存区去缓存这个消息数据，如果消费者处理的慢，那么客户端的缓存区中的消息会不断堆积，而这个缓存区是有大小限制的，如果超出了就会丢失）