【项目实战】秒杀场景超高含金量项目，3000 QPS 高并发秒杀系统实现

已于 2024-04-22 16:00:41 修改
阅读量800 收藏 22
点赞数 19
分类专栏： JAVA学习笔记 文章标签： java spring cloud mybatis java-zookeeper java-rocketmq
于 2024-04-15 22:30:18 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_45215330/article/details/137796892
版权

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

前言

【项目实战】秒杀场景超高含金量项目，3000 QPS 高并发秒杀系统实现
视频链接见文章底部

一、项目导入

1. 导入代码

2. 阅读代码

前后端分离的跨域问题？（CORS）

比如80端口 请求9000端口

@Configuration
public class CorsConfig {
    @Bean
    public CorsWebFilter corsFilter() {
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(new PathPatternParser());
        CorsConfiguration config = new CorsConfiguration();
        // 允许cookies跨域
        config.setAllowCredentials(true);
        // #允许向该服务器提交请求的URI，*表示全部允许，在SpringMVC中，如果设成*，会自动转成当前请求头中的Origin
        config.addAllowedOrigin("*");
        // #允许访问的头信息,*表示全部
        config.addAllowedHeader("*");
        // 预检请求的缓存时间（秒），即在这个时间段里，对于相同的跨域请求不会再预检了
        config.setMaxAge(18000L);
        // 允许提交请求的方法，*表示全部允许
        config.addAllowedMethod("*");
        source.registerCorsConfiguration("/**", config);
        return new CorsWebFilter(source);
    }
}

跨域 --> 客户端需要询问服务端是否允许跨域

在发起api请求前，会构造一个预请求。疫预请求的方法是options类型

且请求参数，请求体都不存在。预请求的作用是请求到服务端，如果服务端允许跨域，就会通过预请求携带对应的响应头信息回来。

如果浏览器检测到响应头中有允许当前页面跨域，就会发起真实请求

cors：是一套机制，用于浏览器校验跨域请求。（同源策略）

基本理念：只要服务器明确表示允许则，校验通过。明确拒绝或没有表示，百不通过

微服务中如何获得用户真实IP？

用户---->网关---->微服务

网关可以拿到用户ip！

public class CommonFilter implements GlobalFilter {
    @Autowired
    private StringRedisTemplate redisTemplate;

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        /**
         * pre拦截逻辑
         * 在请求去到微服务之前，做了两个处理
         * 1.把客户端真实IP通过请求同的方式传递给微服务
         * 2.在请求头中添加FEIGN_REQUEST的请求头，值为0，标记请求不是Feign调用，而是客户端调用
         */
  ServerHttpRequest request =exchange.getRequest().mutate().
 header(CommonConstants.REAL_IP,exchange.getRequest().getRemoteAddress().getHostString()).
               header(CommonConstants.FEIGN_REQUEST_KEY,CommonConstants.FEIGN_REQUEST_FALSE).build();

全局过滤器，因为微服务的请求是网关转发过来的，getRequest().getRemoteAddress()获取到的是网关ip。

登录流程（jwt）

第0步：拿着token查

第一步：拿到用户信息，先到redis中查，查不到到数据库中查，并且存到redis中。

第二步：如果查到的信息为空或者查出的数据密码不符，往mq中发送消息（登录失败），抛出异常，提示密码或者用户名错误

第三步：密码符合，查出用户信息，创建token

private String createToken(UserInfo userInfo) {
    //token创建
    String token = UUID.randomUUID().toString().replace("-", "");
    //把user对象存储到redis中
    CommonRedisKey redisKey = CommonRedisKey.USER_TOKEN;
    redisTemplate.opsForValue().set(redisKey.getRealKey(token), JSON.toJSONString(userInfo), 		         redisKey.getExpireTime(), redisKey.getUnit());
    return token;
}

过期时间是30分钟，如何保证用户体验？
在过滤器中

/**
 * post拦截逻辑
 * 在请求执行完微服务之后,需要刷新token在redis的时间
 * 判断token不为空 && Redis还存在这个token对于的key,这时候需要延长Redis中对应key的有效时间.
 */
String token,redisKey;
if(!StringUtils.isEmpty(token =exchange.getRequest().getHeaders().getFirst(CommonConstants.TOKEN_NAME))
        && redisTemplate.hasKey(redisKey = CommonRedisKey.USER_TOKEN.getRealKey(token))){
    redisTemplate.expire(redisKey, CommonRedisKey.USER_TOKEN.getExpireTime(), CommonRedisKey.USER_TOKEN.getUnit());
}

二、秒杀功能实现

1. 秒杀列表功能展示

秒杀产品列表查询

数据库设计

商品表t_product

idbigint主键id
product_namevarchar产品名称
product_titlevarchar产品标题
product_imgvarchar产品图片链接
product_detaillongtext产品详细介绍
product_pricedecimal产品价格
秒杀商品表t_seckill_product
id
product_id（对应t_product_id）
seckill_price（价格）
intergral（积分）
stock_count（库存）
start_date（开始日期）
time（秒杀开始场次）		bigint
bigint
decimal
decimal
int
date
int

秒杀商品SeckillProductVo（t_product + t_seckill_product）

productName
productTitle
productImg
productDetail
productPrice
currentCount;

逻辑：

Result<List<SeckillProductVo>> selectTodayListByTime(@RequestParam("time") Integer time)

得到秒杀商品t_seckill_product_id集合

Result<List<Product>> selectByIdList(@RequestParam("ids") List<Long> idList);

得到id的商品集合

在这里插入图片描述

整体思想图

商品详情页

在这里插入图片描述

@RequestMapping("/find")
public Result<SeckillProductVo> findById(Integer time, Long seckillId) {
    return Result.success(seckillProductService.selectByIdAndTime(seckillId, time));
}

@Cacheable(key = "'selectByIdAndTime:' + #time + ':' + #seckillId")
public SeckillProductVo selectByIdAndTime(Long seckillId, Integer time) {
    SeckillProduct seckillProduct = seckillProductMapper.selectByIdAndTime(seckillId, time);

    Result<List<Product>> result = productFeignApi.selectByIdList(Collections.singletonList(seckillProduct.getProductId()));
    if (result.hasError() || result.getData() == null || result.getData().size() == 0) {
        throw new BusinessException(new CodeMsg(result.getCode(), result.getMsg()));
    }

    Product product = result.getData().get(0);

    SeckillProductVo vo = new SeckillProductVo();
    // 先将商品的属性 copy 到 vo 对象中
    BeanUtils.copyProperties(product, vo);

    // 再将秒杀商品的属性 copy 到 vo 对象中, 并覆盖 id 属性
    BeanUtils.copyProperties(seckillProduct, vo);
    return vo;
}

逻辑图

在这里插入图片描述

秒杀商品列表数据预热（定时任务）

zookeeper

public class SeckillProductInitJob implements SimpleJob {

