黑马程序猿 - Redis - 实战篇 - 6.秒杀优化

最新推荐文章于 2025-05-11 19:51:12 发布

夏驰和徐策

最新推荐文章于 2025-05-11 19:51:12 发布

阅读量599

点赞数 10

分类专栏： # Redis 文章标签： redis

本文链接：https://blog.csdn.net/tang7mj/article/details/147855916

版权

Redis 专栏收录该内容

11 篇文章

订阅专栏

6、秒杀优化

6.1 秒杀优化-异步秒杀思路

我们来回顾一下下单流程

当用户发起请求，此时会请求nginx，nginx会访问到tomcat，而tomcat中的程序，会进行串行操作，分成如下几个步骤

1、查询优惠卷

2、判断秒杀库存是否足够

3、查询订单

4、校验是否是一人一单

5、扣减库存

6、创建订单

在这六步操作中，又有很多操作是要去操作数据库的，而且还是一个线程串行执行，这样就会导致我们的程序执行的很慢，所以我们需要异步程序执行，那么如何加速呢？

在这里笔者想给大家分享一下课程内没有的思路，看看有没有小伙伴这么想，比如，我们可以不可以使用异步编排来做，或者说我开启N多线程，N多个线程，一个线程执行查询优惠卷，一个执行判断扣减库存，一个去创建订单等等，然后再统一做返回，这种做法和课程中有哪种好呢？答案是课程中的好，因为如果你采用我刚说的方式，如果访问的人很多，那么线程池中的线程可能一下子就被消耗完了，而且你使用上述方案，最大的特点在于，你觉得时效性会非常重要，但是你想想是吗？并不是，比如我只要确定他能做这件事，然后我后边慢慢做就可以了，我并不需要他一口气做完这件事，所以我们应当采用的是课程中，类似消息队列的方式来完成我们的需求，而不是使用线程池或者是异步编排的方式来完成这个需求

优化方案：我们将耗时比较短的逻辑判断放入到redis中，比如是否库存足够，比如是否一人一单，这样的操作，只要这种逻辑可以完成，就意味着我们是一定可以下单完成的，我们只需要进行快速的逻辑判断，根本就不用等下单逻辑走完，我们直接给用户返回成功，再在后台开一个线程，后台线程慢慢的去执行queue里边的消息，这样程序不就超级快了吗？而且也不用担心线程池消耗殆尽的问题，因为这里我们的程序中并没有手动使用任何线程池，当然这里边有两个难点

第一个难点是我们怎么在redis中去快速校验一人一单，还有库存判断

第二个难点是由于我们校验和tomct下单是两个线程，那么我们如何知道到底哪个单他最后是否成功，或者是下单完成，为了完成这件事我们在redis操作完之后，我们会将一些信息返回给前端，同时也会把这些信息丢到异步queue中去，后续操作中，可以通过这个id来查询我们tomcat中的下单逻辑是否完成了。

我们现在来看看整体思路：当用户下单之后，判断库存是否充足只需要导redis中去根据key找对应的value是否大于0即可，如果不充足，则直接结束，如果充足，继续在redis中判断用户是否可以下单，如果set集合中没有这条数据，说明他可以下单，如果set集合中没有这条记录，则将userId和优惠卷存入到redis中，并且返回0，整个过程需要保证是原子性的，我们可以使用lua来操作

当以上判断逻辑走完之后，我们可以判断当前redis中返回的结果是否是0 ，如果是0，则表示可以下单，则将之前说的信息存入到到queue中去，然后返回，然后再来个线程异步的下单，前端可以通过返回的订单id来判断是否下单成功。

🧠 理论理解：

原始秒杀流程中，下单操作是串行执行的，涉及多个数据库查询与写入，极易成为性能瓶颈。
异步秒杀的核心思路：将前端请求快速通过 Redis 校验处理资格，主线程立即响应，后续下单流程由异步线程慢慢处理（如通过阻塞队列 + 后台线程/消息队列）。
优点：
- 减少数据库压力
- 提升系统吞吐量
- 用户体验更流畅

🏢 大厂实战理解：

阿里在双 11 等大促场景中，采用了 “前端快速响应 + 后台异步创建订单” 的设计，异步消息通过 MQ（如 RocketMQ）分发。
字节跳动在抖音直播秒杀带货中，使用 Kafka + Redis 结合，实现高并发下的异步订单处理。
Google 在 Cloud Tasks 任务执行平台中，也采用了异步处理队列和状态追踪方式，支持任务弹性调度。
OpenAI 在模型微调任务中，通过分布式异步工作流系统控制模型训练调度，类似于将下单任务拆分异步分发。

问题 1：你如何理解秒杀系统的核心难点？

🧠 答案：
秒杀系统的核心难点可以归纳为四个方面：

