這篇博客是筆者學習慕課網若魚老師的《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. 事務
秒殺有兩個事務：

減庫存->創建秒殺訂單
創建秒殺訂單
秒殺中涉及到上述兩個事務，其中后邊，為了保障數據安全，要使用事務（Spring的@Transactional）
PROPAGATION_REQUIRED是Spring默認的傳播機制，如果外層有事務，則當前事務加入到外層事務，一塊提交，一塊回滾。本工程的場景使用默認事務傳播機制即可

有關Spring事務傳播機制可以查看這篇博客

7. 壓測
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. 秒殺的邏輯優化
順序：

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

在第二步預減庫存時，可以在內存里加一個map，ID為商品ID，value為是否有庫存，這樣當庫存沒有之后，直接通過內存中的值判斷是否還有庫存，減少對Redis的訪問。
購買請求加入消息隊列，異步下單（前端顯示排隊中），增強用戶體驗
10. 安全優化
10.1 秒殺接口地址隱藏
每次點擊秒殺按鈕，先從服務器獲取動態拼接而成的秒殺地址。
Redis以緩存用戶ID和商品ID為Key，秒殺地址為Value緩存秒殺地址
用戶請求秒殺商品的時候，要帶上秒殺地址進行校驗
10.2 數學公式驗證碼
防止惡意腳本搶購
使請求時間分散
10.3 接口限流防刷
使用計數法，在攔截器做限制請求頻率。利用Redis緩存的有效期（以用戶ID拼接Url作為key，以訪問次數為value），指定緩存有效期為1秒，訪問接口每次將value+1，到達閾值跳轉全局異常。

優化：使用攔截器+自定義注解，減少對業務代碼的侵入

有關攔截器可以查看這篇博客
---------------------?
作者：沒事兒搗搗亂?
來源：CSDN?
原文：https://blog.csdn.net/y277an/article/details/91469669?
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！

總結

以上是生活随笔為你收集整理的Java秒杀系统优化的工程要点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。