|
|
51CTO旗下网站
|
|
移动端

简单几步,设计一个高性能的秒杀系统!

本次采用循序渐进的方式逐步提高性能达到并发秒杀的效果,文章较长,请准备好瓜子板凳!

作者:crossoverJie来源:crossoverJie|2019-06-27 09:50

【大咖·来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》

本次采用循序渐进的方式逐步提高性能达到并发秒杀的效果,文章较长,请准备好瓜子板凳!

图片来自包图网

之前在 Java-Interview 中提到过秒杀架构的设计,这次基于其中的理论简单实现了一下。

本文所有涉及的代码:

  • https://github.com/crossoverJie/SSM
  • https://github.com/crossoverJie/distributed-redis-tool

首先来看看最终架构图:

先简单根据这个图谈下请求的流转,因为后面不管怎么改进,这些都是不变的:

  • 前端请求进入 Web 层,对应的代码就是 Controller。
  • 之后将真正的库存校验、下单等请求发往 Service 层,其中 RPC 调用依然采用的 Dubbo,只是更新为***版本。
  • Service 层再对数据进行落地,下单完成。

***制

抛开秒杀这个场景来说,正常的一个下单流程可以简单分为以下几步:

  • 校验库存
  • 扣库存
  • 创建订单
  • 支付

基于上文的架构,我们有了以下实现,先看看实际项目的结构:

还是和以前一样:

  • 提供出一个 API 用于 Service 层实现,以及 Web 层消费。
  • Web 层简单来说就是一个 Spring MVC。
  • Service 层则是真正的数据落地。
  • SSM-SECONDS-KILL-ORDER-CONSUMER 则是后文会提到的 Kafka 消费。

数据库也是只有简单的两张表模拟下单:

  1. CREATE TABLE `stock` ( 
  2.   `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
  3.   `namevarchar(50) NOT NULL DEFAULT '' COMMENT '名称'
  4.   `countint(11) NOT NULL COMMENT '库存'
  5.   `sale` int(11) NOT NULL COMMENT '已售'
  6.   `version` int(11) NOT NULL COMMENT '乐观锁,版本号'
  7.   PRIMARY KEY (`id`) 
  8. ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8; 
  9.  
  10.  
  11. CREATE TABLE `stock_order` ( 
  12.   `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
  13.   `sid` int(11) NOT NULL COMMENT '库存ID'
  14.   `namevarchar(30) NOT NULL DEFAULT '' COMMENT '商品名称'
  15.   `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间'
  16.   PRIMARY KEY (`id`) 
  17. ) ENGINE=InnoDB AUTO_INCREMENT=55 DEFAULT CHARSET=utf8; 