1️⃣ 高并发压力： 瞬时 QPS（每秒请求数）可达到数十万甚至百万级，传统单体系统无法承受，需要用分布式架构、缓存、限流等手段削峰填谷。

2️⃣ 一致性与准确性： 要确保库存扣减准确，避免超卖；要防止重复下单、一人多单等业务违规。

3️⃣ 性能与延迟： 用户秒杀体验极为敏感，如果后端响应慢、前端卡顿，可能引发投诉、流失，甚至带来商誉损失。

4️⃣ 扩展性与可维护性： 系统不仅要能抗瞬时高峰，还要具备水平扩展、异步解耦、故障恢复等能力，方便后续维护与优化。

在 BAT、字节、京东这种公司，通常会用 Redis + 消息队列（如 RocketMQ、Kafka）+ 异步工作流来解决，并引入压测（如 Gatling、Locust）提前发现系统瓶颈。

🌍 场景 1：字节跳动电商秒杀活动峰值超 100 万 QPS，如何保证库存准确扣减、不超卖？

🛠 选择方案：
✅ Redis + Lua 脚本实现原子性判断（库存、资格） + 异步消息队列落单

🛠 实现步骤：
1️⃣ 提前将秒杀券库存加载到 Redis，使用 seckill:stock:{voucherId} Key 维护库存。
2️⃣ 用户下单请求进入时，用 Lua 脚本：

判断库存 > 0
判断用户未下单（SISMEMBER seckill:order:{voucherId} userId）
库存减一，用户 ID 写入 Set，订单消息 XADD 到 Stream
3️⃣ 后台异步消费 Stream，落地 MySQL。

🛠 遇到的坑：

Redis 单线程瓶颈：解决方案 → 水平拆分不同活动到多个 Redis 实例。
Stream 消费积压：解决方案 → 多个消费者分组 + 定期监控 Pending List。
重启丢缓存：解决方案 → 定期同步 Redis 库存到 DB、用 RocketMQ 替代内存流。

6.2 秒杀优化-Redis完成秒杀资格判断

需求：

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

VoucherServiceImpl

@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 这个变量定义在RedisConstans中
    //private static final String SECKILL_STOCK_KEY ="seckill:stock:"
    stringRedisTemplate.opsForValue().set(SECKILL_STOCK_KEY + voucher.getId(), voucher.getStock().toString());
}

完整lua表达式

-- 1.参数列表
-- 1.1.优惠券id
local voucherId = ARGV[1]
-- 1.2.用户id
local userId = ARGV[2]
-- 1.3.订单id
local orderId = ARGV[3]

-- 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)
-- 3.6.发送消息到队列中， XADD stream.orders * k1 v1 k2 v2 ...
redis.call('xadd', 'stream.orders', '*', 'userId', userId, 'voucherId', voucherId, 'id', orderId)
return 0

当以上lua表达式执行完毕后，剩下的就是根据步骤3,4来执行我们接下来的任务了

VoucherOrderServiceImpl

@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(), String.valueOf(orderId)
    );
    int r = result.intValue();
    // 2.判断结果是否为0
    if (r != 0) {
        // 2.1.不为0 ，代表没有购买资格
        return Result.fail(r == 1 ? "库存不足" : "不能重复下单");
    }
    //TODO 保存阻塞队列
    // 3.返回订单id
    return Result.ok(orderId);
}

🧠 理论理解：

Redis 脚本使用 Lua 实现原子操作，具备以下优势：
- 保证库存扣减 + 重复下单校验 + 推送订单流入消息队列的原子性。
- 彻底消除并发条件下的竞态问题。
- Lua 在 Redis 内部执行，性能极高，延迟极低。
秒杀逻辑用 incrby 扣减库存，sadd 记录下单用户，xadd 推入 Stream 队列。

🏢 大厂实战理解：

阿里巴巴的红包雨、优惠券活动采用 Redis Lua 脚本保障并发一致性。
字节在红包系统和活动抽奖中也广泛使用 Redis 脚本进行资格验证。
NVIDIA 的 Jetson 模型市场，在资源有限时对 GPU License 分配采用 Redis + Lua 保证并发分配的公平性。
Google Pub/Sub 流控策略中也会用到服务端 Lua 实现异步消费限制与回退。

问题 2：为什么需要 Redis + Lua 脚本完成秒杀资格判断，而不是用 Java 代码？

🧠 答案：
原因分三点：

✅ 原子性： Java 是客户端，多条 Redis 命令之间不能保证原子性，而 Lua 脚本在 Redis 内部执行，可以将多步操作（如判断库存、扣减库存、写入订单）打包成一条指令，确保并发安全。

✅ 性能： Lua 脚本在 Redis 内部运行，避免了网络 IO 的多次往返，减少了延迟，提高了处理速度。

