Redis：原理速成+项目实战——Redis实战9（秒杀优化）

👨?🎓作者简介：一位大四、研0学生，正在努力准备大四暑假的实习
🌌上期文章：Redis：原理速成+项目实战——Redis实战8（基于Redis的分布式锁及优化）
📚订阅专栏：Redis：原理速成+项目实战
希望文章对你们有所帮助

简单回顾一下之前实现秒杀的思路，其实无非就是2点：
1、库存够不够，该用户有没有买过
2、操作数据库（扣库存、创建订单）

之前的业务由于涉及了大量数据库的操作，所以性能并不是太好。

异步秒杀思路

之前的业务，可以用下图来表示：

可以发现，Tomcat中顺序执行的操作里面有4个需要对数据库进行查询或修改操作，而MySQL本身的并发能力就是很差的，时间是所有时间之和，这种解决方式并不好。
因此，我们需要将操作数据库的步骤分给多个线程来做，而库存量判断、是否具有购买资格的判断，我们也可以将其交给Redis，从而提高效率。
既然是将步骤分给多个线程来做，我们要开辟线程，并且要使得开辟的线程能够正确执行业务：

整个业务的流程被分开了，所需要的时间不再是所有的过程时间之和（完成下单的操作是异步执行的），而且整个业务基于Redis，将会大大提升业务的性能。
但这需要考虑2个难点问题：如何在Redis里面完成判断库存以及一人一单的校验？如何基于阻塞队列实现秒杀异步下单？

Redis实现秒杀资格的判断

分析

要在Redis里面判断库存量以及一人一单，我们肯定需要将优惠券的库存信息以及相关订单信息缓存到Redis中去，我们需要选取合适的数据结构来保存这两个信息。
库存很容易，因为只包含了库存量这个信息，直接使用String类型进行存储即可。
但要实现一人一单，我们要判断这个优惠券被哪些用户购买过。所以这个数据结构需要能够保存多个值，而又因为一人一单，所以我们要保存的用户的id显然是不能重复的。所以，set是很适合的。
因此业务流程可以很容易知道：

可以发现业务的步骤还是有很多步的，因此我们要保证步骤的原子性，因此上述的内容应当用Lua脚本来写。

实现

需求：

1、新增秒杀优惠券的同时，将优惠券的信息保存到Redis中
2、基于Lua脚本，判断秒杀库存、一人一单、决定用户是否抢购成功
3、若成功，将优惠券id与用户id进行封装，再存入阻塞队列
4、开启线程任务，不断从阻塞队列中获取信息，实现异步下单

1、在VoucherServiceImpl类中新增优惠券，同时保存到Redis中：

    @Resource
    private StringRedisTemplate stringRedisTemplate;

    @Override
    @Transactional
    public void addSeckillVoucher(Voucher voucher) {
        // 保存优惠券
        save(voucher);
        // 保存秒杀信息
        SeckillVoucher seckillVoucher = new SeckillVoucher();
        seckillVoucher.setVoucherId(voucher.getId());
        seckillVoucher.setStock(voucher.getStock());
        seckillVoucher.setBeginTime(voucher.getBeginTime());
        seckillVoucher.setEndTime(voucher.getEndTime());
        seckillVoucherService.save(seckillVoucher);
        //保存秒杀库存到Redis中, SECKILL_STOCK_KEY = "seckill:stock:"
        stringRedisTemplate.opsForValue().set(SECKILL_STOCK_KEY + voucher.getId(), voucher.getStock().toString());
    }

打开postman，进行测试：

添加成功：

2、在resources下创建seckill.lua，决定用户能否抢券成功：

-- 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 判断库存是够充足
if(tonumber(redis.call('get', stockKey)) <= 0) then
    -- 3.2 库存不足，返回1
    return 1
end
--3.2 判断用户是否下单，即判断用户id是不是这个set集合的成员
if(redis.call('sismember', orderKey, userId) == 1) then
    -- 3.2 存在，说明重复下单
    return 2
end
-- 3.4 扣库存
redis.call('incrby', stockKey, -1)
-- 3.5 下单（保存用户）
redis.call('sadd', orderKey, userId)
return 0