Web 层 Controller 实现:

  1. @Autowired 
  2.    private StockService stockService; 
  3.  
  4.    @Autowired 
  5.    private OrderService orderService; 
  6.  
  7.    @RequestMapping("/createWrongOrder/{sid}"
  8.    @ResponseBody 
  9.    public String createWrongOrder(@PathVariable int sid) { 
  10.        logger.info("sid=[{}]", sid); 
  11.        int id = 0; 
  12.        try { 
  13.            id = orderService.createWrongOrder(sid); 
  14.        } catch (Exception e) { 
  15.            logger.error("Exception",e); 
  16.        } 
  17.        return String.valueOf(id); 
  18.    } 

其中 Web 作为一个消费者调用看 OrderService 提供出来的 Dubbo 服务。

Service 层, OrderService 实现,首先是对 API 的实现(会在 API 提供出接口):

  1. @Service 
  2. public class OrderServiceImpl implements OrderService { 
  3.  
  4.     @Resource(name = "DBOrderService"
  5.     private com.crossoverJie.seconds.kill.service.OrderService orderService ; 
  6.  
  7.     @Override 
  8.     public int createWrongOrder(int sid) throws Exception { 
  9.         return orderService.createWrongOrder(sid); 
  10.     } 

这里只是简单调用了 DBOrderService 中的实现,DBOrderService 才是真正的数据落地,也就是写数据库了。

DBOrderService 实现:

  1. Transactional(rollbackFor = Exception.class) 
  2. @Service(value = "DBOrderService"
  3. public class OrderServiceImpl implements OrderService { 
  4.     @Resource(name = "DBStockService"
  5.     private com.crossoverJie.seconds.kill.service.StockService stockService; 
  6.  
  7.     @Autowired 
  8.     private StockOrderMapper orderMapper; 
  9.  
  10.     @Override 
  11.     public int createWrongOrder(int sid) throws Exception{ 
  12.  
  13.         //校验库存 
  14.         Stock stock = checkStock(sid); 
  15.  
  16.         //扣库存 
  17.         saleStock(stock); 
  18.  
  19.         //创建订单 
  20.         int id = createOrder(stock); 
  21.  
  22.         return id; 
  23.     } 
  24.  
  25.     private Stock checkStock(int sid) { 
  26.         Stock stock = stockService.getStockById(sid); 
  27.         if (stock.getSale().equals(stock.getCount())) { 
  28.             throw new RuntimeException("库存不足"); 
  29.         } 
  30.         return stock; 
  31.     } 
  32.  
  33.     private int saleStock(Stock stock) { 
  34.         stock.setSale(stock.getSale() + 1); 
  35.         return stockService.updateStockById(stock); 
  36.     } 
  37.  
  38.     private int createOrder(Stock stock) { 
  39.         StockOrder order = new StockOrder(); 
  40.         order.setSid(stock.getId()); 
  41.         order.setName(stock.getName()); 
  42.         int id = orderMapper.insertSelective(order); 
  43.         return id; 
  44.     }         
  45.  

预先初始化了 10 条库存。手动调用下 createWrongOrder/1 接口发现:

库存表

订单表

一切看起来都没有问题,数据也正常。但是当用 JMeter 并发测试时:

测试配置是:300 个线程并发。测试两轮来看看数据库中的结果:

请求都响应成功,库存确实也扣完了,但是订单却生成了 124 条记录。这显然是典型的超卖现象。

其实现在再去手动调用接口会返回库存不足,但为时晚矣。

乐观锁更新

怎么来避免上述的现象呢?最简单的做法自然是乐观锁了,来看看具体实现:

其实其他的都没怎么改,主要是 Service 层:

  1. @Override 
  2.    public int createOptimisticOrder(int sid) throws Exception { 
  3.  
  4.        //校验库存 
  5.        Stock stock = checkStock(sid); 
  6.  
  7.        //乐观锁更新库存 
  8.        saleStockOptimistic(stock); 
  9.  
  10.        //创建订单 
  11.        int id = createOrder(stock); 
  12.  
  13.        return id; 
  14.    } 
  15.  
  16.    private void saleStockOptimistic(Stock stock) { 
  17.        int count = stockService.updateStockByOptimistic(stock); 
  18.        if (count == 0){ 
  19.            throw new RuntimeException("并发更新库存失败") ; 
  20.        } 
  21.    } 

对应的 XML:

  1. <update id="updateByOptimistic" parameterType="com.crossoverJie.seconds.kill.pojo.Stock"
  2.        update stock 
  3.        <set
  4.            sale = sale + 1, 
  5.            version = version + 1, 
  6.        </set
  7.  
  8.        WHERE id = #{id,jdbcType=INTEGER
  9.        AND version = #{version,jdbcType=INTEGER
  10.  
  11.    </update

同样的测试条件,我们再进行上面的测试 /createOptimisticOrder/1:

这次发现无论是库存订单都是 OK 的。

查看日志发现:

很多并发请求会响应错误,这就达到了效果。

提高吞吐量

为了进一步提高秒杀时的吞吐量以及响应效率,这里的 Web 和 Service 都进行了横向扩展:

  • Web 利用 Nginx 进行负载。
  • Service 也是多台应用。

再用 JMeter 测试时可以直观的看到效果。

由于我是在阿里云的一台小水管服务器进行测试的,加上配置不高、应用都在同一台,所以并没有完全体现出性能上的优势( Nginx 做负载转发时候也会增加额外的网络消耗)。

Shell 脚本实现简单的 CI

由于应用多台部署之后,手动发版测试的痛苦相信经历过的都有体会。

这次并没有精力去搭建完整的 CICD,只是写了一个简单的脚本实现了自动化部署,希望给这方面没有经验的同学带来一点启发。

构建 Web:

  1. #!/bin/bash 
  2.  
  3. # 构建 web 消费者 
  4.  
  5. #read appname 
  6.  
  7. appname="consumer" 
  8. echo "input="$appname 
  9.  
  10. PID=$(ps -ef | grep $appname | grep -v grep | awk '{print $2}'
  11.  
  12. # 遍历杀掉 pid 
  13. for var in ${PID[@]}; 
  14. do 
  15.     echo "loop pid= $var" 
  16.     kill -9 $var 
  17. done 
  18.  
  19. echo "kill $appname success" 
  20.  
  21. cd .. 
  22.  
  23. git pull 
  24.  
  25. cd SSM-SECONDS-KILL 
  26.  
  27. mvn -Dmaven.test.skip=true clean package 
  28.  
  29. echo "build war success" 
  30.  
  31. cp /home/crossoverJie/SSM/SSM-SECONDS-KILL/SSM-SECONDS-KILL-WEB/target/SSM-SECONDS-KILL-WEB-2.2.0-SNAPSHOT.war /home/crossoverJie/tomcat/tomcat-dubbo-consumer-8083/webapps 
  32. echo "cp tomcat-dubbo-consumer-8083/webapps ok!" 
  33.  
  34. cp /home/crossoverJie/SSM/SSM-SECONDS-KILL/SSM-SECONDS-KILL-WEB/target/SSM-SECONDS-KILL-WEB-2.2.0-SNAPSHOT.war /home/crossoverJie/tomcat/tomcat-dubbo-consumer-7083-slave/webapps 
  35. echo "cp tomcat-dubbo-consumer-7083-slave/webapps ok!" 
  36.  
  37. sh /home/crossoverJie/tomcat/tomcat-dubbo-consumer-8083/bin/startup.sh 
  38. echo "tomcat-dubbo-consumer-8083/bin/startup.sh success" 
  39.  
  40. sh /home/crossoverJie/tomcat/tomcat-dubbo-consumer-7083-slave/bin/startup.sh 
  41. echo "tomcat-dubbo-consumer-7083-slave/bin/startup.sh success" 
  42.  
  43. echo "start $appname success" 

构建 Service:

  1. # 构建服务提供者 
  2.  
  3. #read appname 
  4.  
  5. appname="provider" 
  6.  
  7. echo "input="$appname 
  8.  
  9.  
  10. PID=$(ps -ef | grep $appname | grep -v grep | awk '{print $2}'
  11.  
  12. #if [ $? -eq 0 ]; then 
  13. #    echo "process id:$PID" 
  14. #else 
  15. #    echo "process $appname not exit" 
  16. #    exit 
  17. #fi 
  18.  
  19. # 遍历杀掉 pid 
  20. for var in ${PID[@]}; 
  21. do 
  22.     echo "loop pid= $var" 
  23.     kill -9 $var 
  24. done 
  25.  
  26. echo "kill $appname success" 
  27.  
  28.  
  29. cd .. 
  30.  
  31. git pull 
  32.  
  33. cd SSM-SECONDS-KILL 
  34.  
  35. mvn -Dmaven.test.skip=true clean package 
  36.  
  37. echo "build war success" 
  38.  
  39. cp /home/crossoverJie/SSM/SSM-SECONDS-KILL/SSM-SECONDS-KILL-SERVICE/target/SSM-SECONDS-KILL-SERVICE-2.2.0-SNAPSHOT.war /home/crossoverJie/tomcat/tomcat-dubbo-provider-8080/webapps 
  40.  
  41. echo "cp tomcat-dubbo-provider-8080/webapps ok!" 
  42.  
  43. cp /home/crossoverJie/SSM/SSM-SECONDS-KILL/SSM-SECONDS-KILL-SERVICE/target/SSM-SECONDS-KILL-SERVICE-2.2.0-SNAPSHOT.war /home/crossoverJie/tomcat/tomcat-dubbo-provider-7080-slave/webapps 
  44.  
  45. echo "cp tomcat-dubbo-provider-7080-slave/webapps ok!" 
  46.  
  47. sh /home/crossoverJie/tomcat/tomcat-dubbo-provider-8080/bin/startup.sh 
  48. echo "tomcat-dubbo-provider-8080/bin/startup.sh success" 
  49.  
  50. sh /home/crossoverJie/tomcat/tomcat-dubbo-provider-7080-slave/bin/startup.sh 
  51. echo "tomcat-dubbo-provider-8080/bin/startup.sh success" 
  52.  
  53. echo "start $appname success" 

之后每当我有更新,只需要执行这两个脚本就可以帮我自动构建。都是最基础的 Linux 命令,相信大家都看得明白。

乐观锁更新 + 分布式限流

上文的结果看似没有问题,其实还差得远呢。这里只是模拟了 300 个并发没有问题,但是当请求达到了 3000,3W,300W 呢?

虽说可以横向扩展支撑更多的请求,但是能不能利用最少的资源解决问题呢?

仔细分析下会发现:假设我的商品一共只有 10 个库存,那么无论你多少人来买其实最终也最多只有 10 人可以下单成功。所以其中会有 99% 的请求都是无效的。

大家都知道:大多数应用数据库都是压倒骆驼的***一根稻草。通过 Druid 的监控来看看之前请求数据库的情况:

因为 Service 是两个应用:

数据库也有 20 多个连接。怎么样来优化呢?其实很容易想到的就是分布式限流。

我们将并发控制在一个可控的范围之内,然后快速失败这样就能***程度的保护系统。

①distributed-redis-tool ⬆v1.0.3

为此还对 https://github.com/crossoverJie/distributed-redis-tool 进行了小小的升级。

因为加上该组件之后所有的请求都会经过 Redis,所以对 Redis 资源的使用也是要非常小心。

②API 更新

修改之后的 API 如下:

  1. @Configuration 
  2. public class RedisLimitConfig { 
  3.  
  4.     private Logger logger = LoggerFactory.getLogger(RedisLimitConfig.class); 
  5.  
  6.     @Value("${redis.limit}"
  7.     private int limit; 
  8.  
  9.  
  10.     @Autowired 
  11.     private JedisConnectionFactory jedisConnectionFactory; 
  12.  
  13.     @Bean 
  14.     public RedisLimit build() { 
  15.         RedisLimit redisLimit = new RedisLimit.Builder(jedisConnectionFactory, RedisToolsConstant.SINGLE) 
  16.                 .limit(limit) 
  17.                 .build(); 
  18.  
  19.         return redisLimit; 
  20.     } 

这里构建器改用了 JedisConnectionFactory,所以得配合 Spring 来一起使用。

并在初始化时显示传入 Redis 是以集群方式部署还是单机(强烈建议集群,限流之后对 Redis 还是有一定的压力)。

③限流实现

既然 API 更新了,实现自然也要修改:

  1. /** 
  2.   * limit traffic 
  3.   * @return if true 
  4.   */ 
  5.  public boolean limit() { 
  6.  
  7.      //get connection 
  8.      Object connection = getConnection(); 
  9.  
  10.      Object result = limitRequest(connection); 
  11.  
  12.      if (FAIL_CODE != (Long) result) { 
  13.          return true
  14.      } else { 
  15.          return false
  16.      } 
  17.  } 
  18.  
  19.  private Object limitRequest(Object connection) { 
  20.      Object result = null
  21.      String key = String.valueOf(System.currentTimeMillis() / 1000); 
  22.      if (connection instanceof Jedis){ 
  23.          result = ((Jedis)connection).eval(script, Collections.singletonList(key), Collections.singletonList(String.valueOf(limit))); 
  24.          ((Jedis) connection).close(); 
  25.      }else { 
  26.          result = ((JedisCluster) connection).eval(script, Collections.singletonList(key), Collections.singletonList(String.valueOf(limit))); 
  27.          try { 
  28.              ((JedisCluster) connection).close(); 
  29.          } catch (IOException e) { 
  30.              logger.error("IOException",e); 
  31.          } 
  32.      } 
  33.      return result; 
  34.  } 
  35.  
  36.  private Object getConnection() { 
  37.      Object connection ; 
  38.      if (type == RedisToolsConstant.SINGLE){ 
  39.          RedisConnection redisConnection = jedisConnectionFactory.getConnection(); 
  40.          connection = redisConnection.getNativeConnection(); 
  41.      }else { 
  42.          RedisClusterConnection clusterConnection = jedisConnectionFactory.getClusterConnection(); 
  43.          connection = clusterConnection.getNativeConnection() ; 
  44.      } 
  45.      return connection
  46.  } 

如果是原生的 Spring 应用得采用 @SpringControllerLimit(errorCode=200) 注解。

实际使用如下,Web 端:

  1. /** 
  2.      * 乐观锁更新库存 限流 
  3.      * @param sid 
  4.      * @return 
  5.      */ 
  6.     @SpringControllerLimit(errorCode = 200) 
  7.     @RequestMapping("/createOptimisticLimitOrder/{sid}"
  8.     @ResponseBody 
  9.     public String createOptimisticLimitOrder(@PathVariable int sid) { 
  10.         logger.info("sid=[{}]", sid); 
  11.         int id = 0; 
  12.         try { 
  13.             id = orderService.createOptimisticOrder(sid); 
  14.         } catch (Exception e) { 
  15.             logger.error("Exception",e); 
  16.         } 
  17.         return String.valueOf(id); 
  18.     } 

Service 端就没什么更新了,依然是采用的乐观锁更新数据库。

再压测看下效果 /createOptimisticLimitOrderByRedis/1:

首先是看结果没有问题,再看数据库连接以及并发请求数都有明显的下降。

乐观锁更新+分布式限流+Redis 缓存

仔细观察 Druid 监控数据发现这个 SQL 被多次查询:

其实这是实时查询库存的 SQL,主要是为了在每次下单之前判断是否还有库存。

这也是个优化点。这种数据我们完全可以放在内存中,效率比在数据库要高很多。

由于我们的应用是分布式的,所以堆内缓存显然不合适,Redis 就非常适合。

  • 这次主要改造的是 Service 层:
  • 每次查询库存时走 Redis。
  • 扣库存时更新 Redis。

需要提前将库存信息写入 Redis。(手动或者程序自动都可以)

主要代码如下:

  1. @Override 
  2.   public int createOptimisticOrderUseRedis(int sid) throws Exception { 
  3.       //检验库存,从 Redis 获取 
  4.       Stock stock = checkStockByRedis(sid); 
  5.  
  6.       //乐观锁更新库存 以及更新 Redis 
  7.       saleStockOptimisticByRedis(stock); 
  8.  
  9.       //创建订单 
  10.       int id = createOrder(stock); 
  11.       return id ; 
  12.   } 
  13.  
  14.  
  15.   private Stock checkStockByRedis(int sid) throws Exception { 
  16.       Integer count = Integer.parseInt(redisTemplate.opsForValue().get(RedisKeysConstant.STOCK_COUNT + sid)); 
  17.       Integer sale = Integer.parseInt(redisTemplate.opsForValue().get(RedisKeysConstant.STOCK_SALE + sid)); 
  18.       if (count.equals(sale)){ 
  19.           throw new RuntimeException("库存不足 Redis currentCount=" + sale); 
  20.       } 
  21.       Integer version = Integer.parseInt(redisTemplate.opsForValue().get(RedisKeysConstant.STOCK_VERSION + sid)); 
  22.       Stock stock = new Stock() ; 
  23.       stock.setId(sid); 
  24.       stock.setCount(count); 
  25.       stock.setSale(sale); 
  26.       stock.setVersion(version); 
  27.  
  28.       return stock; 
  29.   }     
  30.  
  31.  
  32.   /** 
  33.    * 乐观锁更新数据库 还要更新 Redis 
  34.    * @param stock 
  35.    */ 
  36.   private void saleStockOptimisticByRedis(Stock stock) { 
  37.       int count = stockService.updateStockByOptimistic(stock); 
  38.       if (count == 0){ 
  39.           throw new RuntimeException("并发更新库存失败") ; 
  40.       } 
  41.       //自增 
  42.       redisTemplate.opsForValue().increment(RedisKeysConstant.STOCK_SALE + stock.getId(),1) ; 
  43.       redisTemplate.opsForValue().increment(RedisKeysConstant.STOCK_VERSION + stock.getId(),1) ; 
  44.   }     

压测看看实际效果 /createOptimisticLimitOrderByRedis/1:

***发现数据没问题,数据库的请求与并发也都下来了。

乐观锁更新+分布式限流+Redis 缓存+Kafka 异步

***的优化还是想如何来再次提高吞吐量以及性能的。我们上文所有例子其实都是同步请求,完全可以利用同步转异步来提高性能啊。

这里我们将写订单以及更新库存的操作进行异步化,利用 Kafka 来进行解耦和队列的作用。

每当一个请求通过了限流到达了 Service 层通过了库存校验之后就将订单信息发给 Kafka ,这样一个请求就可以直接返回了。

消费程序再对数据进行入库落地。因为异步了,所以最终需要采取回调或者是其他提醒的方式提醒用户购买完成。

这里代码较多就不贴了,消费程序其实就是把之前的 Service 层的逻辑重写了一遍,不过采用的是 Spring Boot。

总结

经过上面的一顿优化总结起来无非就是以下几点:

  • 尽量将请求拦截在上游。
  • 还可以根据 UID 进行限流。
  • ***程度的减少请求落到 DB。
  • 多利用缓存。
  • 同步操作异步化。
  • Fail Fast,尽早失败,保护应用。

码字不易,这应该是我写过字数最多的了,想想当年高中 800 字的作文都憋不出来😂,可想而知是有多难得了。

以上内容欢迎讨论,感兴趣的朋友可以看下:

  1. https://github.com/crossoverJie/SSM/tree/master/SSM-SECONDS-KILL/SSM-SECONDS-KILL-ORDER-CONSUMER 

【编辑推荐】

  1. 500行Python代码打造刷脸考勤系统,其实也就那么简单
  2. 华为“ARK OS”操作系统商标申请获德国批准 UI设计专利***亮相
  3. 系统管理员宝典:2019年7种实用的编程语言
  4. 史上坑爹的代码!个个让人崩溃!
  5. 滴滴出行架构大神分享:大型微服务框架设计实践
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

这就是5G

这就是5G

5G那些事儿
共15章 | armmay

115人订阅学习

16招轻松掌握PPT技巧

16招轻松掌握PPT技巧

GET职场加薪技能
共16章 | 晒书包

371人订阅学习

20个局域网建设改造案例

20个局域网建设改造案例

网络搭建技巧
共20章 | 捷哥CCIE

758人订阅学习

读 书 +更多

精通Spring 2.0

本书是关于Spring 2.0的权威教程,是Java/Java EE开发者必备的参考书。本书详尽系统地介绍了Java EE的基础知识、Spring 2.0的各种功能,以...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微