一、全局唯一ID

（1）定义

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

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

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

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

（2）代码实现

@Component
public class RedisIdWorker {/*** 开始时间戳*/private static final long BEGIN_TIMESTAMP = 1640995200L;/*** 序列号的位数*/private static final int COUNT_BITS = 32;@Autowiredprivate StringRedisTemplate stringRedisTemplate;public long nextId(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.优惠券id
local voucherId = ARGV[1]
-- 1.2.用户id
local userId = ARGV[2]-- 2.数据key
-- 2.1.库存key
local stockKey = 'seckill:stock:' .. voucherId
-- 2.2.订单key
local orderKey = 'seckill:order:' .. voucherId-- 3.脚本业务
-- 3.1.判断库存是否充足 get stockKey
if(tonumber(redis.call('get', stockKey)) <= 0) then-- 3.2.库存不足，返回1return 1
end
-- 3.2.判断用户是否下单 SISMEMBER orderKey userId
if(redis.call('sismember', orderKey, userId) == 1) then-- 3.3.存在，说明是重复下单，返回2return 2
end
-- 3.4.扣库存 incrby stockKey -1
redis.call('incrby', stockKey, -1)
-- 3.5.下单（保存用户）sadd orderKey userId
redis.call('sadd', orderKey, userId)
return 0

    private static final DefaultRedisScript SECKILL_SCRIPT;static {SECKILL_SCRIPT = new DefaultRedisScript<>();SECKILL_SCRIPT.setLocation(new ClassPathResource("seckill.lua"));SECKILL_SCRIPT.setResultType(Long.class);}@Overridepublic Result seckillVoucher(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 ，代表没有购买资格return Result.fail(r == 1 ? "库存不足" : "不能重复下单");}// 3.发送消息队列 异步// 4.返回订单idreturn Result.ok(orderId);}

六、消息队列

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

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

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

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

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

消息队列就是存放消息的队列。而Redis的List数据结构是一个双向链表，很容易模拟。
队列是入口和出口不在一边，因此可以利用LPUSH结合RPOP来实现。
实现阻塞效果，应该使用BRPOP。

2、PubSub

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

• SUBSCRIBE channel [channel] ：订阅一个或多个频道
• PUBLISH channel msg: 向一个频道发送消息
• PSUBSCRIBE pattern [pattern] :订阅与pattern格式匹配的所有频道
  

3、Stream

（1）基本用法

是Redis 5.0引入的新数据

特点：

• 消息可回溯
• 一个消息可以被多个消费者读取
• 可以阻塞读取
• 有消息漏读的风险

（2）消费者组

消费者组（Consumer Group）：将多个消费者划分到一个组中，监听同一个队列。特点如下：

确认pending-list

查看pendingList

特点：

• 消息可回溯
• 可以多消费者争抢消息，加快消费速度
• 可以阻塞读取
• 没有消息漏读的风险
• 有消息确认机制，保证消息至少被消费一次

4、比较