Redis秒杀实现方案讲解

目录

• 一、全局唯一ID
• 二、超卖问题
• 1、解决办法
• 2、乐观锁
• 四、分布式锁
• 五、Reids优化秒杀—异步执行
• 1、思路
• 六、消息队列
• 1、基于List结构模拟消息队列
• 2、PubSub
• 3、Stream
• 4、比较

一、全局唯一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 http://www.devze.com+ ":" + date);
        // 3.拼接并返回
        return timestamp << COUNT_BITS | count;
    }
}

（3）总结

全局唯一ID生成策略：

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

Redis自增ID策略：

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

二、超卖问题

1、解决办法

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

悲观锁

认为线程安全问题一定会发生，因此在操作数据之前先获取锁，确保线程串行执行。例如Synchronized、Lock都属于悲观锁

乐观锁

认为线程安全问题不一定会发生，因此不加锁，只是在更新数据时去判断有没有其他线程对数据进行了修改。如果没有修改则认为是安全的，自己才更新数据；如果已经被其他线程修改，说明了安全问题，此时可以重试或异常。

2、乐观javascript锁

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

（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 Dewww.devze.comfaultRedisScript<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结构模拟消息队列

消息队列就是存放消息的队列。而R开发者_NoSQLedis的List数据结构是一个双向链表，很容易模拟。

队列是入口和出口不在一边，因此可以利用LP编程客栈USH结合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
消息持久化	支持	不支持	支持
阻塞读取	支持	支持	支持
消息堆积处理	受限于内存空间，可以利用多消费者加快处理	受限于消费者缓冲区	受限于队列长度，可以利用消费者组提高消息速度，减少堆积
消息回溯	不支持	不支持	支持

到此这篇关于Redis秒杀实现方案讲解的文章就介绍到这了,更多相关Redis秒杀内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！