分布式秒杀系统四

最新推荐文章于 2026-01-26 00:13:24 发布

原创最新推荐文章于 2026-01-26 00:13:24 发布 · 281 阅读

本内容遵循CC 4.0 BY-SA版权协议

本文探讨了分布式秒杀系统中确保请求下单数据一致性的问题，包括库存同步、事务处理、数据库锁与分布式锁的使用。介绍了Redis Lua脚本在保证无锁化操作的同时避免超卖，以及在Redis崩溃前同步数据库的策略。同时，提到了MQ可能导致的重复发送问题及幂等接口的重要性。

分布式秒杀系统四

文章目录

- 分布式秒杀系统四

请求下单数据一致性的问题（性能？安全/？）

商品服务中商品减少的数量一定要等于订单服务中订单增加的数量。
库存不能为负数即不能超卖

单机测试的结果：库存10000件，请求方式1秒1w5个请求

直接下单的普通业务：发生了超卖，前后差距8秒
添加synchronized关键字：没有发生超卖，前后耗时15秒

问题一：只是本地加锁，分布式环境下不可用，实际开发应该采用分布式锁（redis/zookeeper）

问题二：需要注意和事务注解（@Transactional）配合使用的问题

⭐不加注解为线程安全，加了注解则不为线程安全

因为@Transactional这个事务管理注解是基于AOP技术实现的，即标识当前方法要用AOP进行代理，代理对象会在调用该方法之前先开启事务，然后加锁执行方法，然后解锁，最后提交/回滚事务。当某个线程执行方法后解了锁却还没提交事务就被打断，则会发生线程安全问题。根据事务的隔离性，当前事务是不能读到其他事务未提交的动作，方法中若将库存减去，其他事务不能看见，所以会导致超卖的情况。

解决：先加锁在进行事务管理，对整个controller进行加锁，但是性能会很差。
分布式锁：没有发生超卖，前后耗时1分47秒，因为并发比较高的情况下，大量的请求失败了。
数据库锁（用到排他锁）：没有发生超卖，前后耗时11秒，并发比较高，大量的请求失败
- 表锁（悲观锁）：事务会直接锁表，其他事务不能再对该表进行任何操作
- 行锁（悲观锁）：事务会锁行，其他事务不能再操作该行，但是可以操作其他行
  - 共享锁（读锁）：一个事务如果对某一行记录添加了读锁，则其他事务也只能对该行加读锁，不能添加排他锁。
  - 排他锁（写锁）：一个事务如果对某一行记录添加了写锁，则其他事务不能对该行加读锁和写锁。
insert，update，delete语句自带排他锁（锁行），select语句没有任何锁。

如果要给select语句添加共享锁，需要在后面设置lock in share mode

如果要给select语句添加排他锁，需要在后面设置for update

注意：
1. 如果select，insert，update ，delete 的where条件中，没有携带主键或者一个唯一性索引的字段，那么就会自动升级成为表锁。
2. 如果sql语句中，where条件的id是一个范围，则会锁住范围内的所有行，哪怕这行记录不存在，这种情况称之为间隙锁。
⭐数据库的乐观锁：直接修改时判断库存（无锁），没有发生超卖，前后的耗时6秒，但实际开发中还存在一些问题。
⭐redis的lua脚本：无锁化的操作，没有发生超卖，前后耗时4秒

用lua脚本去扣减redis，数据库不动，生成的订单也放在redis中，当redis中的库存为0时通过异步的方式线程读取redis中数据到数据库。

如果在同步数据库之前redis崩了怎么办

当请求来了之后，先看redis中库存够不够，如果够先扣减库存，然后返回信息告诉说够，如果秒杀服务接收到该消息，则会将当前秒杀的信息放入MQ消息队列中，然后订单服务和商品服务都来消费MQ中的信息。当秒杀服务将消息放入MQ中之后，就告诉前端抢购完成，这个过程相当于一个异步的操作。

MQ的作用：

分布式事务的保证 - 追求最终一致性：保证MQ中的消息（即秒杀服务放进MQ的消息）消费端一定能够收到，基于消息确认机制 + 重试机制 + 补偿机制，不用担心redis崩溃掉。
请求削峰：假设有许多请求发给上游服务（即秒杀服务）则问题不大，因为业务逻辑不是很复杂，但是当这些请求分发给下游（即订单服务和商品服务）则压力会更大，甚至可能会导致崩溃。也可以理解为一种限流，消费端可以限制消费的数量，什么时候消费完才从MQ中拿取信息。会拉长处理时间，以时间换性能。

秒杀下单的lua脚本

--获取下单的商品id
local gid = KEYS[1]
--获取下单数量
local gnumber = tonumber(ARGV[1])

--进行库存的判定
--获取当前商品的库存
local gsave = tonumber(redis.call('get','goods'..gid) or 0)

--判断库存
if gsave < gnumber then
   --库存不足
   return -1;
end

--库存充足，进行库存扣减
local result = redis.call('decrby','goods'..gid,gnumber)

--返回结果，抢购成功
if result > 0 then
   --抢购成功，但是还有库存可以继续
   return 1
   else
   --抢购成功，并且已经没有库存
   return 0
end