    @Value("${job.seckillProduct.cron}")
    private String cron;
    @Value("${job.seckillProduct.shardingCount}")
    private Integer shardingCount;
    @Value("${job.seckillProduct.shardingParameters}")
    private String shardingParameters;
    @Value("${job.seckillProduct.dataFlow}")
    private boolean dataFlow;

    @Autowired
    private SeckillProductFeignApi seckillProductFeignApi;
    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @Override
    public void execute(ShardingContext shardingContext) {
        // 分片参数利用场次进行分片
        String time = shardingContext.getShardingParameter();

        // 先清空之前的数据
        String key = SeckillRedisKey.SECKILL_PRODUCT_LIST.join(time);
        stringRedisTemplate.delete(key);

        // 调用秒杀服务的接口, 查询秒杀商品数据
        Result<List<SeckillProductVo>> result = seckillProductFeignApi.selectTodayListByTime(Integer.valueOf(time));
        if (result.hasError() || result.getData() == null) {
            log.warn("[秒杀商品数据预热] 查询秒杀商品数据失败, 远程服务异常. res={}", JSON.toJSONString(result));
            return;
        }

        List<SeckillProductVo> productVoList = result.getData();
        log.info("[秒杀商品数据预热] 准备开始预热秒杀商品数据, 当前场次:{}, 本次缓存的数据:{}", time, productVoList.size());

        // 将数据存入 Redis : List
        // key=TODAY:{time}:SECKILL:PRODUCTS
        // value=SeckillProductVo => {json}
        for (SeckillProductVo vo : productVoList) {
            String json = JSON.toJSONString(vo);
            stringRedisTemplate.opsForList().rightPush(key, json);
        }
        log.info("[秒杀商品数据预热] 数据预热完成...");
    }
   }

2. 秒杀功能1.0

业务流程

①当前用户必须登录

②基于秒杀商品id，查询秒杀商品对象

③判断当前时间是否在秒杀开始到结束的范围之内

④判断当前秒杀商品库存是否足够

⑤判断该用户是否已经在当前场次买过商品

⑥扣减秒杀库存，创建秒杀订单

    @RequireLogin
    @RequestMapping("/doSeckill")
    public Result<String> doSeckill(Integer time, Long seckillId, @RequestHeader(CommonConstants.TOKEN_NAME) String token) {
        // 1. 基于 token 获取到用户信息(必须登录)
        UserInfo userInfo = this.getUserByToken(token);
        // 2. 基于场次+秒杀id获取到秒杀商品对象
        SeckillProductVo vo = seckillProductService.selectByIdAndTime(seckillId, time);
        if (vo == null) {
            throw new BusinessException(SeckillCodeMsg.REMOTE_DATA_ERROR);
        }
//         3. 判断时间是否大于开始时间 && 小于 开始时间+2小时
//        if (!DateUtil.isLegalTime(vo.getStartDate(), time)) {
//            throw new BusinessException(SeckillCodeMsg.OUT_OF_SECKILL_TIME_ERROR);
//        }
        // 4. 判断用户是否重复下单
        // 基于用户 + 秒杀 id + 场次查询订单, 如果存在订单, 说明用户已经下过单
        OrderInfo orderInfo = orderInfoService.selectByUserIdAndSeckillId(userInfo.getPhone(), seckillId, time);
        if (orderInfo != null) {
            throw new BusinessException(SeckillCodeMsg.REPEAT_SECKILL);
        }
        // 5. 判断库存是否充足
        if (vo.getStockCount() <= 0 || vo == null) {
            throw new BusinessException(SeckillCodeMsg.SECKILL_STOCK_OVER);
        }
        // 6. 执行下单操作(减少库存, 创建订单)
        String orderNo = orderInfoService.doSeckill(userInfo, vo);
        return Result.success(orderNo);
    }

扣减秒杀库存，创建秒杀订单

