04 整合IDEA+Maven+SSM框架的高併發的商品秒殺項目之高併發優化

Github： "https://github.com/nnngu" 項目源代碼： "https://github.com/nnngu/nguSeckill" 關於併發併發性上不去是因為當多個線程同時訪問一行數據時，產生了事務，因此產生寫鎖，當一個獲取了事務的線程把鎖釋放，另一個排隊線程才能拿到寫 ...

Github：https://github.com/nnngu
項目源代碼：https://github.com/nnngu/nguSeckill

關於併發

併發性上不去是因為當多個線程同時訪問一行數據時，產生了事務，因此產生寫鎖，當一個獲取了事務的線程把鎖釋放，另一個排隊線程才能拿到寫鎖，QPS(Query Per Second每秒查詢率)和事務執行的時間有密切關係，事務執行時間越短，併發性越高，這也是要將費時的 IO 操作移出事務的原因。

項目中的高併發發生在哪？

下圖中，紅色的部分就表示會發生高併發的地方，綠色部分表示對於高併發沒有影響。

為什麼要單獨獲取系統時間？

這是為了我們的秒殺系統的優化做鋪墊。比如在秒殺還未開始的時候，用戶大量刷新秒殺商品詳情頁面是很正常的情況，這時候秒殺還未開始，大量的請求發送到伺服器會造成不必要的負擔。

我們將這個詳情頁放置到CDN中，這樣用戶在訪問該頁面時就不需要訪問我們的伺服器了，起到了降低伺服器壓力的作用。而CDN中存儲的是靜態化的詳情頁和一些靜態資源（css，js等），這樣我們就拿不到系統的時間來進行秒殺時段的控制，所以我們需要單獨設計一個請求來獲取我們伺服器的系統時間。

CDN（Content Delivery Network）的理解

獲取系統時間不需要優化

因為Java訪問一次記憶體（Cacheline）大約10ns，1s=10億ns，也就是如果不考慮GC，這個操作1s可以做1億次。

秒殺地址介面分析

無法使用CDN緩存，因為CDN適合請求對應的資源不變化的，比如靜態資源、JavaScript；秒殺地址返回的數據是變化的，不適合放在CDN緩存；
適合服務端緩存：Redis等，1秒鐘可以承受10萬QPS。多個Redis組成集群，可以到100萬個QPS。所以後端緩存可以用業務系統控制。

秒殺地址介面優化

秒殺操作優化分析

無法使用cdn緩存
後端緩存困難：庫存問題
一行數據競爭：熱門商品

大部分寫的操作和核心操作無法使用CDN，也不可能在緩存中減庫存。你在Redis中減庫存，那麼用戶也可能通過緩存來減庫存，這樣庫存會不一致，所以要通過mysql的事務來保證一致性。

比如一個熱門商品所有人都在搶，那麼會在同一時間對數據表中的一行數據進行大量的update set操作。

行級鎖在commit之後才釋放，所以優化方向是減少行級鎖的持有時間。

延遲問題很關鍵

同城機房網路（0.5ms~2ms），最高併發性是1000qps。
update後JVM -GC(垃圾回收機制)大約50ms，最高併發性是20qps。併發性越高，GC就越可能發生，雖然不一定每次都會發生，但一定會發生。
異地機房，比如北京到上海之間的網路延遲，經過計算大概13~20ms。

如何判斷update更新庫存成功？

有兩個條件：

update自身沒報錯；
客戶端確認update影響記錄數

優化思路：把客戶端邏輯放到MySQL服務端，避免網路延遲和GC影響

如何把客戶端邏輯放到MySQL服務端

有兩種方案：

定製SQL方案，在每次update後都會自動提交，但需要修改MySQL源碼，成本很高，不是大公司（BAT等）一般不會使用這種方法。
使用存儲過程：整個事務在MySQL端完成，用存儲過程寫業務邏輯，服務端負責調用。

接下來先分析第一種方案

根據上圖的成本分析，我們的秒殺系統採用第二種方案，即使用存儲過程。

優化總結

