Seckill System：1-秒杀项目1.1-读写分离

一、最初的构想：引入读写锁

在秒杀开始前，有成千上万的用户疯狂刷新商品详情页，他们只是想看看库存还剩下多少，即进行读操作。在当前的实现下，大量的读请求也必须排队等待获取ReentrantLock，严重影响了用户体验。这是一个典型的“读多写少”的场景，所以引入读写锁。

改写代码

重构SeckillService，将业务逻辑拆分出两个核心方法：

checkStock(): 专门用于查询库存，使用读锁。

/*
  * 新增方法，用于查询商品库存，专门用于处理读请求
  * 使用读写锁中的读锁，允许并发读取，互不堵塞
*/
public Integer checkStock(Long productId) {
  log.info("线程 {} 尝试获取读锁...", Thread.currentThread().getName());
  readLock.lock(); // 读操作上读锁
  log.info("线程 {} 成功获取到读锁", Thread.currentThread().getName());
  try {
      Optional<Product> productOpt = productRepository.findById(productId);
      if (!productOpt.isPresent()) {
          throw new RuntimeException("商品不存在");
      }
      log.info("线程 {} 读取库存为: {}", Thread.currentThread().getName(), productOpt.get().getStock());
      return productOpt.get().getStock();
  } finally {
      log.info("线程 {} 准备释放读锁.", Thread.currentThread().getName());
      readLock.unlock();
  }
}

processSeckill(): 负责执行秒杀下单，使用写锁

public String processSeckill(Long productId, Long userId) {
    log.info("线程 {} 尝试获取写锁...", Thread.currentThread().getName());
    writeLock.lock(); // 2. 秒杀操作上写锁，确保互斥
    log.info("线程 {} 成功获取到写锁", Thread.currentThread().getName());
    // 3. 定义事务
    DefaultTransactionDefinition def = new DefaultTransactionDefinition();
    def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
    // 4. 开启事务
    TransactionStatus status = transactionManager.getTransaction(def);

    try {
        // ...所有业务逻辑，和之前一样
        // 5. 【关键】在锁释放前，手动提交事务
        transactionManager.commit(status);
        log.info("线程 {} 秒杀成功，提交事务。", Thread.currentThread().getName());

        return "秒杀成功！订单创建中...";
    } catch (Exception e) {
        // 6. 如果发生任何异常，手动回滚事务
        transactionManager.rollback(status);
        log.error("线程 {} 秒杀失败: {}", Thread.currentThread().getName(), e.getMessage());
        // 将异常信息返回或记录日志
        return e.getMessage();
    } finally {
        // 7. 最后，释放锁
        log.info("线程 {} 准备释放写锁.", Thread.currentThread().getName());
        writeLock.unlock();
    }
}

同时，我也在 Controller 层为查询库存新增了一个 GET 方式的 API 接口。

JMeter设置

线程组一：读请求
- 线程数： 500。
- Ramp-up: 1
- 循环次数: 10
- 在该线程组下，创建一个 HTTP 请求，指向读接口：GET /seckill/stock/1
线程组二：写请求
- 线程数： 200
- Ramp-up: 1
- 循环次数: 1
- 在该线程组下，创建之前配置好的、带计数器的 HTTP 请求，指向写接口：POST /seckill/1?userId=${uniqueUserId}
  同时启动压测：在 JMeter 中，同时运行多个线程组。

压测结果与分析

结果：读请求均为库存为0;写请求正常，数据库显示，库存数为0，订单数新建100。
读请求
分析：瞬时的大量写请求，在一个极端的时间窗口内将库存扣减完毕。读请求因为写锁被阻塞，等到它们能够被执行时，秒杀已经结束。

二、改进：并发测试场景设计

调整JMeter设置

由于200个/500个线程数太多，在日志中无法回看到最初的日志信息，所以修改线程数，便于观察。
“写请求”线程组：

线程数: 20
Ramp-up Period: 从 1 改成 20。
- 作用： 这意味着 JMeter 会在20秒内“缓慢地”启动这200个线程，大约每1秒启动一个。这给了读请求在两个写请求之间“插进来”的机会。
循环次数 (Loop Count): 1

“读请求”线程组：

线程数: 50
Ramp-up Period: 也改成 20。
循环次数: 保持在 10 。

【关键】为两个线程组设置“调度器”：

在两个线程组的配置界面下方，找到并勾选 “调度器”。
在“持续时间”中，输入 30。
- 作用： 这会强制两个线程组都在运行30秒后自动停止。这能确保读写请求在同一个时间窗口内并发执行。

压测结果与分析

结果：读请求在日志中能够显示出库存数逐渐减少，写请求正常，且日志有如下模式，体现了读写锁“读共享、写独占”的理论：
一次写 -> 一大批读（读到的值都一样） -> 又一次写 -> 又一大批读（读到的新值都一样）…
日志信息

学学八股

ReentrantReadWriteLock

是一个读写锁的实现，在内部维护了一对关联的锁：一个共享的读锁和一个独占的写锁。在”读多写少“的场景下，如果使用ReentrantLock这种普通互斥锁，会因为大量的饿读操作也必须串行执行而导致性能低下。读写锁则允许多个读线程并发访问，极大提升了这类场景下的系统吞吐量。
- 读锁：如果当前没有任何线程持有写锁，那么任意数量的线程都可以成功获取并持有读锁。即读-读共享。
- 写锁：只有在没有任何线程持有读锁或写锁的情况下，一个线程才有可能成功获取写锁。即写-写互斥，写-读互斥。
可能的问题
- “写饥饿”问题： 在非公平、高并发读的场景下，如果读请求源源不断，写线程可能很难有机会获取到写锁，因为它总能看到有线程持有读锁。这就是所谓的“写饥饿”。使用公平锁是缓解这个问题的一种方式。
- 性能并非总是更优： ReentrantReadWriteLock 的内部机制比 ReentrantLock 复杂得多，因此在读写竞争不明显或者并发度不高的情况下，它的开销可能会比简单的互斥锁更大。不要盲目使用，只有在明确的“读多写少”且存在性能瓶颈的场景下，它才是最佳选择。