 public String doSeckill(UserInfo userInfo, SeckillProductVo vo) {
        // 1. 扣除秒杀商品库存
        int row = seckillProductService.decrStockCount(vo.getId());
        // 2. 创建秒杀订单并保存
        OrderInfo orderInfo = this.buildOrderInfo(userInfo, vo);
        orderInfoMapper.insert(orderInfo);
        // 3. 返回订单编号
        return orderInfo.getOrderNo();
    }

3. JMeter压力测试

生成测试账户

http://localhost:9000/uaa/token/initData

JMeter参数配置

线程组
在这里插入图片描述
HTTP请求
在这里插入图片描述
HTTP信息头管理
在这里插入图片描述
CSV数据文件设置
在这里插入图片描述

4. 秒杀功能2.0

超卖问题分析

秒杀流程图
在这里插入图片描述
存在的问题：

  1. 库存超卖
  2. 用户重复下单
    解释：redis库存未及时更新（缓存不同步）
    获取到商品对象时，会从数据查询，假设库存为10，之后同步redis库存为10。接着走一下流程，扣减库存，数据库库存为9，但是redis依然为10。下个用户来是，会直接查询redis。

超卖问题解决

优化方案：SpringCache
扣减库存时，同时更新redis数据
@CacheEvict
虽然缓存很有用，但在某些情况下可能需要逐出（删除）缓存的数据。注释@CacheEvict就是用于此目的。它确保在特定操作下，缓存保持最新。

   @CacheEvict(key = "'selectByIdAndTime:' + #time + ':' + #id")
   @Override
   public int decrStockCount(Long id, Integer time) {
       return seckillProductMapper.decrStock(id);
   }

优化后有所改善，但未解决
存在的问题：多线程并发（原子性问题）
原子性：即一个操作或者多个操作，要么全部执行，并且执行的过程不会被任何因素打断，要么就都不执行。
当多个线程同时执行到获取秒杀对象时，即同时拿到库存数为10
查库存与扣减库存不是同时进行。
优化：加锁
如图：
在这里插入图片描述
但性能会受到严重影响
优化：在扣除库存时，再次判断库存是否足够，并且加锁
在这里插入图片描述
具体加锁实现

        synchronized (this){
        //再次判断库存是否足够
        SeckillProduct sp = seckillProductService.findById(vo.getId());
            if(sp.getStockCount() <= 0){
                //库存不足
               throw new BusinessException(SeckillCodeMsg.SECKILL_STOCK_OVER);
           }
           //扣减库存
           seckillProductService.decrStockCount(vo.getId(),vo.getTime());   
        }

存在的问题： synchronized属于JVM锁，再单机环境下是有效的，但是分布式环境下由于有多个JVM实例，因此无法生效。
优化：将锁放在redis中
在这里插入图片描述
setIfAbsent == redis中的setnx方法，即设置key在redis中 已经存在，返回false
如果当前线程执行位ture则认为抢到了锁，为了避免别人的锁被释放，用一个唯一标识用来表示当前线程。
加锁后，需要释放锁

redisTemplate.delete(key)

存在的问题： 正在加锁时，JVM出现问题，导致锁无法释放，即死锁问题
优化：加入过期时间

redisTemplate.opsForValue().setIfAbsent(key + "code", 5, TimeUnit.SECONDS );

TDOD: Spring提供的setIfAbsent( ) 存在并发问题，原因是改方法是通过先调用 SET + EXPIRE 指令实现的，因为时多指令组成的，此时可能会存在多个线程并发执行。常见的解决方法为使用LUA脚本实现批处理命令。
存在的问题： 假如任务处理时间超过了自动释放的时间，即锁自动释放了，下一个2号线程会加锁，但是1号线程结束任务，会释放2号线程的锁。
优化： 加入唯一标识，释放锁时需要验证，是自己的锁才可以释放。

final String key = "seckill:product:";
String threadId = IdGenerateUtil.get().nextId() + "";
redisTemplate.opsForValue().setIfAbsent(key + vo.getId(), threadId,5, TimeUnit.SECONDS );

//释放锁时只能释放自己的锁
if(threadId.equals((redisTemplate.opsForValue().get(key)))){
	 redisTemplate.delete(key);
   }

存在的问题： 假如发生了超时释放锁的问题，即锁自动释放了，下一个2号线程会加锁，但是1号线程和2号线程存在同时扣除库存的可能。
优化：看门狗机制
个人来说就是一个key被锁住即将释放的时候，如果在当前线程还没执行完任务的时候，有新的线程进来争抢，会导致锁应该给谁的问题，这个时候官方为我们提供看门狗的机制，会自动增加锁的时间。

Redisson分布式锁

完善的优化机制①：Redisson分布式锁
加入依赖

