基于Spring Cloud的電商平臺秒殺系統設計

尹 玲

（廣州科技職業技術大學 廣東 廣州 510550）

0 引言

在電商平臺上，商品的超低價格引起人們對商品的購買欲望，這些超低價格的商品限量銷售使得大量購物者瘋狂搶購，甚至有黃牛黨采用專業的工具搶購。商品在進行秒殺時成百萬上千萬的請求瞬間涌入，數據庫和服務端資源有限，如果架構方面沒有合理的設計，系統必然會崩潰。秒殺系統的業務流程簡單，即用戶下單成功核減庫存，但秒殺系統瞬時并發量極大，特價商品的數量限制導致秒殺成功的請求數量很少。如何解決秒殺過程中的瞬時高并發，防止超賣是本系統重點研究的問題。

1 系統關鍵技術介紹

1.1 Spring Cloud 架構及微服務組件

微服務是可以獨立部署、水平擴展、獨立訪問（或者有獨立的數據庫）的服務單元[1]，Spring Cloud 是一個基于Spring Boot 實現的云應用開發工具，是一套微服務治理的框架[2]。秒殺系統采用Spring Cloud 分布式微服務集群架構，使用Spring Cloud 管理商品服務，秒殺服務、訂單服務、庫存服務等這些微服務，必然離不開Spring Cloud 的相關組件。其主要組件如下：

Spring Cloud Gateway：網關對請求進行路由、過濾和限流。

Netflix Eureka：注冊中心存儲所有服務信息。

Netflix Hystrix：熔斷器通過熔斷機制控制服務和第三方庫的節點，從而對延遲和故障提供更強大的容錯能力[3]。

RestTemplate：Spring 提供、用于訪問的Rest 服務客戶端，主要用于微服務間的調用。

1.2 負載均衡Nginx

負載均衡是將任務分攤到多個處理單元執行，在服務器集群中，Nginx 服務器起到一個代理服務器的角色（即反向代理）[4]，避免其中一個服務器壓力過大，將來自用戶的請求轉發給不同的服務器。同時，Nginx 服務器還可以做靜態資源代理。負載均衡Nginx 保證所有后端服務器的性能充分發揮，從而保持服務器集群的整體性能最優。

1.3 緩存Redis

緩存是指將頻繁訪問的數據放在內存中，從而加快用戶訪問速度的技術。Redis 技術是一種基于內存的數據庫，處理請求能力極高，正常情況下對讀請求處理速度為90 000/s，寫請求處理速度為50 000/s，并且提供一定的數據持久化的功能，緩存Redis 的使用可以提高數據的查詢性能和效率。

1.4 消息中間件RocketMQ

RocketMQ 是阿里巴巴開源的分布式消息中間件，消息隊列基于生產者－消費者設計模式，按具體場景與規則，針對上層請求生產者往隊列的末尾添加數據，多個消費者從隊列里面依次讀取數據然后自行處理，消息隊列具有異步、解耦、削峰的特點[5]。

1.5 數據庫MySQL

MySQL 為一款免費的通用數據庫，通過不斷的迭代升級，現在各項讀寫性能均達到主流水平之上，而且也支持主從、集群模式。

2 系統實現

2.1 系統架構圖

秒殺系統架構圖如圖1所示。

圖1 系統架構圖

2.2 前端層面實現

秒殺商品的頁面信息很多都不會改變，為減少秒殺時服務器壓力，秒殺商品的圖片和文字元素都需要盡可能靜態化。在服務端通過Thymeleaf 模板語言生成靜態頁面，用戶可以通過Nginx訪問頁面，降低對Java服務端的壓力。

前端層面除了生成靜態頁面減少服務器壓力，還可以進行限流操作，盡可能提升秒殺效率。針對普通購物者，當購物者點擊購買按鈕一次后，按鈕置灰，防止用戶重復提交請求。針對黃牛，防止黃牛使用抓包工具和定時腳本自動發請求，需要在后端Controller 層進行處理，即對同一個用戶的請求進行校驗，限制同一個用戶短時間內的大量請求，去除重復請求。如果想簡化操作還可以花錢讓市面上的專業風控團隊來處理。風控系統會根據一系列規則，判斷當前用戶是否為刷單賬號、僵尸賬號等，對那些不符合平臺要求的直接攔截過濾掉。

2.3 Nginx 層和網關層限流

