004 秒杀下单

本文主要是介绍004 秒杀下单，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

超卖问题
- 方案一
- 方案二
- 方案三
- aop锁(单机锁)
- - aop锁(单机锁)
  - - pom.xml
    - LockAspect.java
    - ServiceLock.java
- 分布式锁
- - Mysql分布式锁
  - Redis分布式锁
  - - ServiceRedisLock.java
    - LockRedisAspect.java
- 下单性能优化
- 数据一致性
- 解决一致性问题
- - 异步同步库存

秒杀下单业务步骤:
1.数据校验(身份信息，token，手机号，是否开始，库存是否充足，是否开启秒杀，是否上架)
2.检查库存，锁定库存
3.扣减库存
4.更新库存
5.实现下单

面临的问题:
1.业务问题:如何在高并发模式下，保证库存不会出现超卖
2.性能问题:如何在高并发模式下，保证下单操作性能
3.数据一致性问题:如何在高并发模式下，保证数据一致性

超卖问题

原因:
在高并发模式下，多线程出现了数据脏读，抢占cpu资源情况下，出现了数据脏读，从而操作了多下订单，因此出现超卖

超卖:比如10个商品，商品数量为0的时候，下单了100个订单，多下单90个

如何解决超卖问题:
1.上锁(意味着性能下降，一旦上锁，意味着程序的串行化的执行)
2.原子性操作
3.队列(Queue,Redis,队列)

方案一

给业务进行上锁，让库存扣减变成一个原子的操作，让下单的操作是串行化执行，只有当第一个线程执行结束后，后一个线程才能开始执行，从而控制库存超卖。
注意:在分布式环境下，需要使用分布式锁来控制库存

方案二

利用redis的单线程模式:实现原子性操作，让库存得到控制。Redis服务具备天然的原子性的操作特性，Redis的每一个操作都是一个原子性的操作，因此可以利用Redis的这个特性，实现库存控制，且Redis是高性能的内存数据库，利用redis实现性能与业务的完美结合
原子性操作
以上数据存储特点:把库存数据进行单独的存储，扣减库存直接使用库存进行扣减，而不是使用商品中数据进行扣减(因为使用商品数据扣减，必然会经过2步操作，这2步不是原子性，除非使用lua)
此时扣减库存的方式
1.扣减库存:hincrement(“seckill_goods_stock_1”,-1) #此操作是一个原子操作，下一个线程看见的是上一个线程执行的结果，线程之间具有先后顺序
2.判断库存是否存在
优点:既兼顾了性能问题，又解决了业务库存超卖问题

方案三

队列:Redis队列(其他队列)都具有原子性的操作:Redis-list队列实现库存超卖解决方案
特点:
1.队列的长度等于库存数量
2.队列中存储的数据是此商品的id
3.每一个商品都对应一个队列
此时扣减库存，只需要pop一个队列的元素即可，因为队列的长度等于库存数量，因此pop元素相当于扣减库存；此操作也是原子操作

aop锁(单机锁)

超卖:比如模拟1000个用户，产生1000个订单，实际上被卖出75个商品，因此超卖925个订单!!!

使用Lock锁进行库存控制:Lock lock = new ReentrantLock(true);

//开始加锁
lock.lock();finally{
//释放锁
lock.unlock;
}

以上加锁方式不能控制库存
锁事务冲突

aop锁(单机锁)

问题:针对以上的锁，事务冲突的问题
解决方案:锁上移(在事务开始之前加锁，事务结束后释放锁)
实现方式:表现层加锁，aop增强的方式进行加锁
aop锁

pom.xml

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-aop</artifactId></dependency>

LockAspect.java


package com.example.aop;import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
import org.springframework.context.annotation.Scope;
import org.springframework.core.annotation.Order;
import org.springframework.stereotype.Component;import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;@Component
@Scope
@Aspect
@Order(1)
public class LockAspect {private Lock lock = new ReentrantLock(true);@Pointcut("@annotation(com.example.aop.ServiceLock)")public void lockAspect(){}//增强方法@Around("lockAspect()")public Object around(ProceedingJoinPoint joinPoint){Object obj = null;//上锁lock.lock();try {//执行业务obj = joinPoint.proceed();} catch (Throwable e) {throw new RuntimeException(e);} finally {//释放锁lock.unlock();}return obj;}
}

