Redis_实战2
秒杀优化
异步秒杀流程
- 将判断库存 & 判断重复下单 逻辑交给Redis
- 将耗时长的写数据库操作交给异步线程。
Redis：Key-stock:优惠券id，value-库存String（判断库存充足）
Redis：Key-order:优惠券id，value-用户id Set（判断重复下单）
流程1交给Lua脚本
流程2交给阻塞队列
数据库-扣减库存、创建订单的任务丢给阻塞队列。阻塞队列循环取出任务，并执行。
总结
秒杀业务的优化思路是什么
- 先利用redis完成库存余量、一人一单判断，完成抢单业务。
- 再将下单业务放入阻塞队列，利用独立线程异步下单。
基于阻塞队列的异步秒杀存在哪些问题
- 内存限制问题
- 数据安全问题
宕机-任务丢失、执行任务时出现事故-该任务未执行完-该任务丢失了
Redis消息队列
实现异步秒杀
消息队列，字面意思就是存放消息的队列。最简单的消息队列模型包括3个角色。
- 消息队列：存储和管理消息，也被称为消息代理。
- 生产者：发送消息到消息队列。
- 消费者：从消息队列获取消息并处理消息。
Redis提供了3种不同的方式来实现消息队列：
- list结构：基于list结构模拟消息队列
- 优点：
- 利用redis存储，不受限于JVM内存上限
- 基于redis的持久化机制，数据安全性有保证
- 可以满足消息有序性
- 缺点：
- 无法避免消息丢失
- 只支持单消费者
- Pubsub：基本的点对点消息模型
（发布订阅）消费者可以订阅一个或多个channel，生产者向对应channel发送消息后，所有订阅者都能收到相关消息。
- SUBSRIBE channel [channel]：订阅一个或多个频道
- PUBLISH channel msg：向一个频道发送消息
- PSUBSCRIBE pattern [pattern]：订阅与pattern格式匹配的所有频道。
- 优点
- 采用发布订阅模型，支持多生产，多消费
- 缺点
- 不支持数据持久化
- 无法避免消息丢失
- 消息堆积有上限（堆积在消费者那里），超出时数据丢失
- Stream：比较完善的消息队列模型
Stream是redis5.0引入的一种新数据类型，可以实现功能相对完善的消息队列。
发消息最简用法：XADD users * name jack age 21创建名为users的消息队列，并向其中发送一个消息，内容是{name=jack，age=21}，并使用redis自动生成id*。
XREAD阻塞方式，读取最新的消息：XREAD COUNT 1 BLOCK 1000 STREAMS users $
阻塞1000ms，读一条，$读最新消息（未被读过的消息。从名为users的消息队列读取。
$有小bug：当我们指定起始ID为$时，代表读取最新的消息，如果我们处理一条消息的过程中，又有超过1条以上的消息到达队列，则下次获取时也只能获取到最新的一条，会出现漏读消息的问题。
STREAM类型消息队列的XREAD命令特点：
- 消息可回溯
- 一个消息可以被多个消费者读取
- 可以阻塞读取
- 有消息漏读的风险
消费者组
将多个消费者划分到一个组中，监听同一个队列。
特点：
- 消息分流：队列中的消息分流给组内的不同消费者，而不是重复消费，从而加快消息处理的速度。
- 消息标示：记录最后一个被处理的消息，哪怕消费者宕机重启，还会从标示之后读取消息。确保每一个消息都会被消费。
- 消息确认：消费者获取消息后，消息处于pending状态，并存入一个pending-list。当处理完成后需要通过XACK来确认消息，标记消息为已处理，才会从pending-list移除。
STREAM类型消息队列的XREADGROUP命令特点：
- 消息可以回溯
- 可以多消费者争抢消息，加快消费速度
- 可以阻塞读取
- 没有消息漏读的风险
- 有消息确认机制，保证消息至少被消费一次。
独立于JVM之外，不受JVM内存限制
对比List、PubSub、Stream
- 消息持久化：支持---不支持---支持
- 阻塞读取：支持---支持---支持
- 消息堆积处理：受限于内存空间，可以利用多消费者加快处理---受限于消费者缓冲区---受限于队列长度，可以利用消费者组提高消费速度，减少堆积。
- 消息确认机制：不支持---不支持----支持
- 消息回溯：不支持---不支持---支持