在前端層面盡管已經攔截了惡意請求，減少了部分流量，但是秒殺的總流量還是很多的，研究人員還需要做負載均衡。負載均衡理論上講就是集群，單臺機器的性能有上限，流量太大時扛不住。那研究人員可以多加幾臺機器，提升物理硬件方面的能力。在Nginx 層下面的Node 節點，可以將請求按照輪詢、權重等方式，均勻地分布在每一臺服務器上面。例如1 000 個請求過來，研究人員有10 臺Node 節點服務，那么按照輪詢策略每個節點分擔100 個請求，可以極大地提升服務的響應速度和健壯性。在真實的秒殺場景中，Nginx 層還會加一級4 層負載，在硬件層面的F5或者軟件層面的LVS，對Nginx服務的IP做負載均衡。

Nginx 層除了做反向代理，還可以做好限流控制。Nginx 層和網關層限流具體如圖2所示。

圖2 Nginx 層和網關層限流設計圖

應用級別限流：通過Nginx 配置屬性limit_req_zone和limit_req，來控制客戶端每個IP 地址限制為每秒一次請求。并且在網關層通過對用戶權限控制，只有用戶權限校驗通過，才給予令牌權限允許訪問秒殺接口服務。

接口級別的限流：一般秒殺系統允許用戶每秒/次的訪問量。具體是通過RedisSon（Redis+lua 客戶端）工具來實現，具體限流實現為用戶ID 為key，過期時間expire 屬性設置為1 秒。每次接口請求進來，先通過用戶ID 去查詢Redis，如果查詢不到則允許訪問接口，同時在Redis 中set 以用戶ID 為key 每秒/次的訪問量，來控制同一個用戶下次的訪問。

2.4 緩存Redis 層實現

在秒殺的過程中，對于成功進入后端的請求在訪問數據庫時，會先查詢數據庫商品庫存是否足夠，庫存足夠才會下單成功，進行寫數據庫操作。秒殺時有數十萬的請求進來同時查詢數據庫，由于數據庫讀寫屬于磁盤的輸入輸出，性能較低，數據庫的連接資源非常有限，此時數據庫可能會宕機。秒殺系統最大的瓶頸是對數據庫的讀寫，如果能夠把部分數據或業務邏輯轉移到內存緩存，效率會有極大的提升。所以在秒殺開始前，可以在后臺寫一個控制按鈕，點擊按鈕實現將數據提前寫入緩存Redis 中，讓請求過來的數據都在Redis 層處理計算。Redis 采用主從模式，Redis master（主服務）處理所有的寫請求，Redis slave（從服務）用于讀操作緩解系統的查庫壓力，再由Redis master 將數據同步到Redis slave 上。

另外為了防止超賣，研究人員需要加鎖來保證，讓請求從并行化切換為串行化處理。例如1 000 件商品，平均分成10 份商品庫，每份100 件，然后生成10 把鎖，每把鎖對應一份商品庫。代碼業務中誰拿到鎖，誰就可以產生交易，沒有鎖的請求則處于等待狀態。使用redis 分布式鎖來保護秒殺的數據庫操作如圖3所示。

圖3 使用redis 分布式鎖搶鎖示意圖

Redis 加鎖代碼示例（使用Redis+SpringAOP 的方式實現分布式鎖）

2.5 RocketMQ 消息隊列和MySQL 數據庫

系統使用RocketMQ 的削峰特性來更新下單信息到數據庫，預防因秒殺時大量訂單直接更新數據庫，導致數據庫服務宕機。RocketMQ消息隊列對訂單進行分組存儲管理，然后讓多個消費者來進行消費，消費成功后把訂單信息寫入數據庫。MySQL 數據庫用來做最終持久化，將最終的交易數據寫到硬盤。如圖4所示。

圖4 使用RocketMQ 消息隊列更新數據庫示意圖

3 測試數據

JMeter 是Apache 組織基于Java 開發的壓力測試工具，用于對軟件做壓力測試。JMeter 對秒殺系統的壓測結果如圖5所示。

圖5 JMeter 壓測結果圖

當前秒殺樣本數據50 000，從壓力測試接口來看，吞吐量為929/s，表示系統每秒可以處理完900 個以上的工作量，基本上可以達到秒殺系統的使用要求。

4 結論

本系統結合目前市面最為流行的開發技術Spring Cloud 架構，運用其相關組件完成了微服務電商平臺秒殺系統設計。該設計使用負載均衡Nginx 做反向代理和限流，使用緩存Redis 提高系統的響應速度和利用分布式鎖防止超賣，使用RocketMQ 消息隊列在高并發環境下進行削峰和服務間的解耦。當然，電商實現線上秒殺的方案不止一種，系統也可進一步優化。秒殺存在于大眾生活的方方面面，秒殺系統的研究及性能提升具有重要意義。