		<dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson-spring-boot-starter</artifactId>
            <version>3.22.0</version>
        </dependency>

具体实现代码

public String doSeckill(UserInfo userInfo, SeckillProductVo vo) {
       final String key = "seckill:product:";
        //获取锁
       RLock rlock = redissonClient.getLock(key);
        try{
            // 加锁-超时时间5秒钟
           rlock.lock(5,TimeUnit.SECONDS);
            //如果加锁成功，扣减库存
            SeckillProduct sp = seckillProductService.findById(vo.getId());
           if(sp.getStockCount() <= 0){
                //库存不足
               throw new BusinessException(SeckillCodeMsg.SECKILL_STOCK_OVER);
           }
            // 1. 扣除秒杀商品库存
            int row = seckillProductService.decrStockCount(vo.getId(),vo.getTime());
            if(row <= 0){
                throw new BusinessException(SeckillCodeMsg.SECKILL_U);
            }
       }finally {
            //释放锁
           rlock.unlock();
       }
        // 2. 创建秒杀订单并保存
        OrderInfo orderInfo = this.buildOrderInfo(userInfo, vo);
        orderInfoMapper.insert(orderInfo);
        // 3. 返回订单编号
        return orderInfo.getOrderNo();
    }

存在的问题： 浅谈一下Redis分布式锁存在的问题
虽然redisson帮助我们解决了锁续期的问题，但是在redis集群架构中，由于主从复制具有一定的延时，那么在极端情况下就会出现这样一个问题：当一个线程获取锁成功，并且成功向主节点保存了锁信息，当主节点还未像从节点同步锁信息时，主节点宕机了，那么当发生故障转移从节点切换为主节点时，线程加的锁就丢失了。
优化方案： RedLock
为了解决这个问题，redis引入了红锁RedLock，RedLock与大多数中间件的选举机制类似，采用过半的方式来决定操作成功还是不成功。

	RLock lock = redissonClient.getLock("lock");
    RLock lock2 = redissonClient2.getLock("lock");
    RLock lock3 = redissonClient3.getLock("lock");
    RedissonRedLock redLock = new RedissonRedLock(lock,lock2,lock3);// 分别像三台实例加锁

完善的优化机制①总结：
在使用reids做分布式锁时，并没有想象中的那么简单，高并发场景下容易出现死锁，锁被其他线程误删，锁续期，锁丢失等问题，在实际开发中应该考虑到这些问题并根据相应的解决办法来解决这些问题，从而保证系统的安全性。

乐观锁

完善的优化机制②：乐观锁在这里插入代码片
乐观锁：认为线程安全问题不一定会发生，因此不加锁，只是在更新数据时去判断有没有其它线程对数据做了修改。如果没有修改则认为是安全的，自己才更新数据。如果已经被其它线程修改说明发生了安全问题，此时可以重试或异常。

	<update id="decrStock">
        update t_seckill_product
        set stock_count = stock_count - 1
        where id = #{seckillId} and stock_count > 0
    </update>

    public String doSeckill(UserInfo userInfo, SeckillProductVo vo) {
            // 1. 扣除秒杀商品库存
            int row = seckillProductService.decrStockCount(vo.getId(),vo.getTime());
            if(row <= 0){
                throw new BusinessException(SeckillCodeMsg.SECKILL_U);
            }
        // 2. 创建秒杀订单并保存
        OrderInfo orderInfo = this.buildOrderInfo(userInfo, vo);
        orderInfoMapper.insert(orderInfo);
        // 3. 返回订单编号
        return orderInfo.getOrderNo();
    }

并发优化

Redis库存预减方案

此时虽然通过乐观锁避免了超卖问题，但由于并发较高，还是会产生大量的请求进入扣库存环节，虽然会失败，但是会对性能产生较大影响。
因此希望能够在前置的环节中就控制并发访问任务
在这里插入图片描述

定时任务job

			//保存库存
            //外部key = seckillStockCount:{time}
            //hash key = {seckillId}
            //hash value = 库存
            stringRedisTemplate.opsForHash().put(SeckillRedisKey.SECKILL_STOCK_COUNT_HASH.join(time), vo.getId(), vo.getStockCount());

doSeckill

		//redis库存预减控制访问人数
        String join = SeckillRedisKey.SECKILL_STOCK_COUNT_HASH.join(time + "");
        Long increment = redisTemplate.opsForHash().increment(join, seckillId + "", -1);

        // 5. 判断库存是否充足
        if (increment < 0) {
            throw new BusinessException(SeckillCodeMsg.SECKILL_STOCK_OVER);
        }
库存售完标记

通过redis库存预减后，可以提前预知库存已经没有了，此时可以直接在jvm内存中标记该秒杀商品已经没有库存，之后的请求都没有必要访问redis。
在这里插入图片描述

具体实现

//本地售完标记 key= id， value = 是否已经售完
    private static final Map<Long, Boolean> LOCAL_STOCK_FLAG_CACHE = new ConcurrentHashMap<>();

//增加本地缓存判断
        if(LOCAL_STOCK_FLAG_CACHE.get(seckillId)){
            //如果是ture，直接提示库存不足
            throw new BusinessException(SeckillCodeMsg.SECKILL_STOCK_OVER);
        }