ServiceLock.java


package com.example.aop;import java.lang.annotation.*;@Target({ElementType.PARAMETER,ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ServiceLock {String description() default "";
}

功能测试:没有出现超卖，加锁已经实现了库存的控制

分布式锁

为什么要使用分布式锁:
在JUC单机锁的模式下，只能在单个jvm进程中起作用，但是在集群，分布式部署模式下，无法使用单机锁控制多个jvm进程的并发修改问题，无法实现库存超卖控制
在集群服务，分布式服务模式下，存在多个jvm进程对共享资源并发修改的问题，单机锁无法控制在进程级别的共享资源互斥访问的问题，因此在分布式环境下，必须使用分布式锁
第三方锁

分布式应用原理:保证jvm进程对共享资源的互斥访问，防止jvm进程对共享资源并发修改
应用场景:
1.秒杀场景
2.12306抢票
3.退款

Mysql分布式锁

Mysql实现分布式锁几种方式:
1.乐观锁，悲观锁(这种方式在分布式模式下无法控制库存，单机可以控制)
在多进程模式下，多个事务出现了数据脏读，从而无法控制超卖，虽然加上行锁，但是锁失效后，事务还未提交，此时别的进程事务来读取数据，读到了脏数据
2.单独设计一个表，实现记录锁的操作(加锁:插入一条数据，释放锁:删除一条数据)

Redis分布式锁

ServiceRedisLock.java


package com.example.redis;import java.lang.annotation.*;@Target({ElementType.PARAMETER,ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ServiceRedisLock {String description() default "";
}

LockRedisAspect.java


package com.example.redis;import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Scope;
import org.springframework.core.annotation.Order;
import org.springframework.stereotype.Component;import javax.servlet.http.HttpServletRequest;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;@Component
@Scope
@Aspect
@Order(1)
public class LockRedisAspect {@Autowiredprivate HttpServletRequest request;@Pointcut("@annotation(com.example.redis.ServiceRedisLock)")public void lockAspect(){}//增强方法@Around("lockAspect()")public Object around(ProceedingJoinPoint joinPoint){Object obj = null;//获取秒杀idString requestURI = request.getRequestURI();String killId = requestURI.substring(requestURI.lastIndexOf("/")-1,requestURI.lastIndexOf("/"));//上锁boolean res = RedissLockUtil.tryLock("seckill_goods_lock_"+killId, TimeUnit.SECONDS,3,10);lock.lock();try {//执行业务if (res){obj = joinPoint.proceed();}} catch (Throwable e) {throw new RuntimeException(e);} finally {//释放锁if (res){RedissLockUtil.unlock("seckill_goods_lock_"+killId);}}return obj;}
}

在分布式下测试，可以控制库存

下单性能优化

优化一:从缓存中查询商品数据，不再从数据库查询
优化二:扣减库存，从缓存中开始扣减库存，不考虑数据一致性问题，只需要考虑数据最终一致性即可
优化三:异步化改造，下单的时候，只需要把订单数据传入到队列即可表示下单成功，后面队列的消费者来异步消费消息，实现下订单操作
下单的写的操作，当并发量比较大的时候，写操作会竞争锁资源，造成数据库性能下降。因此对这块代码进行异步化改造
异步处理:消费者在消费端进行监听，如果发现队列中有数据，立马消费队列中数据，然后处理业务

//判断库存是否还存在，如果不存在，那么就直接返回Integer stockStatus = (Integer) redisTemplate.opsForValue().get(Constants.REDIS_GOODS_END_KEY+killId);//判断
if(stockStatus!=null && stockStatus.equals(HttpStatus.SEC_GOODS_END)){return HttpResult.error("商品已无库存");
}//优化一:从缓存中查询商品数据，不再从数据库查询TbSeckillGoods seckillGoods = (TbSeckillGoods) redisTemplate.opsForValue().get("SECKILL_GOODS_STOCK_"+killId);/**
*库存扣减
*/
private boolean reduceStock(Long killId){Long stockNum = redisTemplate.opsForValue.increment("SECKILL_GOODS_STOCK_"+killId,-1);
//扣减成功
if(stockNum > 0){return true;
}else if(stockNum == 0){//最后一次扣减，stock=1，表示此时库存已经售卖完毕//添加标识，表示库存已经扣减完毕redisTemplate.opsForValue().set(Constants.REDIS_GOODS_END_KEY+killId,HttpStatus.SEC_GOODS_END);return true;
}
//扣减失败
return false;
}//第二步优化，从缓存中扣减库存，保证这个操作的原子性
boolean res = this.reduceStock(killId);
//判断库存是否扣减成功
if(!res){return HttpResult.error("下单失败");
}//下单
TbSeckillOrder order = new TbSeckillOrder();
order.setSeckillId(killId);
order.setUserId(userId);
//使用队列，把订单数据入队
Boolean succ = SeckillQueue.getMailQueue().produce(order);
if(!succ){return HttpResuLt.error("秒杀失败");
}
return HttpResult.ok("秒杀成功");

public void run(ApplicationArguments var){new Thread(() -> {LOGGER.info("提醒队列启动成功");//开启一个线程，一直监听bockingQueue队列while(true){try {//进程内队列TbSeckillOrder order = SeckillQueue.getMailQueue().consume();if(order!=null){//从队列中获取订单，执行下单操作seckillService.startAsyncKilled(order);}} catch (InterruptedException e) {e.printStackTrace();}}}).start();
}

数据一致性

CAP定理
C:一致性(数据一致性:牺牲性能为代价)
A:可用性(性能提升，暂时不追求一致性)
P:分区容错性
redis数据
CAP定理要求在软件架构的设计中，不能同时追求一致性，可用性，要么追求强一致性，要么只实现高性能
问题1:从缓存中扣减库存，存在缓存中缓存库存和数据库库存不一致现象
为了性能考虑，牺牲掉一致性，暂时把数据放在缓存中，放弃了一致性的问题，但是最终需要把数据变成一致性的状态。
如何处理?
(1)最终的一致性:支付完成后，同步库存
(2)异步的方式，同步库存

问题2:下单操作，扣减库存操作不是一个原子操作，一旦下单异常失败，本地事务会回滚，但是redis库存已经发生扣减

解决方案:
(1)异常机制对业务补偿
(2)缓存一致性

解决一致性问题

异步同步库存

发生场景，从缓存中扣减库存，但是数据库的库存没有发生任何的变化，因此可以使用异步的方式同步库存。
异步同步库存
引入新的问题，发送消息的操作和本地事务的操作不是一个原子性
半消息机制
消息一致性:为了保证本地消息，本地事务一致性

Rocketmq提供的事务消息，解决本地事务和数据库一致性问题，让发送消息的动作和本地事务是原子性的操作

缓存一致性:先操作数据库，再操作redis

同时操作数据库，缓存的时候，面临数据库和缓存数据一致性的问题，因为本地事务异常，缓存异常都可能造成数据一致性问题，因此解决这类问题的时候，只需要先操作数据库，后操作缓存即可
1.下单操作数据库出现了异常，本地事务回滚，此时缓存没有进行操作，因此数据是一致性的状态
2.下单成功，缓存操作异常，数据库本地事务会回滚，由于缓存没有操作成功，因此数据还是一致状态


@Transactional
@Override
public HttpResult startAsyncKilled(TbSeckillOrder order) {//为了实现缓存，数据库一致性，先操作数据库，后操作缓存order.setCreateTime(new Date());order.setStatus("0");order.setMoney(BigDecimal.ZERO);seckillOrderMapper.insertSelective(order);//第二步优化，从缓存中扣减库存，保证这个操作的原子性boolean res = this.reduceStock(order.getSeckillId());//判断库存是否扣减成功if(!res){return HttpResult.error("下单失败");}return HttpResult.ok();
}