一、全局唯一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;

    @Autowired
    private 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.库存不足，返回1
    return 1
end
-- 3.2.判断用户是否下单 SISMEMBER orderKey userId
if(redis.call('sismember', orderKey, userId) == 1) then
    -- 3.3.存在，说明是重复下单，返回2
    return 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<Long> SECKILL_SCRIPT;

    static {
        SECKILL_SCRIPT = new DefaultRedisScript<>();
        SECKILL_SCRIPT.setLocation(new ClassPathResource("seckill.lua"));
        SECKILL_SCRIPT.setResultType(Long.class);
    }
    @Override
    public 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.判断结果是否为0
        if (r != 0) {
            // 2.1.不为0 ，代表没有购买资格
            return Result.fail(r == 1 ? "库存不足" : "不能重复下单");
        }
        // 3.发送消息队列 异步
        // 4.返回订单id
        return Result.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

（1）基本用法

是Redis 5.0引入的新数据

特点：

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

（2）消费者组

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

确认pending-list

查看pendingList

特点：

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

4、比较

	List	PubSub	Stream
消息持久化	支持	不支持	支持
阻塞读取	支持	支持	支持
消息堆积处理	受限于内存空间，可以利用多消费者加快处理	受限于消费者缓冲区	受限于队列长度，可以利用消费者组提高消息速度，减少堆积
消息回溯	不支持	不支持	支持