 if (increment < 0) {
            //标记当前库存已经售完
            LOCAL_STOCK_FLAG_CACHE.put(seckillId,true);
            throw new BusinessException(SeckillCodeMsg.SECKILL_STOCK_OVER);
        }
Redis记录用户是否重复下单

由于大部分用户都应该不会出现重复下单的问题，而此时每次从数据库查询是否已经下单，是浪费资源且性能较差的操作，因此希望可以借助redis实现记录用户下单状态，判断用户是否已经下单。
在这里插入图片描述
具体实现

		int max = 1;
        String userCountKey = SeckillRedisKey.SECKILL_ORDER_HASH.join(seckillId + "");
        Long increment1 = redisTemplate.opsForHash().increment(userCountKey, userInfo.getPhone() + "", 1);
        if(increment1 > max){
            throw new BusinessException(SeckillCodeMsg.REPEAT_SECKILL);
        }

优化结果

在这里插入图片描述

异步下单

具体实现

public class DefaultMQMessageCallBack implements SendCallback {
    @Override
    public void onSuccess(SendResult sendResult) {
        log.info("[异步消息回调]:发送消息成功:{}",sendResult);
    }

    @Override
    public void onException(Throwable throwable) {
        log.error("[异步消息回调]:消息发送失败，准备重新投递消息",throwable);

    }
}

目的地，参数，CallBack

public void asyncSend(String destination,Object payload,org.apache.rocketmq.client.producer.SendCallback sendCallback )

// 6. 执行下单操作(减少库存, 创建订单)
        //利用RockMq发送消息，实现异步下单
        rocketMQTemplate.asyncSend(MQConstant.ORDER_PEDDING_TOPIC,new OrderMessage(time, seckillId, token, userInfo.getPhone()),new DefaultMQMessageCallBack());
//        String orderNo = orderInfoService.doSeckill(userInfo, vo);
        return Result.success("成功加入下单队列，正在排队中...");
//        return Result.success(orderNo);
    }

下单操作

@RocketMQMessageListener(consumerGroup = MQConstant.ORDER_PENDING_CONSUMER_GROUP,topic = MQConstant.ORDER_PEDDING_TOPIC	)
public class OrderPendingMessage implements RocketMQListener<OrderMessage> {
    @Autowired
    private IOrderInfoService orderInfoService;
    @Autowired
    private ISeckillProductService seckillProductService;
    @Override
    public void onMessage(OrderMessage orderMessage) {
        log.info("[创建订单消息]:收到创建订单消息，准备开始创建订单{}", JSON.toJSON(orderMessage));
        //调用秒杀接口
        UserInfo userInfo = new UserInfo();
        userInfo.setPhone(orderMessage.getUserPhone());
        orderInfoService.doSeckill(userInfo, seckillProductService.selectByIdAndTime(orderMessage.getSeckillId(), orderMessage.getTime()));
    }
}

存在的问题是无法给用户及时发送通知，更新订单信息。
解决方案： 长连接方案

主要的步骤为：

  1. 创建订单
  2. 将订单创建结果发送到 mq
  3. MQ 将结果通知给长连接服务
  4. 长连接服务收到消息后，利用连接将结果通知给客户端
    优点：性能较高，可以实现服务端主动推送消息
    缺点：实现相对复杂，且有些浏览器可能不支持
    常见方案：
    HTTP：就是利用 keepalive 属性，延长单个请求的连接时间，当客户端发起请求给服务端后，服务端在没有结果以前，不进行响应，始终保持连接（也可以设置超时时间），一旦服务端收到消息后，再将结果响应回去。客户端收到消息/超时后可重新发起请求再次获取消息。
  • Tomcat 的 Comet 技术
  • Jetty 的 Continuations
    适用场景：消息较少，又需要长时间等待服务端响应结果的场景
    WEBSOCKET：可以理解 web 版本的 socket 连接，就是基于 TCP 协议实现的一个连接，连接建立成功后，一般情况下不会断开，除非服务单/客户端主动断开。
    在这里插入图片描述
    具体实现：
    public void onMessage(OrderMessage orderMessage) {
        log.info("[创建订单消息]:收到创建订单消息，准备开始创建订单{}", JSON.toJSON(orderMessage));
        OrderMQResult orderMQResult = new OrderMQResult();
        

        try {
            orderMQResult.setTime(orderMessage.getTime());
            orderMQResult.setSeckillId(orderMessage.getSeckillId());
            //调用秒杀接口
            UserInfo userInfo = new UserInfo();
            userInfo.setPhone(orderMessage.getUserPhone());
            String orderNo = orderInfoService.doSeckill(userInfo, seckillProductService.selectByIdAndTime(orderMessage.getSeckillId(), orderMessage.getTime()));
            //订单创建成功
            orderMQResult.setOrderNo(orderNo);
            
        }catch (Exception e){
            //订单创建失败
            SeckillCodeMsg seckillError = SeckillCodeMsg.SECKILL_ERROR;
            orderMQResult.setCode(seckillError.getCode());
            orderMQResult.setMsg(seckillError.getMsg());
            
        }
        //发送订单创建结果消息
        rocketMQTemplate.asyncSend(MQConstant.ORDER_RESULT_TOPIC, orderMQResult, new DefaultMQMessageCallBack());
    }
