Redis实战篇（三）秒杀

一、全局唯一ID

（1）定义

全局ID生成器，是一种在分布式系统下用来生成全局唯一ID的工具，一半满足下列特性：

唯一性
高可用
高性能
递增性
安全性

为了增加ID的安全性，我们不直接使用Redis自增的数值，而是拼接一些其他的信息。
ID的组成部分：

符号位：1bit，永远为0
时间戳：31bit，以秒为单位，可以使用69年
序列号：32bit，秒内计数器，支持每秒产生2ⁿ32个不同的ID

（2）代码实现

@ComponentpublicclassRedisIdWorker{/**
     * 开始时间戳
     */privatestaticfinallongBEGIN_TIMESTAMP=1640995200L;/**
     * 序列号的位数
     */privatestaticfinalintCOUNT_BITS=32;@AutowiredprivateStringRedisTemplate stringRedisTemplate;publiclongnextId(String keyPrefix){// 1.生成时间戳LocalDateTime now =LocalDateTime.now();long nowSecond = now.toEpochSecond(ZoneOffset.UTC);long timestamp = nowSecond -BEGIN_TIMESTAMP;// 2.生成序列号// 2.1.获取当前日期，精确到天String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));// 2.2.自增长long count = stringRedisTemplate.opsForValue().increment("icr:"+ keyPrefix +":"+ date);// 3.拼接并返回return timestamp <<COUNT_BITS| count;}}

（3）总结

全局唯一ID生成策略：

UUID
Redis自增
雪花算法
数据库自增

Redis自增ID策略：

每天一个key，方便统计
ID构造是时间戳 + 计数器

二、超卖问题

1、解决办法

超卖问题是典型的多线程安全问题，针对这一问题的常见解决方案就是加锁：

悲观锁认为线程安全问题一定会发生，因此在操作数据之前先获取锁，确保线程串行执行。例如Synchronized、Lock都属于悲观锁
乐观锁认为线程安全问题不一定会发生，因此不加锁，只是在更新数据时去判断有没有其他线程对数据进行了修改。如果没有修改则认为是安全的，自己才更新数据；如果已经被其他线程修改，说明了安全问题，此时可以重试或异常。

2、乐观锁

乐观锁的关键是判断之前查询得到的数据是否有被修改过，常见的方式有两种：

（1）版本号法

在这里插入图片描述

（2）CAS法

在这里插入图片描述

（3）总结

悲观锁乐观锁方案添加同步锁，让线程串行执行不加锁，在更新时判断是否有其他线程在修改优点简单粗暴性能好缺点性能一般存在成功率低的问题

四、分布式锁

五、Reids优化秒杀—异步执行

1、思路

（1）Lua脚本逻辑

判断库存是否充足：利用String类型
判断用户是否下单：利用Set类型
在这里插入图片描述

（2）java执行Lua脚本逻辑

在这里插入图片描述

（3）代码

-- 1.参数列表-- 1.1.优惠券idlocal voucherId = ARGV[1]-- 1.2.用户idlocal userId = ARGV[2]-- 2.数据key-- 2.1.库存keylocal stockKey ='seckill:stock:'.. voucherId
-- 2.2.订单keylocal orderKey ='seckill:order:'.. voucherId

-- 3.脚本业务-- 3.1.判断库存是否充足 get stockKeyif(tonumber(redis.call('get', stockKey))<=0)then-- 3.2.库存不足，返回1return1end-- 3.2.判断用户是否下单 SISMEMBER orderKey userIdif(redis.call('sismember', orderKey, userId)==1)then-- 3.3.存在，说明是重复下单，返回2return2end-- 3.4.扣库存 incrby stockKey -1
redis.call('incrby', stockKey,-1)-- 3.5.下单（保存用户）sadd orderKey userId
redis.call('sadd', orderKey, userId)return0

privatestaticfinalDefaultRedisScript<Long>SECKILL_SCRIPT;static{SECKILL_SCRIPT=newDefaultRedisScript<>();SECKILL_SCRIPT.setLocation(newClassPathResource("seckill.lua"));SECKILL_SCRIPT.setResultType(Long.class);}@OverridepublicResultseckillVoucher(Long voucherId){Long userId =UserHolder.getUser().getId();long orderId = redisIdWorker.nextId("order");// 1.执行lua脚本Long result = stringRedisTemplate.execute(SECKILL_SCRIPT,Collections.emptyList(),
                voucherId.toString(), userId.toString());int r = result.intValue();// 2.判断结果是否为0if(r !=0){// 2.1.不为0 ，代表没有购买资格returnResult.fail(r ==1?"库存不足":"不能重复下单");}// 3.发送消息队列 异步// 4.返回订单idreturnResult.ok(orderId);}

六、消息队列

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

消息队列：存储和管理消息，也被成为消息代理。
生产者：发送消息导消息队列
消费者：从消息队列获取消息并处理消息。

Redis提供了三种不同的方式来实现消息队列：

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

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

消息队列就是存放消息的队列。而Redis的List数据结构是一个双向链表，很容易模拟。
队列是入口和出口不在一边，因此可以利用LPUSH结合RPOP来实现。
实现阻塞效果，应该使用BRPOP。
描述优点1、利用Redis存储，不受限于JVM内存上限； 2、基于Redis的持久化机制，数据安全性有保障 3、可以满足消息有序性缺点1、无法避免消息丢失 2、只支持单消费者

2、PubSub

发布订阅模式，消费者可以订阅一个或多个channel，生产者向对应channel发送消息后，所有订阅者都能收到相关消息。

SUBSCRIBE channel [channel] ：订阅一个或多个频道
PUBLISH channel msg: 向一个频道发送消息
PSUBSCRIBE pattern [pattern] :订阅与pattern格式匹配的所有频道
描述优点1、采用发布订阅模式，支持多生产、多消费缺点1、不支持数据持久化 2、无法避免消息丢失 3、消息堆积有上限，超出时数据丢失
3、Stream