亲宝软件园·资讯

展开

Redis秒杀实现方案讲解

珠光 人气:0

一、全局唯一ID

(1)定义

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

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

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生成策略:

Redis自增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提供了三种不同的方式来实现消息队列:

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

消息队列就是存放消息的队列。而Redis的List数据结构是一个双向链表,很容易模拟。

队列是入口和出口不在一边,因此可以利用LPUSH结合RPOP来实现。

实现阻塞效果,应该使用BRPOP。

描述
优点1、利用Redis存储,不受限于JVM内存上限; 2、基于Redis的持久化机制,数据安全性有保障 3、可以满足消息有序性
缺点1、无法避免消息丢失 2、只支持单消费者

2、PubSub

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

描述
优点1、采用发布订阅模式,支持多生产、多消费
缺点1、不支持数据持久化 2、无法避免消息丢失 3、消息堆积有上限,超出时数据丢失

3、Stream

(1)基本用法

是Redis 5.0引入的新数据

特点:

(2)消费者组

消费者组(Consumer Group):将多个消费者划分到一个组中,监听同一个队列。特点如下:

确认pending-list

查看pendingList

特点:

4、比较

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

加载全部内容

相关教程
猜你喜欢
用户评论