深入解析秒杀业务中的核心问题 —— 从并发控制到事务管理

最新推荐文章于 2024-10-12 17:55:45 发布

codefly-xtl

最新推荐文章于 2024-10-12 17:55:45 发布

阅读量842

点赞数 24

分类专栏： Java 文章标签： java sql 数据库

本文链接：https://blog.csdn.net/qq_42798343/article/details/142027104

版权

Java 专栏收录该内容

32 篇文章 0 订阅

订阅专栏

深入解析秒杀业务中的核心问题 —— 从并发控制到事务管理

秒杀系统是应对高并发、高压力下的典型业务场景，涉及到并发控制、库存管理、事务管理等多个关键技术点。本文将深入剖析秒杀商品业务中常见的几个核心问题，包括 AOP 事务管理、同步锁机制、乐观锁、CAS 操作，以及用户限购策略。通过这些技术的结合，确保秒杀系统在高并发场景下的稳定性和一致性。

1. AOP 代理对象与事务管理

在秒杀商品的业务中，事务管理是至关重要的环节，尤其是涉及到库存扣减和订单创建的场景。Spring 提供了 @Transactional 注解，通过 AOP（面向切面编程）实现事务管理。为了保证事务的正常执行，方法调用必须通过 Spring 的代理对象来进行。

为什么需要代理对象？

Spring 的事务管理是通过 AOP 实现的，AOP 的本质是通过代理对象拦截方法调用，并在方法调用前后进行事务的开启、提交、回滚等操作。如果在同一个类中直接调用 this 方法，则不会经过代理，事务拦截器无法生效，导致事务管理失效。

解决方案：

为了确保在类内部调用方法时依然通过代理对象，我们可以通过以下技术：

AopContext.currentProxy()：Spring 提供的 AopContext.currentProxy() 方法可以获取当前类的代理对象，确保事务正常生效。
@EnableAspectJAutoProxy(exposeProxy = true)：该注解的作用是暴露当前的代理对象，配合 AopContext.currentProxy() 来获取代理对象。

代码示例：

synchronized (uid.toString().intern()) {
    // 获取当前代理对象，确保事务生效
    IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
    return proxy.createOrder(productId, uid);
}

在这个场景中，我们确保通过代理对象调用 createOrder 方法，以保证事务的正确性。

2. 并发控制与锁机制

在秒杀商品业务中，确保单个用户不能在同一时刻多次请求是很重要的。为了实现这一点，我们可以使用 synchronized 锁机制，通过用户 ID 进行加锁，确保一个用户不能同时发起多次秒杀请求。

synchronized (uid.toString().intern()) 机制：

uid.toString().intern() 方法保证相同的用户 ID 会共享同一个锁对象，intern() 会将字符串放入常量池，从而确保不同用户获得不同的锁对象，而相同用户始终使用相同的锁。
synchronized 锁粒度基于用户，防止同一用户并发访问，确保线程安全。

注意：这种锁机制是 JVM 层面的锁，适用于单机环境。如果是分布式部署，还需要使用 Redis 分布式锁 等手段来确保分布式环境下的并发控制。

代码示例：

Long uid = UserHolder.getUser().getId();
synchronized (uid.toString().intern()) {
    // 秒杀业务逻辑
}

在分布式环境下，可以用 Redis 锁来代替 JVM 锁，确保分布式集群环境中的并发安全。

3. 锁包含事务，还是事务包含锁？

在秒杀业务中，锁和事务的执行顺序非常关键。通常情况下，我们希望在进入临界区（即加锁后）开启事务，确保多个操作的原子性。这意味着锁的作用是为了保证并发控制，而事务的作用是确保数据操作的原子性和一致性。

因此，锁先于事务启动，事务的所有操作都在加锁保护的代码块内执行。这样可以确保在并发情况下，事务中的操作不会出现线程安全问题。

代码示例：

synchronized (uid.toString().intern()) {
    // 在锁内，调用带有事务的方法
    IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
    return proxy.createOrder(productId, uid);
}

在这个流程中，锁保护了事务，确保同一时间只有一个用户可以创建订单，并且事务操作得到正确的执行。

4. 乐观锁、悲观锁、版本号、CAS

在秒杀场景中，库存扣减的正确性是关键问题之一。常见的解决方案包括乐观锁、悲观锁、CAS（Compare And Swap），它们各有优缺点。

乐观锁：基于一种“乐观”的思想，假设不会发生冲突，因此不加锁。它通过 版本号 或其他条件进行判断。在库存扣减时，通过检查 stock > 0 或版本号的方式保证库存扣减的正确性。

宽松的乐观锁：
```
UPDATE product_stock
SET stock = stock - 1
WHERE product_id = #{productId} AND stock > 0;
```
严格的乐观锁：
```
UPDATE product_stock
SET stock = stock - 1
WHERE product_id = #{productId} AND stock = #{currentStock};
```
宽松的乐观锁只要库存大于 0 就能扣减，而严格的乐观锁要求库存值完全匹配，避免高并发下的超卖情况。
CAS（Compare And Swap）：CAS 是一种无锁的操作，通过比较内存中的值是否是预期的值，如果是就更新，否则重试。它在并发高的场景中非常有效，避免了加锁带来的性能开销。

5. 限购策略：一人一单

在秒杀商品业务中，通常会限制每个用户只能购买一件商品。这可以通过在订单表中查询用户是否已经下单来实现。

解决方案：

在秒杀开始前，查询当前用户是否已经下过订单。如果下单了，直接返回失败信息，防止重复下单。

SQL 示例：

SELECT COUNT(1) 
FROM orders 
WHERE user_id = #{uid} 
AND product_id = #{productId};

-- 如果用户没有下过单，则创建订单
INSERT INTO orders (order_id, user_id, product_id, quantity)
VALUES (#{orderId}, #{uid}, #{productId}, 1);