本次采用循序漸進的方式逐步提高性能達到并發(fā)秒殺的效果，文章較長，請準備好瓜子板凳!

[[269065]] 

圖片來自包圖網(wǎng)

之前在 Java-Interview 中提到過秒殺架構的設計，這次基于其中的理論簡單實現(xiàn)了一下。

本文所有涉及的代碼：

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

首先來看看最終架構圖：

 

先簡單根據(jù)這個圖談下請求的流轉(zhuǎn)，因為后面不管怎么改進，這些都是不變的：

• 前端請求進入 Web 層，對應的代碼就是 Controller。
• 之后將真正的庫存校驗、下單等請求發(fā)往 Service 層，其中 RPC 調(diào)用依然采用的 Dubbo，只是更新為***版本。
• Service 層再對數(shù)據(jù)進行落地，下單完成。

***制

拋開秒殺這個場景來說，正常的一個下單流程可以簡單分為以下幾步：

• 校驗庫存
• 扣庫存
• 創(chuàng)建訂單
• 支付

基于上文的架構，我們有了以下實現(xiàn)，先看看實際項目的結構：

 

還是和以前一樣：

• 提供出一個 API 用于 Service 層實現(xiàn)，以及 Web 層消費。
• Web 層簡單來說就是一個 Spring MVC。
• Service 層則是真正的數(shù)據(jù)落地。
• SSM-SECONDS-KILL-ORDER-CONSUMER 則是后文會提到的 Kafka 消費。

數(shù)據(jù)庫也是只有簡單的兩張表模擬下單：

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 '創(chuàng)建時間', 
  PRIMARY KEY (`id`) 
) ENGINE=InnoDB AUTO_INCREMENT=55 DEFAULT CHARSET=utf8; 

Web 層 Controller 實現(xiàn)：

@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 作為一個消費者調(diào)用看 OrderService 提供出來的 Dubbo 服務。

Service 層， OrderService 實現(xiàn)，首先是對 API 的實現(xiàn)(會在 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); 
    } 
} 

這里只是簡單調(diào)用了 DBOrderService 中的實現(xiàn)，DBOrderService 才是真正的數(shù)據(jù)落地，也就是寫數(shù)據(jù)庫了。

DBOrderService 實現(xiàn)：

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); 
 
        //創(chuàng)建訂單 
        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 條庫存。手動調(diào)用下 createWrongOrder/1 接口發(fā)現(xiàn)：

 

庫存表

 

訂單表

一切看起來都沒有問題，數(shù)據(jù)也正常。但是當用 JMeter 并發(fā)測試時：

 

測試配置是：300 個線程并發(fā)。測試兩輪來看看數(shù)據(jù)庫中的結果：

 

請求都響應成功，庫存確實也扣完了，但是訂單卻生成了 124 條記錄。這顯然是典型的超賣現(xiàn)象。

其實現(xiàn)在再去手動調(diào)用接口會返回庫存不足，但為時晚矣。

樂觀鎖更新

怎么來避免上述的現(xiàn)象呢?最簡單的做法自然是樂觀鎖了，來看看具體實現(xiàn)：

其實其他的都沒怎么改，主要是 Service 層：

@Override 
   public int createOptimisticOrder(int sid) throws Exception { 
 
       //校驗庫存 
       Stock stock = checkStock(sid); 
 
       //樂觀鎖更新庫存 
       saleStockOptimistic(stock); 
 
       //創(chuàng)建訂單 
       int id = createOrder(stock); 
 
       return id; 
   } 
 
   private void saleStockOptimistic(Stock stock) { 
       int count = stockService.updateStockByOptimistic(stock); 
       if (count == 0){ 
           throw new RuntimeException("并發(fā)更新庫存失敗") ; 
       } 
   } 

對應的 XML：

<update id="updateByOptimistic" parameterType="com.crossoverJie.seconds.kill.pojo.Stock"> 
       update stock 
       <set> 
           sale = sale + 1, 
           version = version + 1, 
       </set> 
 
       WHERE id = #{id,jdbcType=INTEGER} 
       AND version = #{version,jdbcType=INTEGER} 
 
   </update> 

同樣的測試條件，我們再進行上面的測試 /createOptimisticOrder/1：

 

這次發(fā)現(xiàn)無論是庫存訂單都是 OK 的。

查看日志發(fā)現(xiàn)：

 

很多并發(fā)請求會響應錯誤，這就達到了效果。

提高吞吐量

為了進一步提高秒殺時的吞吐量以及響應效率，這里的 Web 和 Service 都進行了橫向擴展：

• Web 利用 Nginx 進行負載。
• Service 也是多臺應用。

 

再用 JMeter 測試時可以直觀的看到效果。

由于我是在阿里云的一臺小水管服務器進行測試的，加上配置不高、應用都在同一臺，所以并沒有完全體現(xiàn)出性能上的優(yōu)勢( Nginx 做負載轉(zhuǎn)發(fā)時候也會增加額外的網(wǎng)絡消耗)。

Shell 腳本實現(xiàn)簡單的 CI

由于應用多臺部署之后，手動發(fā)版測試的痛苦相信經(jīng)歷過的都有體會。

這次并沒有精力去搭建完整的 CICD，只是寫了一個簡單的腳本實現(xiàn)了自動化部署，希望給這方面沒有經(jīng)驗的同學帶來一點啟發(fā)。

構建 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" 

