1.引言
高并发场景在现场的日常工作中很常见，特别是在互联网公司中，这篇文章就来通过秒杀商品来模拟高并发的场景。文章末尾会附上文章的所有代码、脚本和测试用例。
本文环境： SpringBoot + MySQL + MybatisPlus + Swagger
模拟工具： Jmeter
模拟场景： 减库存->创建订单->模拟支付
2.出现商品超卖
在开发中，对于下面的代码，可能很熟悉：在Service里面加上@Transactional事务注解和Lock锁
数据库
CREATE TABLE `test_commodity` (
`id` bigint(20) NOT NULL COMMENT '主键id',
`name` varchar(255) NOT NULL COMMENT '商品名称',
`stock_number` int(10) NOT NULL COMMENT '库存数量',
`version` int(10) NOT NULL COMMENT '版本',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表';
CREATE TABLE `test_order` (
`id` bigint(11) NOT NULL AUTO_INCREMENT COMMENT 'id',
`order_code` varchar(255) NOT NULL COMMENT '订单编号',
`order_time` datetime NOT NULL COMMENT '创建时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=101 DEFAULT CHARSET=utf8mb4 COMMENT='订单表';
CREATE TABLE `test_pay` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id',
`order_code` varchar(255) NOT NULL COMMENT '订单编号',
`pay_user` varchar(255) NOT NULL COMMENT '购买人',
`pay_time` datetime DEFAULT NULL COMMENT '购买时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=101 DEFAULT CHARSET=utf8mb4 COMMENT='支付表';
控制层：Controller
@Tag(name = "实现高并发秒杀的七种方式")
@RestController
@Slf4j
@RequestMapping("test/seckill")
public class Dome {
@Autowired
private TestCommodityService testCommodityService;
@Operation(summary = "秒杀实现方式——Lock加锁")
@GetMapping("/start/lock")
public AjaxResult<?> startLock() {
try {
log.info("开始秒杀方式一...");
AjaxResult<?> result = testCommodityService.startSecondKillByLock(1);
if (result != null) {
log.info("{}", result.getMessage());
} else {
log.info("{}", "爆满了，请稍后！");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
}
return AjaxResult.success();
}
}
业务层：Service
/**
* 可重入锁
*/
private static final Lock lock = new ReentrantLock();
/**
* 秒杀实现方式——Lock加锁
*
* @param skgId 商品id
* @return ok
*/
@Transactional(rollbackFor = Exception.class)
@Override
public AjaxResult<?> startSecondKillByLock(long skgId) {
lock.lock();
try {
// 校验库存
TestCommodity testCommodity = testCommodityMapper.selectById(skgId);
Integer number = testCommodity.getStockNumber();
if (number > 0) {
// 扣库存
testCommodity.setStockNumber(number - 1);
testCommodityMapper.updateById(testCommodity);
// 创建订单
String code = UUID.fastUUID().toString();
TestOrder testOrder = new TestOrder();
testOrder.setOrderCode(code);
testOrder.setOrderTime(new Date());
testOrderMapper.insert(testOrder);
// 创建支付
TestPay testPay = new TestPay();
testPay.setOrderCode(code);
testPay.setPayUser(UUID.fastUUID().toString());
testPay.setPayTime(new Date());
} else {
return AjaxResult.error("卖完了");
}
} catch (Exception e) {
return AjaxResult.error("异常了！！！");
} finally {
lock.unlock();
}
return AjaxResult.success();
}
对于上面的代码应该没啥问题吧，业务方法上加事务，在处理业务的时候加锁。
但上面这样写法是有问题的，会出现超卖的情况，看下测试结果：模拟1000个并发，抢100商品，使用Jmeter模拟并发
发生了超卖！
这里在业务方法开始加了锁，在业务方法结束后释放了锁。但这里的事务提交却不是这样的，有可能在事务提交之前，就已经把锁释放了，这样会导致商品超卖现象。所以加锁的时机很重要！
3. 解决商品超卖
对于上面超卖现象，主要问题出现在事务中锁释放的时机，事务未提交之前，锁已经释放。（事务提交是在整个方法执行完）。如何解决这个问题呢，就是把加锁步骤提前
可以在controller层进行加锁
可以使用Aop在业务方法执行之前进行加锁
3.1 方式一（改进版加锁）
控制层：Controller
@Operation(summary = "方式一（改进版加锁）")
@GetMapping("/start/lock1")
public AjaxResult<?> startLock1() {
// 在此处加锁
lock.lock();
try {
log.info("开始秒杀方式一...");
AjaxResult<?> result = testCommodityService.startSecondKillByLock1(1);
if (result != null) {
log.info("{}", result.getMessage());
} else {
log.info("{}", "爆满了，请稍后！");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
// 在此处释放锁
lock.unlock();
}
return AjaxResult.success();
}
业务层：Service
/**
* 方式一（改进版加锁）
*
* @param skgId 商品id
* @return ok
*/
@Transactional(rollbackFor = Exception.class)
@Override
public AjaxResult<?> startSecondKillByLock1(long skgId) {
try {
// 校验库存
TestCommodity testCommodity = testCommodityMapper.selectById(skgId);
Integer number = testCommodity.getStockNumber();
if (number > 0) {
// 扣库存
testCommodity.setStockNumber(number - 1);
testCommodityMapper.updateById(testCommodity);
// 创建订单
String code = UUID.fastUUID().toString();
TestOrder testOrder = new TestOrder();
testOrder.setOrderCode(code);
testOrder.setOrderTime(new Date());
testOrderMapper.insert(testOrder);
// 创建支付
TestPay testPay = new TestPay();
testPay.setOrderCode(code);
testPay.setPayUser(UUID.fastUUID().toString());
testPay.setPayTime(new Date());
testPayMapper.insert(testPay);
} else {
return AjaxResult.error("卖完了");
}
} catch (Exception e) {
return AjaxResult.error("异常了！！！");
} finally {
}
return AjaxResult.success();
}
上面这样的加锁就可以解决事务未提交之前，锁释放的问题，对于并发量大于商品数的情况，商品秒杀一般不会出现少卖的请况。测试下来完全OK。
3.2 方式二（AOP版加锁）
对于上面在控制层进行加锁的方式，可能显得不优雅，那就还有另一种方式进行在事务之前加锁，那就是AOP
自定义AOP注解
@Target({ElementType.PARAMETER, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ServiceLock {
String description() default "";
}
定义切面类
@Slf4j
@Component
@Scope
@Aspect
@Order(1) //order越小越是最先执行，但更重要的是最先执行的最后结束
public class LockAspect {
/**
* 思考：为什么不用synchronized
* service 默认是单例的，并发下lock只有一个实例
*/
private static Lock lock = new ReentrantLock(true); // 互斥锁 参数默认false，不公平锁
// Service层切点 用于记录错误日志
@Pointcut("@annotation(com.cn.annotation.ServiceLock)")
public void lockAspect() {
}
@Around("lockAspect()")
public Object around(ProceedingJoinPoint joinPoint) {
lock.lock();
Object obj = null;
try {
obj = joinPoint.proceed();
} catch (Throwable e) {
e.printStackTrace();
throw new RuntimeException();
} finally{
lock.unlock();
}
return obj;
}
}
控制层：Controller
@Operation(summary = "方式二（AOP版加锁）")
@GetMapping("/start/lock2")
public AjaxResult<?> startLock2() {
try {
log.info("开始秒杀方式二...");
AjaxResult<?> result = testCommodityService.startSecondKillByLock2(1);
if (result != null) {
log.info("{}", result.getMessage());
} else {
log.info("{}", "爆满了，请稍后！");
}
} catch (Exception e) {
e.printStackTrace();
}
return AjaxResult.success();
}
业务层：Service
/**
* 方式二（AOP版加锁）
*
* @param skgId 商品id
* @return ok
*/
@ServiceLock // 使用Aop进行加锁
@Transactional(rollbackFor = Exception.class)
@Override
public AjaxResult<?> startSecondKillByLock2(long skgId) {
try {
// 校验库存
TestCommodity testCommodity = testCommodityMapper.selectById(skgId);
Integer number = testCommodity.getStockNumber();
if (number > 0) {
// 扣库存
testCommodity.setStockNumber(number - 1);
testCommodityMapper.updateById(testCommodity);
// 创建订单
String code = UUID.fastUUID().toString();
TestOrder testOrder = new TestOrder();
testOrder.setOrderCode(code);
testOrder.setOrderTime(new Date());
testOrderMapper.insert(testOrder);
// 创建支付
TestPay testPay = new TestPay();
testPay.setOrderCode(code);
testPay.setPayUser(UUID.fastUUID().toString());
testPay.setPayTime(new Date());
testPayMapper.insert(testPay);
} else {
return AjaxResult.error("卖完了");
}
} catch (Exception e) {
return AjaxResult.error("异常了！！！");
}
return AjaxResult.success();
}
这种方式在对锁的使用上，更高阶、更美观！
3.3 方式三（悲观锁一）
除了上面在业务代码层面加锁外，还可以使用数据库自带的锁进行并发控制。
悲观锁，什么是悲观锁呢？通俗的说，在做任何事情之前，都要进行加锁确认。这种数据库级加锁操作效率较低。
使用for update一定要加上事务，当事务处理完后，for update才会将行级锁解除
如果请求数和秒杀商品数量一致，会出现少卖。
控制层：Controller
@Operation(summary = "方式三（悲观锁一）")
@GetMapping("/start/lock3")
public AjaxResult<?> startLock3() {
try {
log.info("开始秒杀方式三...");
AjaxResult<?> result = testCommodityService.startSecondKillByLock3(1);
if (result != null) {
log.info("{}", result.getMessage());
} else {
log.info("{}", "爆满了，请稍后！");
}
} catch (Exception e) {
e.printStackTrace();
}
return AjaxResult.success();
}
业务层：Service
/**
* 方式三（悲观锁一）
*
* @param skgId 商品id
* @return ok
*/
@Transactional(rollbackFor = Exception.class)
@Override
public AjaxResult<?> startSecondKillByLock3(long skgId) {
try {
// 校验库存-悲观锁
TestCommodity testCommodity = testCommodityMapper.selectById2(skgId);
Integer number = testCommodity.getStockNumber();
if (number > 0) {
// 扣库存
testCommodity.setStockNumber(number - 1);
testCommodityMapper.updateById(testCommodity);
// 创建订单
String code = UUID.fastUUID().toString();
TestOrder testOrder = new TestOrder();
testOrder.setOrderCode(code);
testOrder.setOrderTime(new Date());
testOrderMapper.insert(testOrder);
// 创建支付
TestPay testPay = new TestPay();
testPay.setOrderCode(code);
testPay.setPayUser(UUID.fastUUID().toString());
testPay.setPayTime(new Date());
testPayMapper.insert(testPay);
} else {
return AjaxResult.error("卖完了");
}
} catch (Exception e) {
return AjaxResult.error("异常了！！！");
}
return AjaxResult.success();
}
Mapper层：mapper
/**
* 将此行数据进行加锁，当整个方法将事务提交后，才会解锁
* @param skgId
* @return
*/
TestCommodity selectById2(long skgId);
Dao层：xml
<select id="selectById2" resultType="com.cn.domain.TestCommodity">
SELECT * FROM test_commodity WHERE id = #{skgId} FOR UPDATE
</select>
3.4 方式四（悲观锁二）
悲观锁的第二种方式就是利用update更新命令来加表锁
控制层：Controller
@Operation(summary = "方式四（悲观锁二）")
@GetMapping("/start/lock4")
public AjaxResult<?> startLock4() {
try {
log.info("开始秒杀方式四...");
AjaxResult<?> result = testCommodityService.startSecondKillByLock4(1);
if (result != null) {
log.info("{}", result.getMessage());
} else {
log.info("{}", "爆满了，请稍后！");
}
} catch (Exception e) {
e.printStackTrace();
}
return AjaxResult.success();
}
业务层：Service
/**
* 方式四（悲观锁二）
*
* @param skgId 商品id
* @return ok
*/
@Transactional(rollbackFor = Exception.class)
@Override
public AjaxResult<?> startSecondKillByLock4(long skgId) {
try {
// 不校验，直接扣库存更新
int result = testCommodityMapper.updateSecondKillById(skgId);
if (result > 0) {
// 创建订单
String code = UUID.fastUUID().toString();
TestOrder testOrder = new TestOrder();
testOrder.setOrderCode(code);
testOrder.setOrderTime(new Date());
testOrderMapper.insert(testOrder);
// 创建支付
TestPay testPay = new TestPay();
testPay.setOrderCode(code);
testPay.setPayUser(UUID.fastUUID().toString());
testPay.setPayTime(new Date());
testPayMapper.insert(testPay);
} else {
return AjaxResult.error("卖完了");
}
} catch (Exception e) {
return AjaxResult.error("异常了！！！");
}
return AjaxResult.success();
}
Mapper层：mapper
/**
* 直接更新扣减数据库
* @param skgId
* @return
*/
int updateSecondKillById(long skgId);
Dao层：xml
<update id="updateSecondKillById">
UPDATE test_commodity SET stock_number = stock_number-1 WHERE id = #{skgId} AND stock_number > 0
</update>
3.5 方式五（乐观锁）
乐观锁，顾名思义，就是对操作结果很乐观，通过利用version字段来判断数据是否被修改
乐观锁，不进行库存数量的校验，直接做库存扣减
这里使用的乐观锁会出现大量的数据更新异常（抛异常就会导致购买失败）、如果配置的抢购人数比较少、比如120:100(人数:商品) 会出现少买的情况，不推荐使用乐观锁。
控制层：Controller
@Operation(summary = "方式五（乐观锁）")
@GetMapping("/start/lock5")
public AjaxResult<?> startLock5() {
try {
log.info("开始秒杀方式五...");
// 参数添加了购买数量
AjaxResult<?> result = testCommodityService.startSecondKillByLock5(1,1);
if (result != null) {
log.info("{}", result.getMessage());
} else {
log.info("{}", "爆满了，请稍后！");
}
} catch (Exception e) {
e.printStackTrace();
}
return AjaxResult.success();
}
业务层：Service
/**
* 方式五（乐观锁）
*
* @param skgId 商品id
* @param payNumber 购买数量
* @return ok
*/
@Transactional(rollbackFor = Exception.class)
@Override
public AjaxResult<?> startSecondKillByLock5(long skgId, int payNumber) {
try {
// 乐观锁，不进行库存数量的校验，直接
TestCommodity testCommodity = testCommodityMapper.selectById(skgId);
Integer number = testCommodity.getStockNumber();
Integer version = testCommodity.getVersion();
// 剩余的数量应该要大于等于秒杀的数量
if (number >= 1) {
int result = testCommodityMapper.updateSecondKillByVersion(number, skgId, version);
if (result > 0) {
// 创建订单
String code = UUID.fastUUID().toString();
TestOrder testOrder = new TestOrder();
testOrder.setOrderCode(code);
testOrder.setOrderTime(new Date());
testOrderMapper.insert(testOrder);
// 创建支付
TestPay testPay = new TestPay();
testPay.setOrderCode(code);
testPay.setPayUser(UUID.fastUUID().toString());
testPay.setPayTime(new Date());
testPayMapper.insert(testPay);
}
} else {
return AjaxResult.error("卖完了");
}
} catch (Exception e) {
return AjaxResult.error("异常了！！！");
}
return AjaxResult.success();
}
Mapper层：mapper
/**
* 方式五（乐观锁）
* @param number 购买数量
* @param skgId id
* @param version 版本号
* @return
*/
int updateSecondKillByVersion(Integer number, long skgId, Integer version);
Dao层：xml
<update id="updateSecondKillByVersion">
UPDATE test_commodity SET stock_number = stock_number - #{number} , version = version +1 WHERE id=#{skgId} AND version = #{version}
</update>
乐观锁会出现大量的数据更新异常（抛异常就会导致购买失败），会出现少买的情况，不推荐使用乐观锁
3.6 方式六（阻塞队列）
利用阻塞队类，也可以解决高并发问题。其思想就是把接收到的请求按顺序存放到队列中，消费者线程逐一从队列里取数据进行处理，看下具体代码。
阻塞队列：这里使用静态内部类的方式来实现单例模式，在并发条件下不会出现问题。
package com.cn.controller.test.seckill;
import com.cn.domain.TestOrder;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;
/**
* @date 2023/8/28
* @description // 秒杀队列(固定长度为100)
*/
public class SecondKillQueue {
// 队列大小
static final int QUEUE_MAX_SIZE = 100;
// 用于多线程间下单的队列
static BlockingQueue<TestOrder> blockingQueue = new LinkedBlockingQueue<TestOrder>(QUEUE_MAX_SIZE);
// 使用静态内部类，实现单例模式
private SecondKillQueue(){};
private static class SingletonHolder{
// 静态初始化器，由JVM来保证线程安全
private static SecondKillQueue queue = new SecondKillQueue();
}
/**
* 单例队列
* @return
*/
public static SecondKillQueue getSkillQueue(){
return SingletonHolder.queue;
}
/**
* 生产入队
* @param kill
* @throws InterruptedException
* add(e) 队列未满时，返回true；队列满则抛出IllegalStateException(“Queue full”)异常——AbstractQueue
* put(e) 队列未满时，直接插入没有返回值；队列满时会阻塞等待，一直等到队列未满时再插入。
* offer(e) 队列未满时，返回true；队列满时返回false。非阻塞立即返回。
* offer(e, time, unit) 设定等待的时间，如果在指定时间内还不能往队列中插入数据则返回false，插入成功返回true。
*/
public Boolean produce(TestOrder kill) {
return blockingQueue.offer(kill);
}
/**
* 消费出队
* poll() 获取并移除队首元素，在指定的时间内去轮询队列看有没有首元素有则返回，否者超时后返回null
* take() 与带超时时间的poll类似不同在于take时候如果当前队列空了它会一直等待其他线程调用notEmpty.signal()才会被唤醒
*/
public TestOrder consume() throws InterruptedException {
return blockingQueue.take();
}
/**
* 获取队列大小
* @return
*/
public int size() {
return blockingQueue.size();
}
}
消费秒杀队列：实现ApplicationRunner接口
package com.cn.controller.test.seckill;
import com.cn.common.AjaxResult;
import com.cn.common.HttpStatus;
import com.cn.domain.TestOrder;
import com.cn.service.TestCommodityService;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.stereotype.Component;
/**
* @date 2023/8/28
* @description
*/
// 消费秒杀队列
@Slf4j
@Component
public class TaskRunner implements ApplicationRunner {
@Autowired
private TestCommodityService testCommodityService;
@Override
public void run(ApplicationArguments var){
new Thread(() -> {
log.info("队列启动成功");
while(true){
try {
// 进程内队列
TestOrder testOrder = SecondKillQueue.getSkillQueue().consume();
if(testOrder != null){
// 调用apo加锁impl
AjaxResult<?> result = testCommodityService.startSecondKillByLock2(1);
if(result != null && result.getCode().equals(HttpStatus.SUCCESS)){
log.info("TaskRunner,result:{}",result);
log.info("TaskRunner从消息队列取出订单，编号:{}{}",testOrder.getOrderCode(),"秒杀成功");
}
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
}
控制层：Controller
@Operation(summary = "方式六（消息队列）")
@PostMapping("/start/queue6")
public AjaxResult<?> startQueue6() {
try {
log.info("开始秒杀方式六...");
TestOrder testOrder = new TestOrder();
String code = UUID.fastUUID().toString();
testOrder.setOrderCode(code);
testOrder.setOrderTime(new Date());
Boolean flag = SecondKillQueue.getSkillQueue().produce(testOrder);
// 虽然进入了队列，但是不一定能秒杀成功 进队出队有时间间隙
if (flag) {
log.info("编号:{}{}", testOrder.getOrderCode(), "秒杀成功");
} else {
log.info("编号:{}{}", testOrder.getOrderCode(), "秒杀失败");
}
} catch (Exception e) {
e.printStackTrace();
}
return AjaxResult.success();
}
注意：在业务层和AOP方法中，不能抛出任何异常， throw new RuntimeException()这些抛异常代码要注释掉。因为一旦程序抛出异常就会停止，导致消费秒杀队列进程终止！
使用阻塞队列来实现秒杀，有几点要注意：
消费秒杀队列中调用业务方法加锁与不加锁情况一样，也就是testCommodityService.startSecondKillByLock2()、testCommodityService.startSecondKillByLock()方法结果一样，这也很好理解
当队列长度与商品数量一致时，会出现少卖的现象，可以调大数值
下面是队列长度1000，商品数量1000，并发数2000情况下出现的少卖
3.7.方式七（Disruptor队列）
Disruptor是个高性能队列，研发的初衷是解决内存队列的延迟问题，在性能测试中发现竟然与I/O操作处于同样的数量级，基于Disruptor开发的系统单线程能支撑每秒600万订单。
// 事件生成工厂（用来初始化预分配事件对象）
public class SecondKillEventFactory implements EventFactory<SecondKillEvent> {
@Override
public SecondKillEvent newInstance() {
return new SecondKillEvent();
}
}
// 事件对象（秒杀事件）
public class SecondKillEvent implements Serializable {
private static final long serialVersionUID = 1L;
private long seckillId;
private long userId;
// set/get方法略
}
// 使用translator方式生产者
public class SecondKillEventProducer {
private final static EventTranslatorVararg<SecondKillEvent> translator = (seckillEvent, seq, objs) -> {
seckillEvent.setSeckillId((Long) objs[0]);
seckillEvent.setUserId((Long) objs[1]);
};
private final RingBuffer<SecondKillEvent> ringBuffer;
public SecondKillEventProducer(RingBuffer<SecondKillEvent> ringBuffer){
this.ringBuffer = ringBuffer;
}
public void secondKill(long seckillId, long userId){
this.ringBuffer.publishEvent(translator, seckillId, userId);
}
}
// 消费者(秒杀处理器)
@Slf4j
public class SecondKillEventConsumer implements EventHandler<SecondKillEvent> {
private SecondKillService secondKillService = (SecondKillService) SpringUtil.getBean("secondKillService");
@Override
public void onEvent(SecondKillEvent seckillEvent, long seq, boolean bool) {
Result result = secondKillService.startSecondKillByAop(seckillEvent.getSeckillId(), seckillEvent.getUserId());
if(result.equals(Result.ok(SecondKillStateEnum.SUCCESS))){
log.info("用户:{}{}",seckillEvent.getUserId(),"秒杀成功");
}
}
}
public class DisruptorUtil {
static Disruptor<SecondKillEvent> disruptor;
static{
SecondKillEventFactory factory = new SecondKillEventFactory();
int ringBufferSize = 1024;
ThreadFactory threadFactory = runnable -> new Thread(runnable);
disruptor = new Disruptor<>(factory, ringBufferSize, threadFactory);
disruptor.handleEventsWith(new SecondKillEventConsumer());
disruptor.start();
}
public static void producer(SecondKillEvent kill){
RingBuffer<SecondKillEvent> ringBuffer = disruptor.getRingBuffer();
SecondKillEventProducer producer = new SecondKillEventProducer(ringBuffer);
producer.secondKill(kill.getSeckillId(),kill.getUserId());
}
}
@ApiOperation(value="秒杀实现方式七——Disruptor队列")
@PostMapping("/start/disruptor")
public Result startDisruptor(long skgId){
try {
log.info("开始秒杀方式七...");
final long userId = (int) (new Random().nextDouble() * (99999 - 10000 + 1)) + 10000;
SecondKillEvent kill = new SecondKillEvent();
kill.setSeckillId(skgId);
kill.setUserId(userId);
DisruptorUtil.producer(kill);
} catch (Exception e) {
e.printStackTrace();
}
return Result.ok();
}
经过测试，发现使用Disruptor队列队列，与自定义队列有着同样的问题，也会出现超卖的情况，但效率有所提高。
4. 小结
对于上面七种实现并发的方式，做一下总结：
一、二方式是在代码中利用锁和事务的方式解决了并发问题，主要解决的是锁要加载事务之前
三、四、五方式主要是数据库的锁来解决并发问题，方式三是利用for upate对表加行锁，方式四是利用update来对表加锁，方式五是通过增加version字段来控制数据库的更新操作，方式五的效果最差
六、七方式是通过队列来解决并发问题，这里需要特别注意的是，在代码中不能通过throw抛异常，否则消费线程会终止，而且由于进队和出队存在时间间隙，会导致商品少卖
上面所有的情况都经过代码测试，测试分一下三种情况：
并发数1000，商品数100
并发数1000，商品数1000
并发数2000，商品数1000
参考帖子：实现高并发秒杀的七种方式
52
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