订单详情查询

主要是需要判断订单是否是自己的

@GetMapping("/find")
public Result<OrderInfo> findOrderId(String orderNo, @RequestHeader(CommonConstants.TOKEN_NAME) String token){
    UserInfo userByToken = getUserByToken(token);
    OrderInfo orderInfo = orderInfoService.findOrderId(orderNo);
    if(orderInfo != null && userByToken.getPhone().equals(orderInfo.getUserId())){
        throw new RuntimeException("非法操作");
    }
    return Result.success(orderInfo);
}
超时取消订单

如果订单超过一定时间，还不支付，需要自动的将订单状态取消，并重新回补库存。
发布时间：在订单下单成功后

收到消息：

  • 检查订单是否已经支付，如果已经支付就不管它
  • 如果没有支付，将订单状态更新为超时取消
  • MySQL 库存+1
  • 重新查到 MySQL 的库存后存入 Redis
  • 本地售完标识清
    具体实现 ：

延时发送：asyncSend（主题，参数，callback，超时时间，延迟等级）

//创建订单成功，发送延时消息检查超时未支付订单
Message<OrderTimeOutMessage> build = MessageBuilder.withPayload(new OrderTimeOutMessage(orderNo, orderMessage.getSeckillId())).build();
rocketMQTemplate.asyncSend(MQConstant.ORDER_PAY_TIMEOUT_TOPIC,build, new DefaultMQMessageCallBack(), 2000, 3);

监听者

@RocketMQMessageListener(
        consumerGroup = MQConstant.ORDER_PAY_TIMEOUT_GROUP,
        topic = MQConstant.ORDER_PAY_TIMEOUT_TOPIC
)
@Slf4j
public class OrderPayTimeOutListener implements RocketMQListener<OrderTimeOutMessage> {

    @Autowired
    private IOrderInfoService orderInfoService;

    @Override
    public void onMessage(OrderTimeOutMessage message) {
        log.info("[超时未支付检查] 收到超时为支付检查信息:{}", message);
        //超时未支付检查
        orderInfoService.checkPayTime(message);


    }
}

checkPayTime

public void checkPayTime(OrderTimeOutMessage message) {
        //根据订单编号，查询订单是否支付
        //OrderInfo orderInfo = orderInfoMapper.find(message.getOrderNo());
        //支付则结束，更新订单状态为超时取消
        int status = orderInfoMapper.updateCancelStatus(message.getOrderNo(), OrderInfo.STATUS_TIMEOUT);
        if(status >0){
            //sql， 库存+1
            seckillProductService.incryStockCount(message.getSeckillId());
            //查询sql 后，将库存存入 redis
            SeckillProduct seckillProduct = seckillProductService.findById(message.getSeckillId());
            redisTemplate.opsForHash().put(SeckillRedisKey.SECKILL_STOCK_COUNT_HASH.join(seckillProduct.getTime() + ""),
                    seckillProduct.getId() + "", seckillProduct.getStockCount() + "");
            //清除本地标志
            OrderInfoController.LOCAL_STOCK_FLAG_CACHE.remove(message.getSeckillId());  
        }
    }

关于清除本地标记问题：分布式缓存同步
由于本地标识是缓存在 JVM 中的，当秒杀服务集群部署时，可能各个不同的服务中都存在该库存售完标记，此时只是清空超时订单所在服务器的话，可能其他服务器本地售完标记还未清除，导致请求到其他服务器的用户，无法抢购商品。
在这里插入图片描述

OrderInfoController.LOCAL_STOCK_FLAG_CACHE.remove(message.getSeckillId());

rocketMQTemplate.asyncSend(MQConstant.CANCEL_SECKILL_OVER_SIGE_TOPIC, message.getSeckillId(), new DefaultMQMessageCallBack());

//消息模式修改为广播消息
@RocketMQMessageListener(
        consumerGroup = MQConstant.CANCEL_SECKILL_OVER_SIGE_GROUP,
        topic = MQConstant.CANCEL_SECKILL_OVER_SIGE_TOPIC,
        messageModel = MessageModel.BROADCASTING
        
)
@Slf4j
public class ClearLocalStockMessageListener implements RocketMQListener<Long> {
    @Override
    public void onMessage(Long seckillId) {
        log.info("[清除本地标识]收到清除本地标识，清除本地售完标识：{}", seckillId);
        OrderInfoController.LOCAL_STOCK_FLAG_CACHE.put(seckillId, false);
    }
}