前端控制。暴露介面，按鈕防重覆（點擊一次按鈕後就變成灰色，禁止重覆點擊按鈕）
動靜態數據分離。CDN緩存，後端緩存
事務競爭優化。減少事務行級鎖的持有時間

下載安裝Redis

Redis是一個開源的、支持網路、可基於記憶體亦可持久化的日誌型、Key-Value資料庫

下載安裝Redis的步驟，搜索引擎能找到相關的資料，本文不做展開。

下載安裝完Redis之後就可以繼續進行操作。

使用Java操作Redis

Java操作Redis使用的是jedis包。

在pom.xml添加jedis的依賴，如下圖：

添加protostuff-core 以及protostuff-runtime 序列化jar包，如下圖：

序列化是處理對象流的機制，就是將對象的內容進行流化，可以對流化後的對象進行讀寫操作，也可以將流化後的對象在網路間傳輸。反序列化就是將流化後的對象重新轉化成原來的對象。

在Java中內置了序列化機制，通過implements Serializable來標識一個對象實現了序列化介面，不過其性能並不高。

建立操作Redis的dao類

原本查詢秒殺商品時是通過主鍵直接去資料庫查詢的，選擇將數據緩存在Redis，在查詢秒殺商品時先去Redis緩存中查詢，以此降低資料庫的壓力。如果在緩存中查詢不到數據再去資料庫中查詢，再將查詢到的數據放入Redis緩存中，這樣下次就可以直接去緩存中直接查詢到。

添加RedisDao.java文件，位於下圖所示的位置：

RedisDao.java文件裡面的代碼請參照項目的源代碼。

在applicationContext-dao.xml中註入redisDao

在applicationContext-dao.xml中添加下圖所示的內容：

改造exportSeckillUrl方法：

修改SeckillServiceImpl.java文件中的exportSeckillUrl方法：

/**
     * 在秒殺開啟時輸出秒殺介面的地址，否則輸出系統時間跟秒殺地址
     *
     * @param seckillId 秒殺商品Id
     * @return 根據對應的狀態返回對應的狀態實體
     */
    @Override
    public Exposer exportSeckillUrl(long seckillId) {
        
        Seckill seckill = redisDao.getSeckill(seckillId);
        if (seckill == null) {
            // 訪問資料庫讀取數據
            seckill = seckillMapper.queryById(seckillId);
            if (seckill == null) {
                return new Exposer(false, seckillId);
            } else {
                // 放入redis
                redisDao.putSeckill(seckill);
            }
        }

        // 判斷是否還沒到秒殺時間或者是過了秒殺時間
        Date startTime = seckill.getStartTime();
        Date endTime = seckill.getEndTime();
        Date nowTime = new Date();
        // 開始時間大於現在的時候說明沒有開始秒殺活動；秒殺活動結束時間小於現在的時間說明秒殺已經結束了
        if (nowTime.getTime() > startTime.getTime() && nowTime.getTime() < endTime.getTime()) {
            //秒殺開啟,返回秒殺商品的id,用給介面加密的md5
            String md5 = getMd5(seckillId);
            return new Exposer(true, md5, seckillId);
        }
        return new Exposer(false, seckillId, nowTime.getTime(), startTime.getTime(), endTime.getTime());
        
    }

簡單的優化

以前的實現流程：

用戶的秒殺操作分為兩步：減庫存、插入購買明細，我們在這裡進行簡單的優化，就是將原本先update（減庫存）再進行insert（插入購買明細）的步驟改成：先insert再update。

為什麼要先insert再update

首先是在更新操作的時候給行加鎖，插入並不會加鎖，如果更新操作在前，那麼就需要執行完更新和插入以後事務提交或回滾才釋放鎖。而如果插入在前，更新在後，那麼只有在更新時才會加行鎖，之後在更新完以後事務提交或回滾釋放鎖。
在這裡，插入是可以並行的，而更新由於會加行級鎖是串列的。
也就是說是如果更新在前，加鎖和釋放鎖之間兩次的網路延遲和GC，如果更新在後，則加鎖和釋放鎖之間只有一次的網路延遲和GC，也就是減少的持有鎖的時間。
這裡先insert並不是忽略了庫存不足的情況，而是因為insert和update是在同一個事務里，光是insert並不一定會提交，只有在update成功才會提交，所以並不會造成過量插入秒殺成功記錄。