3、在VoucherOrderServiceImpl中修改seckillVoucher，修改业务，先调用Lua脚本执行，返回0即可将下单信息存入阻塞队列（存入阻塞队列的代码编写较为麻烦，暂时放着）：

    //秒杀优化，调用Lua的代码
    @Override
    public Result seckillVoucher(Long voucherId) {
        //获取用户
        Long userId = UserHolder.getUser().getId();
        //执行Lua脚本，这里使用了静态代码块
        Long result = stringRedisTemplate.execute(
                SECKILL_SCRIPT,
                Collections.emptyList(), //这里我们没有key传，只需要传送一个空集合即可
                voucherId.toString(), userId.toString()//传其他类型的参数
        );
        //判断结果是否为0
        int r = result.intValue();
        if(r != 0){
            //不为0，没有购买资格
            return Result.fail(r == 1 ? "库存不足" : "不能重复下单");
        }
        //为0，有购买资格，将下单信息保存到阻塞队列
        long orderId = redisIdWorker.nextId("order");
        //TODO 保存阻塞队列，这边先空着，下一部分单独编写

        //返回订单id
        return Result.ok(orderId);
    }

打开postman进行测试，连续下单两次，证明下单资格判断的可行性：



当然数据库中的数据还是没有改变的， 异步下单还没做。

如果要进行压力测试的话，大家要自己构建出几百个用户，然后这些用户分别占一个线程进行下单，用jmeter进行测试，完成这些测试还是很繁琐的，但是因为这些操作都是基于Redis的，容易知道吞吐率肯定是变大了不少的。

基于阻塞队列实现秒杀异步下单

对于用户资格的判断已经完成了，假设用户具有秒杀的资格，这时候我们只需要独立开辟一个线程，去异步实现下单。因为用户只要具有这个资格，直接返回订单的id从而让用户去执行付款即可，而将订单的信息存入数据库并不需要严格的时效性，因此业务可行：

接下来，开启线程任务，不断从阻塞队列中获取信息，实现下单，这是整体性能变高的关键。
代码的实现，我们之所以选择阻塞队列，是因为阻塞队列具有一个重要的性质：当线程尝试获取阻塞队列的元素时，若队列中没有元素，该线程就会被阻塞，直到队列中获取到这个元素了。
另外代码中因为涉及了开辟独立线程去实现异步下单，因此我们需要准备好线程池与线程任务。
最终业务的全部代码实现如下：

@Slf4j
@Service
public class VoucherOrderServiceImpl extends ServiceImpl<VoucherOrderMapper, VoucherOrder> implements IVoucherOrderService {

    //注入秒杀优惠券的service
    @Resource
    private ISeckillVoucherService seckillVoucherService;

    @Resource
    private RedisIdWorker redisIdWorker;
    
    @Resource
    private StringRedisTemplate stringRedisTemplate;

    @Resource
    private RedissonClient redissonClient;

    public static final DefaultRedisScript<Long> SECKILL_SCRIPT;
    static {
        SECKILL_SCRIPT = new DefaultRedisScript<>();
        SECKILL_SCRIPT.setLocation(new ClassPathResource("seckill.lua"));//设置脚本位置
        SECKILL_SCRIPT.setResultType(Long.class);//配置返回值
    }

    //阻塞队列：当线程尝试从这个队列中获取元素，如果没有元素，那么该线程就会被阻塞，直到队列中获取到元素
    private BlockingQueue<VoucherOrder> orderTasks = new ArrayBlockingQueue<>(1024 * 1024);
    //线程池
    private static final ExecutorService SECKILL_ORDER_EXECUTOR = Executors.newSingleThreadExecutor();

    //线程任务，用户随时都能抢单，所以应该要在这个类被初始化的时候马上开始执行
    @PostConstruct  //该注解表示在当前类初始化完毕以后立即执行
    private void init(){
        SECKILL_ORDER_EXECUTOR.submit(new VoucherOrderHandler());
    }

    private class VoucherOrderHandler implements Runnable{