步骤：
[异步消息回调]发送消息成功：SendResult（发送创建订单消息）
[创建订单消息]收到创建订单消息，准备开始创建订单
[异步消息回调]发送消息成功：SendResult（订单结果通知–ORDER_RESULT_TOPIC）
[异步消息回调]发送消息成功：SendResult（订单未支付超时检查–ORDER_PAY_TIMEOUT_TOPIC）
[超时未支付检查]收到超时未支付检查
[异步消息回调]发送消息成功：SendResult(清除本地标志广播消息–CANCEL_SECKILL_OVER_SIGE_TOPIC）
[清除本地标识]收到清楚本地标识请求，清楚本地售完标识

1

视频链接：bilibili
持续更新中

西塘的猫
关注
  • 19
    点赞
  • 踩
  • 22
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
【高并发】秒杀业务场景详解
Steven_L_的博客
06-16 5790
一、秒杀场景的特点        秒杀的商品具有价格低、库存有限、定时开始的特点，因此秒杀场景最大的特点就是高并发。数以千万的用户的流量集中在某个时间点上（即秒杀开始时），给后端服务器造成很大压力，如果不能进行有效削峰、限流，所有请求一次性打到某一台服务器或数据库上，必然造成服务的不可用，给用户造成不良体验。 二、整体架构设计        在整体架构上，用户的请求首先通过一个
别再拿TPS说事了！说实在的，有些场景3000TPS就够用了 | 人物志
区块链大本营
06-08 9494
两台机器实现QPS3000的服务优化
u011734144的专栏
11-16 2267
服务流程：      输入为一句话， 分词、匹配百科词条，读redis过滤、从redis读词条summary信息、返回   需求：      业务方的峰值QPS为3000   按照之前相关百科的一套逻辑： 单机tornado服务进程数4个 模拟10个并发，压测的QPS为332， 响应时间为30ms $siege -c10 -r5000 -f urls.lst Transacti...
QPS这么高，那就来写个多级缓存吧
程序猿杂货铺
12-26 747
查询mysql数据库时，同样的输入需要不止一次获取值或者一个查询需要做大量运算时，很容易会想到使用redis缓存。但是如果查询并发量特别大的话，请求redis服务也会特别耗时，这种场景下，将redis迁移到本地减少查询耗时是一种常见的解决方法 多级缓存基本架构 说明：存储选择了mysql、redis和guava cache。 mysql作为持久化，redis作为分布式缓存， guava ca...
盘点和总结秒杀服务的功能设计及注意事项技术体系
Java_zhujia的博客
12-11 493
对于普通用户来讲，看到的只是一个比较简单的秒杀页面，在未达到规定时间，秒杀按钮是灰色的，一旦到达规定时间，灰色按钮变成可点击状态。分析秒杀的业务场景，最重要的有一点就是超卖问题，假如备货只有100个，但是最终超卖了200，一般来讲秒杀系统的价格都比较低，如果超卖将严重影响公司的财产利益，因此首当其冲的就是解决商品的超卖问题。现在的秒杀大多都会出来针对秒杀对应的软件，这类软件会模拟不断向后台服务器发起请求，一秒几百次都是很常见的，如何防止这类软件的重复无效请求，防止不断发起的请求也是需要我们针对性考虑的。
【避坑参考】如何实现一个百万QPS的秒杀系统
最新发布
蹊源的奇思妙想的博客
03-04 1019
在构建百万QPS的秒杀系统的道路上，没有一种放之四海而皆准的完美方案。每个业务场景都有其独特的需求和挑战，因此最合适的方案往往是基于具体业务场景量身定制的。通过本文的分享，我们希望能够为读者提供一些有益的架构设计和实战经验，帮助你们在面对高并发挑战时能够更加从容和高效。然而，最终的方案还需要结合具体业务场景进行不断的调整和优化。希望这些分享能为你们带来启发，并帮助你们在实际操作中更好地应对各种挑战。
苏宁高时效、高并发秒杀业务中台的设计与实现
02-24
就秒杀业务而言，系统在瞬时会达到极高的并发量，如果与其它业务耦合，那么势必会对其它业务造成风险，因此基于安全性考虑和业务隔离原则，秒杀系统在设计上应该与其它系统充分解耦，单独部署。本文将讨论在苏宁现有...
系统吞吐量、TPS（QPS）、用户并发量、性能测试概念和公式
02-25
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间QPS（TPS）：每秒钟request/事务数量并发数：系统同时处理的request/事务数响应时间：一般取平均响应时间（很多人经常会把并发数和TPS理解混淆）理解了上面三...
Python并发请求下限制QPS(每秒查询率)的实现代码
09-16
主要介绍了Python并发请求下限制QPS(每秒查询率)实现方法，本文通过实例代码给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
Python 项目开发实战项目 - Python tornado 开发 BBS 论坛项目源码
02-15
项目使用高性能异步服务器框架Tornado来实现，在单个Tornado实例下，4核Intel i7 cpu可以达到1000-3000 的QPS 功能模块： # 授权模块 * 登陆 * 注册 * 注销 * 验证码 # 问题模块 * 问题列表 * 问题分页 * 问题...
软件测试中的QPS和TPS解析：以秒杀系统为例
jakelihua
12-13 543
通过不断地调整测试负载、监测系统响应时间和记录QPS、TPS值的变化，测试团队可以发现潜在的性能瓶颈和问题，为系统的优化和改进提供有力的支持。综合QPS和TPS评价系统的性能，将有助于确保系统在各种条件下都能够保持稳定、高效的运行。在进行软件测试时，测试团队可以通过模拟用户查询请求，测量系统在一秒内能够处理的查询次数来评估QPS。在秒杀系统中，TPS反映了系统对用户秒杀请求的处理速度。假设用户在秒杀系统中发起了1000次秒杀请求，测试团队通过记录系统在一秒内成功处理的秒杀请求数量，来评估系统的TPS。
大厂防止超卖的7种实现，很受用！
犬小哈
07-26 614
点击关注公众号，Java干货及时送达????高并发场景在现场的日常工作中很常见，特别是在互联网公司中，这篇文章就来通过秒杀商品来模拟高并发的场景。本文环境：SpringBoot 2.5.7 + MySQL 8.0 X + MybatisPlus + Swagger2.9.2模拟工具：Jmeter模拟场景：减库存->创建订单->模拟支付基于 Spring Boot + MyBatis P...
原生PHP、Laravel、MIXPHP、Go高并发性能测试QPS
十年砍柴的博客
09-17 4309
系统环境： 4核8G内存，SSD硬盘 CentOS 6.5 64位 MySQL 5.6.29 PHP 5.6.22 Apache 2.2.31 nginx 1.10.0 启用OPcache web架构为： 把php请求利用Nginx反向代理给后端的Apache或者MIXPHP。 测试之前，请先查看apache的ab测试注意点：Apache的ab进行并发性能测试的注意点 一、基准性能测试 1000并发，1万请求数： ab-n10000-c1000{URL} 1...
支撑60WQPS的秒杀系统
11-15 1092
简介 秒杀能够以极小的经费撬动巨大的流量，虽然会带来一定的口碑损失，但因为极具性价比，所以经常被运营同学使用。本文介绍如何设计一款能够支撑60W QPS的秒杀系统，希望能够帮助到大家。 这套系统有着漫长的演变历史，从最初利用Nginx、PHP，到后来使用GO，团队慢慢的将系统做的更加稳定。唯一不好的地方是，当年我写的后台还在使用（写前端代码能力有限），运营配置体验上有些瑕疵，后期需要优化一版。 目前14台8+32的机器，可以支撑60W QPS，理论上还能支持的更高，不过单ELB的上限是60W，即使流量再高，
单机Qps上限是多少？
weixin_34290352的博客
07-11 5357
现在这个年代，你要是不懂高并发，你都不好意思说自己是搞互联网的! 一、什么是并发，什么是高并发 并发，两个及以上的行为一起发生，比如你一边吃饭一边看电视 高并发，多个行为（至于是多少，这个没有定数，你可以认为是100,1000）一起发生 二、要多久才能处理完这些请求 首先，我们需要明确两个基本点 1、处理每个请求需要耗费时间，哪怕时间很短 2、服务资源是有限的，不能一次性处理全部请求 我们可以...
秒杀系统架构设计与实现(2)--15万QPS
AI
05-21 2848
前面我们进行了二版简单的架构设计与实现(详细点击 1万+QPS秒杀 , 10万+QPS秒杀)，这版我们继续架构演进，主要服务与服务进行解耦1、架构2、开压15万QPS一台机器（部署可以看https://blog.csdn.net/luozhonghua2014/article/details/80362614）的确有点扛不住了 ~哈哈3、看看DB如何了嗯，数据完整4、 服务解耦提供者服务，我们采用...
服务器系统怎么做高并发,QPS 高并发 如何设计一个支撑高并发大流量的系统？...
06-07
要设计一个支撑高并发大流量的系统，需要考虑以下几个方面： 1. 构建分布式系统：将系统分成多个模块，每个模块可以独立部署和扩展。这样可以减轻单个服务器的压力，提高系统的可用性和可扩展性。 2. 优化数据库访问：使用缓存技术和数据库读写分离等方式，减少数据库的负载和响应时间。 3. 负载均衡：通过负载均衡技术，将请求分发到多个服务器上，从而平衡服务器的负载，提高系统的性能和可用性。 4. 异步处理：将一些耗时的操作异步处理，如异步写日志、异步发送邮件等，避免阻塞请求线程，提高系统的并发能力。 5. CDN加速：使用CDN技术，将静态资源缓存在CDN节点上，加速用户访问速度，减少服务器负载。 6. 压力测试：对系统进行压力测试，模拟实际用户访问情况，发现系统瓶颈，优化系统设计和配置。 7. 自动化运维：使用自动化运维工具，如Ansible、Puppet等，实现系统部署、配置、监控等自动化管理，提高系统的可靠性和稳定性。 以上是设计支撑高并发大流量系统的一些关键点，需要根据具体的业务场景和技术架构进行应用。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值