第三部分：核心业务实现：秒杀逻辑详解
3.1 三种秒杀方案对比
秒杀的核心是库存扣减。我们设计了三种方案，分别适用于不同并发量的场景。
方案一：数据库乐观锁（适合中等并发，约500-2000 QPS）
乐观锁的核心思想：不锁定资源，而是在更新时检查数据是否被修改过。
-- 乐观锁扣减库存的SQL
UPDATE seckill_goods
SET stock_count = stock_count - 1, version = version + 1
WHERE id = #{goodsId} AND stock_count > 0 AND version = #{oldVersion}
工作原理：
查询商品信息，获取当前version
扣减库存时，在WHERE条件中加入version = oldVersion
如果更新行数为0，说明版本已变化（有其他线程修改了库存），需要重试
优点：
不需要数据库锁，性能较高
实现简单
缺点：
高并发下重试次数多，CPU消耗大
不适合极高并发场景
方案二：Redis预减库存 + 异步下单（适合高并发，5000-20000 QPS）
Redis是内存数据库，单机QPS可达10万+。我们将库存存储在Redis中，秒杀请求先操作Redis，成功后再异步处理订单。
工作流程：
秒杀开始前，将库存预热到Redis
秒杀请求到达时，使用Redis的DECR命令原子扣减库存
扣减成功后，将用户ID存入Redis Set（用于防重复）
发送MQ消息，异步创建订单
优点：
性能极高，Redis单机可支撑10万QPS
通过异步处理削峰填谷
缺点：
实现复杂，需要处理缓存与数据库的一致性
Redis故障会影响秒杀
方案三：分布式锁 + Lua脚本（最安全，适合对一致性要求极高的场景）
使用Redisson分布式锁保证同一时间只有一个线程操作库存，使用Lua脚本保证操作的原子性。
优点：
数据一致性最强
避免超卖
缺点：
性能相对较低
需要维护分布式锁
3.2 统一响应结果：让前后端沟通更顺畅
在前后端分离的开发模式中，统一的响应格式至关重要。它让前端能统一处理成功和失败的情况。
public class Result<T> {
private Integer code; // 状态码：200成功，其他失败
private String message; // 提示信息
private T data; // 响应数据
private Long timestamp; // 时间戳
// 成功响应（无数据）
public static <T> Result<T> success() {
return new Result<>(200, "success", null);
}
// 成功响应（带数据）
public static <T> Result<T> success(T data) {
return new Result<>(200, "success", data);
}
// 失败响应
public static <T> Result<T> error(String message) {
return new Result<>(500, message, null);
}
}
为什么需要timestamp？
帮助前端判断响应是否过期
便于问题排查时定位时间点
防止重放攻击（可以检查时间戳是否在合理范围内）
3.3 全局异常处理：别让异常信息暴露给用户
在Web应用中，异常处理非常重要。如果让系统异常直接暴露给用户，不仅体验差，还可能泄露敏感信息。
@RestControllerAdvice
public class GlobalExceptionHandler {
// 处理业务异常
@ExceptionHandler(BusinessException.class)
public Result<Void> handleBusinessException(BusinessException e) {
// 记录警告日志（不是错误，是预期内的业务失败）
log.warn("业务异常: code={}, message={}", e.getCode(), e.getMessage());
return Result.error(e.getCode(), e.getMessage());
}
// 处理参数校验异常
@ExceptionHandler(MethodArgumentNotValidException.class)
public Result<Void> handleValidationException(MethodArgumentNotValidException e) {
// 提取所有校验失败的信息
String message = e.getBindingResult().getFieldErrors().stream()
.map(FieldError::getDefaultMessage)
.collect(Collectors.joining(", "));
return Result.error(400, message);
}
// 处理系统异常（兜底）
@ExceptionHandler(Exception.class)
public Result<Void> handleException(Exception e) {
// 记录完整错误堆栈，便于排查
log.error("系统异常: {}", e.getMessage(), e);
// 返回通用错误信息，不暴露内部细节
return Result.error(500, "系统繁忙，请稍后再试");
}
}
为什么需要全局异常处理？
统一格式：所有错误响应格式一致，前端易于处理
信息过滤：防止敏感信息（如SQL语句、文件路径）泄露
日志记录：集中记录异常，便于监控和排查
代码简化：业务代码中只需抛出异常，不需要到处try-catch
3.4 秒杀核心服务详解
秒杀服务是整个系统的核心，我们重点分析三种方案的实现。
方案一实现：数据库乐观锁
@Transactional
public SeckillOrder seckillWithOptimisticLock(Long userId, Long goodsId) {
// 1. 校验商品状态（是否存在、是否在秒杀时间内）
SeckillGoods goods = validateSeckillGoods(goodsId);
// 2. 检查用户是否已秒杀（防止重复）
checkUserSeckillRecord(userId, goodsId);
// 3. 乐观锁扣减库存
// 关键点：WHERE条件中加入了stock_count > 0和version
int updateCount = seckillGoodsMapper.decreaseStockWithVersion(goodsId, 1);
if (updateCount == 0) {
// 更新失败说明库存不足或版本冲突
throw BusinessException.STOCK_NOT_ENOUGH;
}
// 4. 创建订单
SeckillOrder order = createOrder(userId, goods);
// 5. 记录秒杀记录
saveSeckillRecord(userId, goodsId, order.getId(), 1);
return order;
}
关键点解释：
@Transactional：保证库存扣减和订单创建在同一个事务中，要么都成功，要么都失败
decreaseStockWithVersion：使用乐观锁，避免行锁导致的性能问题
updateCount == 0：表示库存不足或版本冲突，需要告诉用户秒杀失败
方案二实现：Redis预减库存
public void seckillWithRedis(Long userId, Long goodsId) {
// 1. Redis原子扣减库存
String stockKey = "seckill:stock:" + goodsId;
Long stock = redisTemplate.opsForValue().decrement(stockKey);
// 如果库存小于0，说明已经卖完了
if (stock == null || stock < 0) {
// 恢复库存（decr后为负数，需要加回来）
if (stock != null && stock < 0) {
redisTemplate.opsForValue().increment(stockKey);
}
throw BusinessException.STOCK_NOT_ENOUGH;
}
// 2. 防止重复秒杀（使用Redis Set）
String userKey = "seckill:user:" + goodsId;
Boolean isSuccess = redisTemplate.opsForSet().add(userKey, userId.toString());
if (Boolean.FALSE.equals(isSuccess)) {
// 用户已参与，恢复库存
redisTemplate.opsForValue().increment(stockKey);
throw BusinessException.REPEAT_SECKILL;
}
// 3. 发送MQ消息，异步创建订单
seckillMessageSender.sendMessage(userId, goodsId);
}
为什么使用Redis DECR？
DECR是原子操作，不用担心并发问题
Redis单线程模型，天然保证原子性
性能极高，单机可达10万+ QPS
为什么需要恢复库存？
DECR操作后如果库存变为负数，说明超卖了
需要将库存加回，保证数据正确性
3.5 消息队列异步处理：削峰填谷
秒杀场景下，如果所有订单创建都同步进行，数据库会承受巨大压力。使用消息队列可以将请求“削峰填谷”。
@Component
public class SeckillMessageConsumer {
@RabbitListener(queues = "seckill.queue")
public void handleMessage(SeckillDTO dto) {
// 1. 再次校验库存（数据库层）
SeckillGoods goods = seckillGoodsMapper.selectById(dto.getGoodsId());
if (goods.getStockCount() <= 0) {
log.warn("库存不足，放弃处理");
return;
}
// 2. 乐观锁扣减数据库库存
int updateCount = seckillGoodsMapper.decreaseStockWithVersion(
dto.getGoodsId(), 1);
if (updateCount == 0) {
log.warn("扣减库存失败，放弃处理");
return;
}
// 3. 创建订单
SeckillOrder order = new SeckillOrder();
order.setOrderNo(generateOrderNo());
order.setUserId(dto.getUserId());
order.setGoodsId(goods.getId());
order.setGoodsName(goods.getGoodsName());
order.setGoodsPrice(goods.getSeckillPrice());
seckillOrderMapper.insert(order);
log.info("订单创建成功: {}", order.getOrderNo());
}
}
为什么需要异步处理？
秒杀请求只需要快速响应“已收到请求”，用户可以稍后查看结果
订单创建涉及数据库写入，耗时较长，不适合同步处理
消息队列可以缓冲请求，避免数据库被打垮
为什么不直接信任Redis库存？
Redis可能宕机或数据丢失
最终一致性：Redis库存只是“预扣减”，真正的扣减必须在数据库完成
数据库是最终权威数据源
来源：
http://oplhc.cn/category/software-apps.html