        @Override
        public void run() {
            //不断从队列中取订单信息
            while (true){
                try {
                    VoucherOrder voucherOrder = orderTasks.take();
                    //创建订单，流程里面无须再加锁，加个锁就是做个兜底
                    handleVoucherOrder(voucherOrder);
                } catch (Exception e) {
                    //e.printStackTrace();
                    log.error("创建订单异常", e);
                }
            }
        }
    }

    IVoucherOrderService proxy;

    //秒杀优化，调用Lua的代码
    @Override
    public Result seckillVoucher(Long voucherId) {
        //获取用户
        Long userId = UserHolder.getUser().getId();
        //执行Lua脚本，这里使用了静态代码块
        Long result = stringRedisTemplate.execute(
                SECKILL_SCRIPT,
                Collections.emptyList(), //这里我们没有key传，只需要传送一个空集合即可
                voucherId.toString(), userId.toString()//传其他类型的参数
        );
        //判断结果是否为0
        int r = result.intValue();
        if(r != 0){
            //不为0，没有购买资格
            return Result.fail(r == 1 ? "库存不足" : "不能重复下单");
        }
        //为0，有购买资格，将下单信息保存到阻塞队列
        long orderId = redisIdWorker.nextId("order");
        //TODO 保存阻塞队列
        //先将用户id与订单id封装起来
        VoucherOrder voucherOrder = new VoucherOrder();
        voucherOrder.setId(orderId);
        voucherOrder.setUserId(userId);
        voucherOrder.setVoucherId(voucherId);
        //放入阻塞队列
        orderTasks.add(voucherOrder);
        //获取代理对象
        proxy = (IVoucherOrderService) AopContext.currentProxy();

        //返回订单id
        return Result.ok(orderId);
    }

    private void handleVoucherOrder(VoucherOrder voucherOrder) {
        //获取用户，用户id不能再从UserHolder中取了，因为现在是从线程池获取的全新线程，不是主线程
        Long userId = voucherOrder.getUserId();
        //创建锁对象
        RLock lock = redissonClient.getLock("lock:order:" + userId);
        //获取锁
        boolean isLock = lock.tryLock();
        //判断是否获取锁成功
        if(!isLock){
            log.error("不允许重复下单");//理论上不会发生
            return;
        }
        try {
            //这是主线程的一个子线程，无法直接获得代理对象，代理对象需要在主线程中获取，并设置成成员变量使得该子线程能够获取
            //createVoucherOrder的方法体直接修改，不再需要重新根据id创建订单，而是直接将订单传进去
            proxy.createVoucherOrder(voucherOrder);
        } finally {
            lock.unlock();
        }
    }

    @Transactional
    public void createVoucherOrder(VoucherOrder voucherOrder) {
        Long userId = voucherOrder.getUserId();
        //查询订单
        int count = query().eq("user_id", userId).eq("voucher_id", voucherOrder.getVoucherId()).count();
        //判断是否存在
        if (count > 0) {
            log.error("不可重复购买");
            return;
        }
        //扣减库存
        boolean success = seckillVoucherService.update().
                setSql("stock = stock - 1").
                eq("voucher_id", voucherOrder.getVoucherId()).
                gt("stock", 0).
                update();
        if (!success) {
            log.error("库存不足");
            return;
        }
        //不需要再创建订单，直接save
        save(voucherOrder);
    }
}

总结及发现问题

1、秒杀业务的优化思路

（1）先用Redis完成库存量以及一人一单判断，完成抢单
（2）下单的业务（操作数据库的业务）放入阻塞队列，并用独立线程完成异步下单

2、基于阻塞队列的异步秒杀存在的问题

（1）内存限制问题：我们使用了JDK的阻塞队列，占用的是JVM内存，若不加以限制，会有很多的订单对象创建线程并且将大量信息放入阻塞队列，可能会内存溢出
（2）数据安全问题：要用于下单的业务信息都存到了内存中，万一服务宕机，那么用户完成了抢单，但是数据库却没有做出相应的修改，将会导致数据不一致

解决的方法将在下一节进行分析