Java を使用して効率的なフラッシュ セール システムを実装するにはどうすればよいですか?

最初に、最終的なアーキテクチャ図を見てみましょう:

この図に基づいてリクエストのフローについて簡単に説明します。これは、どのように改善しても問題がないためです。

• フロントエンド リクエストは Web 層に入り、対応するコードはコントローラーです。

• その後、実際の在庫確認、発注などのリクエストがサービス層に送信され、RPC 呼び出しでは引き続き Dubbo が使用されますが、*** バージョンに更新されます。

• サービス層はデータを実装し、注文が行われます。

*** システム

フラッシュ セールのシナリオはさておき、通常の注文プロセスは次のステップに単純に分割できます。

• 在庫の確認

• 在庫の差し引き

• 注文の作成

• 支払い

上記の構造に基づいて、次のようになります。実装については、まず実際のプロジェクトの構造を見てみましょう:

これは以前と同じです:

• API を提供しますサービス層の実装と Web 層の利用。

• Web 層は単なる Spring MVC です。

• サービス層は実際のデータ実装です。

• SSM-SECONDS-KILL-ORDER-CONSUMER は、後述する Kafka の消費です。

データベースには、順序をシミュレートするための単純なテーブルが 2 つだけあります:

CREATE TABLE `stock` (   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,   `name` varchar(50) NOT NULL DEFAULT '' COMMENT '名称',   `count` int(11) NOT NULL COMMENT '库存',   `sale` int(11) NOT NULL COMMENT '已售',   `version` int(11) NOT NULL COMMENT '乐观锁，版本号',   PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;   CREATE TABLE `stock_order` (   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,   `sid` int(11) NOT NULL COMMENT '库存ID',   `name` varchar(30) NOT NULL DEFAULT '' COMMENT '商品名称',   `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',   PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=55 DEFAULT CHARSET=utf8;

Web 層コントローラーの実装:

@Autowired    private StockService stockService;     @Autowired    private OrderService orderService;     @RequestMapping("/createWrongOrder/{sid}")    @ResponseBody    public String createWrongOrder(@PathVariable int sid) {        logger.info("sid=[{}]", sid);        int id = 0;        try {            id = orderService.createWrongOrder(sid);        } catch (Exception e) {            logger.error("Exception",e);        }        return String.valueOf(id);    }

Web はコンシューマーとして呼び出されますOrderService が提供する Dubbo サービスを見てください。

サービス層である OrderService 実装は、最初に API の実装です (出力インターフェイスは API で提供されます):

@Service public class OrderServiceImpl implements OrderService {      @Resource(name = "DBOrderService")     private com.crossoverJie.seconds.kill.service.OrderService orderService ;      @Override     public int createWrongOrder(int sid) throws Exception {         return orderService.createWrongOrder(sid);     } }

ここでは、DBOrderService の実装への単純な呼び出しを示します。DBOrderService は、実際のデータ ランディング、つまりデータベースの書き込み。

DBOrderService 実装:

Transactional(rollbackFor = Exception.class) @Service(value = "DBOrderService") public class OrderServiceImpl implements OrderService {     @Resource(name = "DBStockService")     private com.crossoverJie.seconds.kill.service.StockService stockService;      @Autowired     private StockOrderMapper orderMapper;      @Override     public int createWrongOrder(int sid) throws Exception{          //校验库存         Stock stock = checkStock(sid);          //扣库存         saleStock(stock);          //创建订单         int id = createOrder(stock);          return id;     }      private Stock checkStock(int sid) {         Stock stock = stockService.getStockById(sid);         if (stock.getSale().equals(stock.getCount())) {             throw new RuntimeException("库存不足");         }         return stock;     }      private int saleStock(Stock stock) {         stock.setSale(stock.getSale() + 1);         return stockService.updateStockById(stock);     }      private int createOrder(Stock stock) {         StockOrder order = new StockOrder();         order.setSid(stock.getId());         order.setName(stock.getName());         int id = orderMapper.insertSelective(order);         return id;     }          }

事前に初期化された 10 個のインベントリ。 createWrongOrder/1 インターフェイスを手動で呼び出して、次を見つけます:

#在庫テーブル

##注文テーブル

#Everything問題はないようで、データは正常です。ただし、同時テストに JMeter を使用する場合:

テスト構成は: 同時 300 スレッドです。 2 ラウンドをテストして、データベース内の結果を確認します:

##リクエストはすべて正常に応答され、在庫は実際に差し引かれましたが、注文に対して 124 レコードが生成されました。これは明らかに典型的な売られ過ぎ現象です。

実際、ここでインターフェイスを手動で呼び出すと、不十分な在庫が返されますが、もう手遅れです。

#オプティミスティック ロックの更新

上記の現象を回避するにはどうすればよいですか?最も簡単な方法は当然のことながらオプティミスティック ロックです。具体的な実装を見てみましょう:

実際には、他に大きな変更はありません。主にサービス層です:

@Override    public int createOptimisticOrder(int sid) throws Exception {         //校验库存        Stock stock = checkStock(sid);         //乐观锁更新库存        saleStockOptimistic(stock);         //创建订单        int id = createOrder(stock);         return id;    }     private void saleStockOptimistic(Stock stock) {        int count = stockService.updateStockByOptimistic(stock);        if (count == 0){            throw new RuntimeException("并发更新库存失败") ;        }    }

対応する XML:

<update>        update stock        <set>            sale = sale + 1,            version = version + 1,        </set>         WHERE id = #{id,jdbcType=INTEGER}        AND version = #{version,jdbcType=INTEGER}     </update>

同じテスト条件で、上記のテストを再度実行します/createOptimisticOrder/1:

今回は、どちらの在庫注文もOKであることがわかりました。

ログを確認して、次の情報を見つけます。

多くの同時リクエストがエラーで応答し、結果が得られます。

#スループットの向上

フラッシュ セール時のスループットと応答効率をさらに向上させるために、Web とサービスの両方を水平方向に拡張しました。

Web は読み込みに Nginx を使用します。

• サービスはマルチアプリケーションでもあります。



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

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

Shell 脚本实现简单的 CI

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

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

构建 Web：

#!/bin/bash  # 构建 web 消费者  #read appname  appname="consumer" echo "input="$appname  PID=$(ps -ef | grep $appname | grep -v grep | awk '{print $2}')  # 遍历杀掉 pid for var in ${PID[@]}; do     echo "loop pid= $var"     kill -9 $var done  echo "kill $appname success"  cd ..  git pull  cd SSM-SECONDS-KILL  mvn -Dmaven.test.skip=true clean package  echo "build war success"  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 echo "cp tomcat-dubbo-consumer-8083/webapps ok!"  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 echo "cp tomcat-dubbo-consumer-7083-slave/webapps ok!"  sh /home/crossoverJie/tomcat/tomcat-dubbo-consumer-8083/bin/startup.sh echo "tomcat-dubbo-consumer-8083/bin/startup.sh success"  sh /home/crossoverJie/tomcat/tomcat-dubbo-consumer-7083-slave/bin/startup.sh echo "tomcat-dubbo-consumer-7083-slave/bin/startup.sh success"  echo "start $appname success"

构建 Service：

# 构建服务提供者  #read appname  appname="provider"  echo "input="$appname   PID=$(ps -ef | grep $appname | grep -v grep | awk '{print $2}')  #if [ $? -eq 0 ]; then #    echo "process id:$PID" #else #    echo "process $appname not exit" #    exit #fi  # 遍历杀掉 pid for var in ${PID[@]}; do     echo "loop pid= $var"     kill -9 $var done  echo "kill $appname success"   cd ..  git pull  cd SSM-SECONDS-KILL  mvn -Dmaven.test.skip=true clean package  echo "build war success"  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  echo "cp tomcat-dubbo-provider-8080/webapps ok!"  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  echo "cp tomcat-dubbo-provider-7080-slave/webapps ok!"  sh /home/crossoverJie/tomcat/tomcat-dubbo-provider-8080/bin/startup.sh echo "tomcat-dubbo-provider-8080/bin/startup.sh success"  sh /home/crossoverJie/tomcat/tomcat-dubbo-provider-7080-slave/bin/startup.sh echo "tomcat-dubbo-provider-8080/bin/startup.sh success"  echo "start $appname success"

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

乐观锁更新 + 分布式限流

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

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

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

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

因为 Service 是两个应用：

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

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

①distributed-redis-tool ⬆v1.0.3

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

②API 更新

修改之后的 API 如下：

@Configuration public class RedisLimitConfig {      private Logger logger = LoggerFactory.getLogger(RedisLimitConfig.class);      @Value("${redis.limit}")     private int limit;       @Autowired     private JedisConnectionFactory jedisConnectionFactory;      @Bean     public RedisLimit build() {         RedisLimit redisLimit = new RedisLimit.Builder(jedisConnectionFactory, RedisToolsConstant.SINGLE)                 .limit(limit)                 .build();          return redisLimit;     } }

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

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

③限流实现

既然 API 更新了，实现自然也要修改：

/**   * limit traffic   * @return if true   */  public boolean limit() {       //get connection      Object connection = getConnection();       Object result = limitRequest(connection);       if (FAIL_CODE != (Long) result) {          return true;      } else {          return false;      }  }   private Object limitRequest(Object connection) {      Object result = null;      String key = String.valueOf(System.currentTimeMillis() / 1000);      if (connection instanceof Jedis){          result = ((Jedis)connection).eval(script, Collections.singletonList(key), Collections.singletonList(String.valueOf(limit)));          ((Jedis) connection).close();      }else {          result = ((JedisCluster) connection).eval(script, Collections.singletonList(key), Collections.singletonList(String.valueOf(limit)));          try {              ((JedisCluster) connection).close();          } catch (IOException e) {              logger.error("IOException",e);          }      }      return result;  }   private Object getConnection() {      Object connection ;      if (type == RedisToolsConstant.SINGLE){          RedisConnection redisConnection = jedisConnectionFactory.getConnection();          connection = redisConnection.getNativeConnection();      }else {          RedisClusterConnection clusterConnection = jedisConnectionFactory.getClusterConnection();          connection = clusterConnection.getNativeConnection() ;      }      return connection;  }

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

实际使用如下，Web 端：

/**      * 乐观锁更新库存 限流      * @param sid      * @return      */     @SpringControllerLimit(errorCode = 200)     @RequestMapping("/createOptimisticLimitOrder/{sid}")     @ResponseBody     public String createOptimisticLimitOrder(@PathVariable int sid) {         logger.info("sid=[{}]", sid);         int id = 0;         try {             id = orderService.createOptimisticOrder(sid);         } catch (Exception e) {             logger.error("Exception",e);         }         return String.valueOf(id);     }

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

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

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

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

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

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

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

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

• 这次主要改造的是 Service 层：

• 每次查询库存时走 Redis。

• 扣库存时更新 Redis。

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

主要代码如下：

@Override   public int createOptimisticOrderUseRedis(int sid) throws Exception {       //检验库存，从 Redis 获取       Stock stock = checkStockByRedis(sid);        //乐观锁更新库存 以及更新 Redis       saleStockOptimisticByRedis(stock);        //创建订单       int id = createOrder(stock);       return id ;   }     private Stock checkStockByRedis(int sid) throws Exception {       Integer count = Integer.parseInt(redisTemplate.opsForValue().get(RedisKeysConstant.STOCK_COUNT + sid));       Integer sale = Integer.parseInt(redisTemplate.opsForValue().get(RedisKeysConstant.STOCK_SALE + sid));       if (count.equals(sale)){           throw new RuntimeException("库存不足 Redis currentCount=" + sale);       }       Integer version = Integer.parseInt(redisTemplate.opsForValue().get(RedisKeysConstant.STOCK_VERSION + sid));       Stock stock = new Stock() ;       stock.setId(sid);       stock.setCount(count);       stock.setSale(sale);       stock.setVersion(version);        return stock;   }         /**    * 乐观锁更新数据库 还要更新 Redis    * @param stock    */   private void saleStockOptimisticByRedis(Stock stock) {       int count = stockService.updateStockByOptimistic(stock);       if (count == 0){           throw new RuntimeException("并发更新库存失败") ;       }       //自增       redisTemplate.opsForValue().increment(RedisKeysConstant.STOCK_SALE + stock.getId(),1) ;       redisTemplate.opsForValue().increment(RedisKeysConstant.STOCK_VERSION + stock.getId(),1) ;   }

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

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

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

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

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

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

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

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

以上がJava を使用して効率的なフラッシュ セール システムを実装するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。