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

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等架構進行分析

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

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

個人博客即將搬運同步至騰訊雲+社區，邀請你們一同入駐：https://cloud.tencent.com/developer/support-plan