黑马点评：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的逻辑就可以删去了。
最终经测试，功能完整，这里不再展示，业务优化成功。