✅ 简化业务逻辑： 用 Lua 写核心校验，Java 侧只需关注异步分发、后续处理，整体系统更清晰、职责更分明。

在大厂如字节，Lua 脚本通常会配合 Redis Stream、HLL、Bloom Filter 等一起使用，减少后端校验压力。

🌍 场景 2：阿里天猫双 11 跨国大促，多地多机房并发秒杀，如何避免主从漂移造成的锁丢失？

🛠 选择方案：
✅ Redisson MultiLock 或 RedLock 跨多个独立 Redis 实例加锁

🛠 实现步骤：
1️⃣ 配置至少 5 个跨机房 Redis 节点。
2️⃣ 加锁时在半数以上节点成功写入 Lock Key（超时秒数短，保证快速失败）。
3️⃣ 定时 Watchdog 自动续期，防止业务超时释放锁。
4️⃣ 加锁失败直接快速返回，交由流量削峰、限流组件处理。

🛠 遇到的坑：

节点时钟漂移：需要 NTP 同步、校准节点时间。
网络分区导致局部锁失效：需严格监控心跳、健康检查、Failover 方案。
Redisson MultiLock 性能下降：可以分流业务到不同分布式锁分组，避免大锁全局串行。

6.3 秒杀优化-基于阻塞队列实现秒杀优化

VoucherOrderServiceImpl

修改下单动作，现在我们去下单时，是通过lua表达式去原子执行判断逻辑，如果判断我出来不为0 ，则要么是库存不足，要么是重复下单，返回错误信息，如果是0，则把下单的逻辑保存到队列中去，然后异步执行

//异步处理线程池
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 {
                    // 1.获取队列中的订单信息
                    VoucherOrder voucherOrder = orderTasks.take();
                    // 2.创建订单
                    handleVoucherOrder(voucherOrder);
                } catch (Exception e) {
                    log.error("处理订单异常", e);
                }
             }
        }
     
       private void handleVoucherOrder(VoucherOrder voucherOrder) {
            //1.获取用户
            Long userId = voucherOrder.getUserId();
            // 2.创建锁对象
            RLock redisLock = redissonClient.getLock("lock:order:" + userId);
            // 3.尝试获取锁
            boolean isLock = redisLock.lock();
            // 4.判断是否获得锁成功
            if (!isLock) {
                // 获取锁失败，直接返回失败或者重试
                log.error("不允许重复下单！");
                return;
            }
            try {
                //注意：由于是spring的事务是放在threadLocal中，此时的是多线程，事务会失效
                proxy.createVoucherOrder(voucherOrder);
            } finally {
                // 释放锁
                redisLock.unlock();
            }
    }
     //a
    private BlockingQueue<VoucherOrder> orderTasks =new  ArrayBlockingQueue<>(1024 * 1024);

    @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(), String.valueOf(orderId)
        );
        int r = result.intValue();
        // 2.判断结果是否为0
        if (r != 0) {
            // 2.1.不为0 ，代表没有购买资格
            return Result.fail(r == 1 ? "库存不足" : "不能重复下单");
        }
        VoucherOrder voucherOrder = new VoucherOrder();
        // 2.3.订单id
        long orderId = redisIdWorker.nextId("order");
        voucherOrder.setId(orderId);
        // 2.4.用户id
        voucherOrder.setUserId(userId);
        // 2.5.代金券id
        voucherOrder.setVoucherId(voucherId);
        // 2.6.放入阻塞队列
        orderTasks.add(voucherOrder);
        //3.获取代理对象
         proxy = (IVoucherOrderService)AopContext.currentProxy();
        //4.返回订单id
        return Result.ok(orderId);
    }
     
      @Transactional
    public  void createVoucherOrder(VoucherOrder voucherOrder) {
        Long userId = voucherOrder.getUserId();
        // 5.1.查询订单
        int count = query().eq("user_id", userId).eq("voucher_id", voucherOrder.getVoucherId()).count();
        // 5.2.判断是否存在
        if (count > 0) {
            // 用户已经购买过了
           log.error("用户已经购买过了");
           return ;
        }

        // 6.扣减库存
        boolean success = seckillVoucherService.update()
                .setSql("stock = stock - 1") // set stock = stock - 1
                .eq("voucher_id", voucherOrder.getVoucherId()).gt("stock", 0) // where id = ? and stock > 0
                .update();
        if (!success) {
            // 扣减失败
            log.error("库存不足");
            return ;
        }
        save(voucherOrder);
 
    }

🧠 理论理解：

利用 Java 的 BlockingQueue（如 ArrayBlockingQueue）存储 Redis 资格校验通过的下单请求。
后台线程池持续消费队列：
- 使用 Redisson 获取分布式锁（防止一人多单）
- 执行数据库扣库存、落单等操作
使用 Spring 的 @PostConstruct 启动消费线程，并注意事务隔离和线程安全问题。