去代碼里改造執行秒殺的executeSeckill()方法，優化性能。

深度優化（使用存儲過程）

前邊通過調整insert和update的執行順序來實現簡單的優化，但依然存在著Java客戶端和伺服器通信時的網路延遲和GC影響，我們可以將執行秒殺操作時的insert和update放到MySQL服務端的存儲過程里，而Java客戶端直接調用這個存儲過程，這樣就可以避免網路延遲和可能發生的GC影響。另外，由於我們使用了存儲過程，也就用不到Spring的事務管理了，因為在存儲過程里我們會直接啟用一個事務。

去MySQL的控制台執行儲存過程`procedure.sql`裡面的代碼

去MySQL的控制台執行儲存過程procedure.sql裡面的代碼。

procedure.sql文件位於項目的sql目錄下。

註意點：在存儲過程中，row_count() 函數用來返回上一條 sql（delete, insert, update）影響的行數。

根據row_count() 的返回值，可以進行接下來的流程判斷：

0：未修改數據；

>0：表示修改的行數；

<0：表示SQL錯誤或未執行修改SQL

修改源碼以調用存儲過程

在SeckillMapper.java介面中聲明killByProcedure()方法

    /**
     * 使用儲存過程執行秒殺
     *
     * @param paramMap
     */
    void killByProcedure(Map<String, Object> paramMap);

然後在SeckillMapper.xml中寫sql語句，具體代碼請參照項目的源代碼。

接著在SeckillService.java介面中聲明 executeSeckillProcedure()方法

在pom.xml中添加commons-collections的依賴，如下圖：

然後在SeckillServiceImpl.java中實現executeSeckillProcedure()方法。

在SeckillServiceImplTest.java中編寫測試方法executeSeckillProcedureTest()。

測試結果：

修改SeckillController.java中的execute()方法，把一開始調用普通方法的改成調用儲存過程的方法。

存儲過程優化總結

存儲過程優化：事務行級鎖持有的時間
不要過度依賴存儲過程
簡單的邏輯依賴存儲過程
QPS:一個秒殺單6000/qps

經過簡單優化和深度優化之後，本項目大概能達到一個秒殺單6000qps，這個數據對於一個秒殺商品來說其實已經挺ok了，註意這裡是指同一個秒殺商品6000qps，如果是不同商品不存在行級鎖競爭的問題。

系統部署架構

CDN：放置一些靜態化資源，或者可以將動態數據分離。一些js依賴直接用公網的CDN，自己開發的一些頁面也做靜態化處理推送到CDN。用戶在CDN獲取到的數據不需要再訪問我們的伺服器，動靜態分離可以降低伺服器請求量。比如秒殺詳情頁，做成HTML放在CDN上，動態數據可以通過ajax請求後臺獲取。

Nginx：作為http伺服器，響應客戶請求，為後端的servlet容器做反向代理，以達到負載均衡的效果。

Redis：用來做伺服器端的緩存，通過Jedis提供的API來達到熱點數據的一個快速存取的過程，減少資料庫的請求量。

MySQL：保證秒殺過程的數據一致性與完整性。

智能DNS解析+智能CDN加速+Nginx併發+Redis緩存+MySQL分庫分表，如下圖：

大型系統部署架構，邏輯集群就是開發的部分。

Nginx做負載均衡
分庫分表：在秒殺系統中，一般通過關鍵的秒殺商品id取模進行分庫分表，以512為一張表，1024為一張表。分庫分表一般採用開源架構，如阿裡巴巴的tddl分庫分表框架。
統計分析：一般使用hadoop等架構進行分析

在這樣一個架構中，可能參與的角色如下：

到此，該項目已經全部完成，感謝閱讀本文。