黑马点评：Redis消息队列【学习笔记】

目录

当前业务存在的问题

认识消息队列

List

PubSub (publish subscribe)​

Stream

单消费模式

消费者组模式

对比

异步秒杀优化

---

当前业务存在的问题

JVM内存限制：当前使用的是JDK提供的阻塞队列，使用的是JVM的内存，如果不加以限制，在高并发的情况下，就会有无数的订单对象需要创建并放到阻塞队列，超出JVM内存限制，导致内存溢出，虽然我们这里给长度设置了上限，但是如果订单太多，就塞不进去了  --->内存限制

数据安全：

1.如果服务突然宕机/重启，由于JVM内存没有持久化机制，内存里的订单信息丢失，后台没有订单数据，但用户已经下单付款了  --->数据不一致。

2.某一线程从队列里取出下单任务，若此时发生事故，任务就无法执行，但此时队列里已经没有该订单任务了  --->任务丢失。

认识消息队列

消息队列是JVM以外的一个独立的服务，不受JVM内存的限制  --->解决内存限制

消息队列不仅做数据存储，还确保了数据安全：有持久化机制，能持久保存  --->解决数据不一致

消息投递给消费者后，要求消费者做消息的确认，否则，消息依然存在于队列，下次依然投递给消费者，直到被确认，即消息至少被消费一次  --->解决任务丢失

List

PubSub (publish subscribe)

Stream

单消费模式

写：

读：

消费者组模式

对比

异步秒杀优化

（主要是为了替代原来的阻塞队列）

首先，添加队列以及对应的消费者组

修改lua脚本

注释掉之前的处理任务逻辑

改造：

由于已经在redis中判断过库存是否充足，以及该用户是否买过同一个优惠券。所以只要走到createVoucherOrder方法，几乎不可能存在扣减库存失败/插入订单失败，故这里没有必要再次保证原子性，也就不需要@Transactional注解，也就不用代理对象调用该方法了，也就不需要这里的proxy了，所以有关proxy的逻辑就可以删去了。

最终经测试，功能完整，这里不再展示，业务优化成功。