之后每當我有更新，只需要執(zhí)行這兩個腳本就可以幫我自動構建。都是最基礎的 Linux 命令，相信大家都看得明白。

樂觀鎖更新 + 分布式限流

上文的結果看似沒有問題，其實還差得遠呢。這里只是模擬了 300 個并發(fā)沒有問題，但是當請求達到了 3000，3W，300W 呢?

雖說可以橫向擴展支撐更多的請求，但是能不能利用最少的資源解決問題呢?

仔細分析下會發(fā)現(xiàn)：假設我的商品一共只有 10 個庫存，那么無論你多少人來買其實最終也最多只有 10 人可以下單成功。所以其中會有 99% 的請求都是無效的。

大家都知道：大多數(shù)應用數(shù)據(jù)庫都是壓倒駱駝的***一根稻草。通過 Druid 的監(jiān)控來看看之前請求數(shù)據(jù)庫的情況：

因為 Service 是兩個應用：

 

數(shù)據(jù)庫也有 20 多個連接。怎么樣來優(yōu)化呢?其實很容易想到的就是分布式限流。

我們將并發(fā)控制在一個可控的范圍之內(nèi)，然后快速失敗這樣就能***程度的保護系統(tǒng)。

①distributed-redis-tool ⬆v1.0.3

為此還對 https://github.com/crossoverJie/distributed-redis-tool 進行了小小的升級。

因為加上該組件之后所有的請求都會經(jīng)過 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 還是有一定的壓力)。

③限流實現(xiàn)

既然 API 更新了，實現(xiàn)自然也要修改：

/** 
  * 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 端就沒什么更新了，依然是采用的樂觀鎖更新數(shù)據(jù)庫。

再壓測看下效果 /createOptimisticLimitOrderByRedis/1：

首先是看結果沒有問題，再看數(shù)據(jù)庫連接以及并發(fā)請求數(shù)都有明顯的下降。

樂觀鎖更新+分布式限流+Redis 緩存

仔細觀察 Druid 監(jiān)控數(shù)據(jù)發(fā)現(xiàn)這個 SQL 被多次查詢：

其實這是實時查詢庫存的 SQL，主要是為了在每次下單之前判斷是否還有庫存。

這也是個優(yōu)化點。這種數(shù)據(jù)我們完全可以放在內(nèi)存中，效率比在數(shù)據(jù)庫要高很多。

由于我們的應用是分布式的，所以堆內(nèi)緩存顯然不合適，Redis 就非常適合。

• 這次主要改造的是 Service 層：
• 每次查詢庫存時走 Redis。
• 扣庫存時更新 Redis。

需要提前將庫存信息寫入 Redis。(手動或者程序自動都可以)

主要代碼如下：

@Override 
  public int createOptimisticOrderUseRedis(int sid) throws Exception { 
      //檢驗庫存，從 Redis 獲取 
      Stock stock = checkStockByRedis(sid); 
 
      //樂觀鎖更新庫存 以及更新 Redis 
      saleStockOptimisticByRedis(stock); 
 
      //創(chuàng)建訂單 
      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; 
  }     
 
 
  /** 
   * 樂觀鎖更新數(shù)據(jù)庫 還要更新 Redis 
   * @param stock 
   */ 
  private void saleStockOptimisticByRedis(Stock stock) { 
      int count = stockService.updateStockByOptimistic(stock); 
      if (count == 0){ 
          throw new RuntimeException("并發(fā)更新庫存失敗") ; 
      } 
      //自增 
      redisTemplate.opsForValue().increment(RedisKeysConstant.STOCK_SALE + stock.getId(),1) ; 
      redisTemplate.opsForValue().increment(RedisKeysConstant.STOCK_VERSION + stock.getId(),1) ; 
  }     

壓測看看實際效果 /createOptimisticLimitOrderByRedis/1：

***發(fā)現(xiàn)數(shù)據(jù)沒問題，數(shù)據(jù)庫的請求與并發(fā)也都下來了。

樂觀鎖更新+分布式限流+Redis 緩存+Kafka 異步

***的優(yōu)化還是想如何來再次提高吞吐量以及性能的。我們上文所有例子其實都是同步請求，完全可以利用同步轉(zhuǎn)異步來提高性能啊。

這里我們將寫訂單以及更新庫存的操作進行異步化，利用 Kafka 來進行解耦和隊列的作用。

每當一個請求通過了限流到達了 Service 層通過了庫存校驗之后就將訂單信息發(fā)給 Kafka ，這樣一個請求就可以直接返回了。

消費程序再對數(shù)據(jù)進行入庫落地。因為異步了，所以最終需要采取回調(diào)或者是其他提醒的方式提醒用戶購買完成。

這里代碼較多就不貼了，消費程序其實就是把之前的 Service 層的邏輯重寫了一遍，不過采用的是 Spring Boot。

總結

經(jīng)過上面的一頓優(yōu)化總結起來無非就是以下幾點：

• 盡量將請求攔截在上游。
• 還可以根據(jù) UID 進行限流。
• ***程度的減少請求落到 DB。
• 多利用緩存。
• 同步操作異步化。
• Fail Fast，盡早失敗，保護應用。

碼字不易，這應該是我寫過字數(shù)最多的了，想想當年高中 800 字的作文都憋不出來😂，可想而知是有多難得了。

以上內(nèi)容歡迎討論，感興趣的朋友可以看下:

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