🏢 大厂实战理解：

阿里在微服务架构中，采用 Disruptor + RocketMQ 组合提升下单队列性能，核心订单系统用线程隔离做异步处理。
字节跳动推荐系统的行为日志、订单日志统一投递至日志中心（Kafka），由异步任务落地 DB。
OpenAI 在多模型并发 Fine-tune 的任务中，也使用队列与 GPU 资源绑定，串行控制同用户同模型调度。
Google 和 NVIDIA 的异步资源调度器普遍会采用限量队列 +锁机制，保障公平性和幂等性。

问题 3：阻塞队列和消息队列（如 Kafka、RocketMQ）在异步下单中的优劣？

🧠 答案：

对比项	阻塞队列（Java 内存）	消息队列（Kafka/RocketMQ）
性能	内存高性能，毫秒级延迟	分布式、跨机器，延迟略高但可接受
容错性	单节点内存，进程挂了数据丢失	分布式存储，有持久化、消息确认、重试机制
扩展性	单机容量有限，难以扩展	多节点水平扩展，支持超大规模吞吐
使用场景	小规模项目、原型验证、单节点轻量化	中大型项目、核心业务、跨服务异步解耦、流量削峰

大厂实际生产中，阿里、字节通常直接用 RocketMQ、Kafka 来做异步下单，阻塞队列更常用在单机测试或小型活动中。

问题 4：如果 Lua 脚本出现阻塞或执行超时，会对 Redis 带来什么影响？你如何优化？

🧠 答案：
Lua 脚本执行期间，Redis 是单线程的，长时间运行的脚本会阻塞其他命令执行，导致整个 Redis 实例“卡死”。优化方法：

✅ 严格控制 Lua 脚本内容，禁止循环、递归、慢查询等复杂逻辑。
✅ 使用 Redis 的 SCRIPT KILL 命令终止长时间运行的脚本（但要慎用，可能导致部分业务逻辑未完成）。
✅ 将复杂业务拆解成多个简单原子步骤，或考虑使用 Redisson 分布式锁替代部分 Lua 控制逻辑。

大厂实践中，字节、阿里有专门的 Redis 脚本测试平台，确保上线脚本都经过严格审查和压测。

问题 5：异步秒杀架构如何确保订单最终一致性？

🧠 答案：
确保最终一致性可以通过以下机制实现：

✅ 幂等性设计： 每个订单操作都带唯一业务 ID（如全局唯一订单号），即使重复执行也不会产生副作用。
✅ 消息可靠投递： 使用消息队列的消息确认、持久化、重试、死信队列机制，保证重要订单消息不会丢失。
✅ 后台补偿机制： 定期扫描 Redis、DB，检查有资格但未成功下单的记录，手动或自动补偿。

例如在阿里、京东，订单系统通常分为事务型（主流程）和异步型（补偿、重放）两套，确保即便主流程中断，最终结果也能回归一致。

问题 6：如何在多机部署中防止 Redis 分布式锁失效？

🧠 答案：
单 Redis 实例存在主从切换时数据丢失、锁误释放的风险，可以采用以下方案：

✅ Redisson MultiLock： 在多个独立 Redis 实例上加锁，半数以上成功才算加锁成功。
✅ RedLock 算法： 用 Redis 原作者提出的方案，跨多个 Redis 节点生成锁，提高容错能力。
✅ Zookeeper 分布式锁： 如果对一致性要求极高，可以直接用 Zookeeper 提供的原生锁机制（代价是性能稍低）。

大厂中，阿里、字节通常用 Redisson MultiLock，Google、NVIDIA 在高一致性场景下可能选择 etcd 或 Zookeeper。

小总结：

秒杀业务的优化思路是什么？

先利用Redis完成库存余量、一人一单判断，完成抢单业务
再将下单业务放入阻塞队列，利用独立线程异步下单
基于阻塞队列的异步秒杀存在哪些问题？
- 内存限制问题
- 数据安全问题

🌍 场景 3：Google Cloud Tasks 分布式任务调度，如何确保大规模任务幂等、唯一？

🛠 选择方案：
✅ 全局唯一 ID + 分布式锁 + 幂等处理

🛠 实现步骤：
1️⃣ 所有任务生成基于 Redis 的全局唯一 ID（如 RedisIdWorker 实现的时间戳 + 序列号）。
2️⃣ 任务调度前，先基于任务 ID 获取分布式锁（Redisson），只允许一个线程执行。
3️⃣ 任务入库、状态更新等操作必须设计幂等：即重复执行不会引起数据污染。
4️⃣ 出错任务进入重试队列或死信队列，由后台专用任务补偿。

🛠 遇到的坑：