這篇部落格是筆者學習慕課網若魚老師的《Java秒殺系統方案優化 高效能高併發實戰》課程的學習筆記。若魚老師授課循循善誘，講解由淺入深，歡迎大家支援。

本文記錄課程中的注意點，方便以後code review。此外，本文將注意點相關的優質講解連結在了一起，方便初學者系統學習。

> 本文並非單純介紹秒殺系統特有的技術點，不適合高手。進階學習的話，極客時間有個不錯的小專欄——如何設計一個秒殺系統，阿里高階技術專家講解秒殺系統的設計要點，那個課程挺乾貨的。

設計秒殺系統的技術要點

1. 登入的密碼傳輸：

使用者的資料庫表設計，需要增加一欄位儲存密碼的Salt值

兩次MD5操作(敏感資料一定要使用https協議傳輸

)：

• 客戶端：將明文password和客戶端硬編碼的Salt值進行拼接，然後進行MD5操作。

> 不用鹽的話，MD5字串有可能會被彩虹表或者社工庫破解

• 服務端：將客戶端傳過來的MD5字串和資料庫使用者對應的Salt欄位進行拼接。然後進行MD5操作。

> 這次加鹽MD5，可以有效防止內部員工洩露或者資料庫被拖庫後，明文密碼洩露

2. 自定義JSR303的校驗器

可以參照javax.validation.constraints.NotNull註解，自定義自己的校驗器，將校驗程式碼與業務程式碼分離。不過由於校驗失敗會輸出BindException異常，所以最好配合全域性捕獲異常進行友好的輸出。

> 自定義校驗器很簡單，只需要定義一個註解和對應的校驗類

3. 自定義全域性異常捕獲

使用@ControllerAdvice註解，定義全域性的異常捕獲，並從異常中獲取異常資訊解析出來，傳送給前端
可以自定義一個GlobalException異常，利用全域性異常捕獲，將所有伺服器處理異常集中處理。（Service層處理異常後不設定狀態碼，而是直接拋GlobalException全域性異常）

> 不返回狀態碼的好處是Controller層不需要再繁瑣的判斷Service層的返回值，程式碼更簡潔

4. 資料庫表設計

• 通過將訂單建立唯一索引來保證使用者只能建立一個秒殺訂單
• 商品金額最好以分為單位，比較安全
• 商品ID最好不要使用自增，會暴露商品總數等資訊。可以使用UUID，但範圍查詢時會有效能損耗。所以一般採用SnowFlake演算法生成ID

> 另外，自增ID的缺點也就是無法在多個表中，或者多個數據庫中保持ID主鍵唯一不重複，所以若是使用分散式資料庫以及資料合併的情況下時不能使用自增ID的。

5. 程式碼規範

• 更新欄位越多，產生的資料庫Binlog就越多。所以只更新資料庫部分欄位的時候，最好新建一個物件，只賦值要更新的欄位，然後呼叫mybatis的@Update，這樣不做全量更新可以提高效能
• 前端回包使用Result包裝類封裝，對報錯資訊使用CodeMsg包裝類封裝，保持程式碼風格統一
• Service只注入跟自己同名的dao，如果需要別的dao，請注入對應的Service

> Service的api相比dao會多一些防禦程式碼（例如，直接修改了別的模組dao資料，但快取未清理），更加安全

6. 事務

秒殺有兩個事務：

1. 減庫存->建立秒殺訂單
2. 建立秒殺訂單
   秒殺中涉及到上述兩個事務，為了保障資料安全，可以使用宣告式事務（Spring的@Transactional）

> PROPAGATION_REQUIRED是Spring預設的傳播機制，如果外層有事務，則當前事務加入到外層事務，一塊提交，一塊回滾。本工程的場景使用預設事務傳播機制即可

有關Spring事務傳播機制可以檢視這篇部落格

7. 壓測

• 在生產環境中，秒殺系統要獨立執行與其他業務系統，實現資源隔離，避免業務系統相互影響穩定性
• 請求入口可以使用nginx，LVS，F5等不同的負載均衡器
• Jmeter 隨機生成使用者資料，然後使用Jmeter模擬使用者壓測。壓測執行環境最好與被測伺服器環境隔離。

> 介面測試可以還使用Postman和ApacheBench

8. 頁面優化技術

• 頁面/URL快取。用於資料變化不頻繁的頁面或者熱點網頁。如果資料較多需要分頁的資料，類似商品詳情資料，一般可以考慮只快取前兩頁（根據訪問量作取捨）

> 快取方法：將渲染好的html檔案存放到Redis。在訪問Url時，首先檢測Redis是否有html快取。有快取的話則直接返回快取；沒有快取的話則渲染後存入Redis，並返回給前端。頁面快取過期時間具體根據業務場景判斷。

• 頁面區域性快取。熱點資料快取，當Ajax請求資訊更新，涉及的可能是需要儲存在資料庫的操作，例如表格資訊等時，可以採用Redis快取，方法同頁面快取一樣，定義好可以區分業務的Key即可

• 靜態資源優化

  • JS/CSS壓縮，減少流量（可通過升級HTTP2來解決）
  • 多個JS/CSS組合，減少連線數（例如：tengine）
  • CDN就近訪問

> 如果需要採用JS/CSS壓縮或者減少連線數等方法，可以使用HTTP2來提升效能

• 物件快取。例如使用Redis儲存Session物件。物件快取涉及到一個雙寫一致性問題，有關雙寫一致性問可以檢視這篇部落格

9. 秒殺的邏輯優化

順序：

1. 系統初始化，把商品庫存數量載入到Redis
2. 收到請求，Redis原子操作預減庫存，庫存不足，直接返回，否則進入3
3. 請求入隊，立即返回前端“排隊中”
4. 請求出隊，生成訂單，減少庫存（服務端）
5. 客戶端輪詢，是否秒殺成功（客戶端）和4同步，得到結果重新整理結果顯示

優化：

1. 在第二步預減庫存時，可以在記憶體里加一個map，ID為商品ID，value為是否有庫存，這樣當庫存沒有之後，直接通過記憶體中的值判斷是否還有庫存，減少對Redis的訪問。
2. 購買請求加入訊息佇列，非同步下單（前端顯示排隊中），增強使用者體驗
3. 前端要儘量減少重複請求

10. 安全優化

10.1 秒殺介面地址隱藏

1. 每次點選秒殺按鈕，先從伺服器獲取動態拼接而成的秒殺地址。
2. Redis以快取使用者ID和商品ID為Key，秒殺地址為Value快取秒殺地址
3. 使用者請求秒殺商品的時候，要帶上秒殺地址進行校驗

10.2 數學公式驗證碼

1. 防止惡意指令碼搶購
2. 使請求時間分散

10.3 介面限流防刷

使用計數法，在攔截器做限制請求頻率。利用Redis快取的有效期（以使用者ID拼接Url作為key，以訪問次數為value），指定快取有效期為1秒，訪問介面每次將value+1，到達閾值跳轉全域性異常。

> 優化：使用攔截器+自定義註解，減少對業務程式碼的侵入。有關攔截器可以檢視這篇部落格 > 另外對於介面限流也可以考慮使用令牌桶，控制對mysql的訪問。

相關推薦