尹 玲

（廣州科技職業(yè)技術(shù)大學(xué) 廣東 廣州 510550）

0 引言

在電商平臺(tái)上，商品的超低價(jià)格引起人們對(duì)商品的購(gòu)買欲望，這些超低價(jià)格的商品限量銷售使得大量購(gòu)物者瘋狂搶購(gòu)，甚至有黃牛黨采用專業(yè)的工具搶購(gòu)。商品在進(jìn)行秒殺時(shí)成百萬(wàn)上千萬(wàn)的請(qǐng)求瞬間涌入，數(shù)據(jù)庫(kù)和服務(wù)端資源有限，如果架構(gòu)方面沒(méi)有合理的設(shè)計(jì)，系統(tǒng)必然會(huì)崩潰。秒殺系統(tǒng)的業(yè)務(wù)流程簡(jiǎn)單，即用戶下單成功核減庫(kù)存，但秒殺系統(tǒng)瞬時(shí)并發(fā)量極大，特價(jià)商品的數(shù)量限制導(dǎo)致秒殺成功的請(qǐng)求數(shù)量很少。如何解決秒殺過(guò)程中的瞬時(shí)高并發(fā)，防止超賣是本系統(tǒng)重點(diǎn)研究的問(wèn)題。

1 系統(tǒng)關(guān)鍵技術(shù)介紹

1.1 Spring Cloud 架構(gòu)及微服務(wù)組件

微服務(wù)是可以獨(dú)立部署、水平擴(kuò)展、獨(dú)立訪問(wèn)（或者有獨(dú)立的數(shù)據(jù)庫(kù)）的服務(wù)單元[1]，Spring Cloud 是一個(gè)基于Spring Boot 實(shí)現(xiàn)的云應(yīng)用開(kāi)發(fā)工具，是一套微服務(wù)治理的框架[2]。秒殺系統(tǒng)采用Spring Cloud 分布式微服務(wù)集群架構(gòu)，使用Spring Cloud 管理商品服務(wù)，秒殺服務(wù)、訂單服務(wù)、庫(kù)存服務(wù)等這些微服務(wù)，必然離不開(kāi)Spring Cloud 的相關(guān)組件。其主要組件如下：

Spring Cloud Gateway：網(wǎng)關(guān)對(duì)請(qǐng)求進(jìn)行路由、過(guò)濾和限流。

Netflix Eureka：注冊(cè)中心存儲(chǔ)所有服務(wù)信息。

Netflix Hystrix：熔斷器通過(guò)熔斷機(jī)制控制服務(wù)和第三方庫(kù)的節(jié)點(diǎn)，從而對(duì)延遲和故障提供更強(qiáng)大的容錯(cuò)能力[3]。

RestTemplate：Spring 提供、用于訪問(wèn)的Rest 服務(wù)客戶端，主要用于微服務(wù)間的調(diào)用。

1.2 負(fù)載均衡Nginx

負(fù)載均衡是將任務(wù)分?jǐn)偟蕉鄠€(gè)處理單元執(zhí)行，在服務(wù)器集群中，Nginx 服務(wù)器起到一個(gè)代理服務(wù)器的角色（即反向代理）[4]，避免其中一個(gè)服務(wù)器壓力過(guò)大，將來(lái)自用戶的請(qǐng)求轉(zhuǎn)發(fā)給不同的服務(wù)器。同時(shí)，Nginx 服務(wù)器還可以做靜態(tài)資源代理。負(fù)載均衡Nginx 保證所有后端服務(wù)器的性能充分發(fā)揮，從而保持服務(wù)器集群的整體性能最優(yōu)。

1.3 緩存Redis

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

1.4 消息中間件RocketMQ

RocketMQ 是阿里巴巴開(kāi)源的分布式消息中間件，消息隊(duì)列基于生產(chǎn)者－消費(fèi)者設(shè)計(jì)模式，按具體場(chǎng)景與規(guī)則，針對(duì)上層請(qǐng)求生產(chǎn)者往隊(duì)列的末尾添加數(shù)據(jù)，多個(gè)消費(fèi)者從隊(duì)列里面依次讀取數(shù)據(jù)然后自行處理，消息隊(duì)列具有異步、解耦、削峰的特點(diǎn)[5]。

1.5 數(shù)據(jù)庫(kù)MySQL

MySQL 為一款免費(fèi)的通用數(shù)據(jù)庫(kù)，通過(guò)不斷的迭代升級(jí)，現(xiàn)在各項(xiàng)讀寫性能均達(dá)到主流水平之上，而且也支持主從、集群模式。

2 系統(tǒng)實(shí)現(xiàn)

2.1 系統(tǒng)架構(gòu)圖

秒殺系統(tǒng)架構(gòu)圖如圖1所示。

圖1 系統(tǒng)架構(gòu)圖

2.2 前端層面實(shí)現(xiàn)

秒殺商品的頁(yè)面信息很多都不會(huì)改變，為減少秒殺時(shí)服務(wù)器壓力，秒殺商品的圖片和文字元素都需要盡可能靜態(tài)化。在服務(wù)端通過(guò)Thymeleaf 模板語(yǔ)言生成靜態(tài)頁(yè)面，用戶可以通過(guò)Nginx訪問(wèn)頁(yè)面，降低對(duì)Java服務(wù)端的壓力。

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

2.3 Nginx 層和網(wǎng)關(guān)層限流

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

Nginx 層除了做反向代理，還可以做好限流控制。Nginx 層和網(wǎng)關(guān)層限流具體如圖2所示。

圖2 Nginx 層和網(wǎng)關(guān)層限流設(shè)計(jì)圖

應(yīng)用級(jí)別限流：通過(guò)Nginx 配置屬性limit_req_zone和limit_req，來(lái)控制客戶端每個(gè)IP 地址限制為每秒一次請(qǐng)求。并且在網(wǎng)關(guān)層通過(guò)對(duì)用戶權(quán)限控制，只有用戶權(quán)限校驗(yàn)通過(guò)，才給予令牌權(quán)限允許訪問(wèn)秒殺接口服務(wù)。

接口級(jí)別的限流：一般秒殺系統(tǒng)允許用戶每秒/次的訪問(wèn)量。具體是通過(guò)RedisSon（Redis+lua 客戶端）工具來(lái)實(shí)現(xiàn)，具體限流實(shí)現(xiàn)為用戶ID 為key，過(guò)期時(shí)間expire 屬性設(shè)置為1 秒。每次接口請(qǐng)求進(jìn)來(lái)，先通過(guò)用戶ID 去查詢Redis，如果查詢不到則允許訪問(wèn)接口，同時(shí)在Redis 中set 以用戶ID 為key 每秒/次的訪問(wèn)量，來(lái)控制同一個(gè)用戶下次的訪問(wèn)。

2.4 緩存Redis 層實(shí)現(xiàn)

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

另外為了防止超賣，研究人員需要加鎖來(lái)保證，讓請(qǐng)求從并行化切換為串行化處理。例如1 000 件商品，平均分成10 份商品庫(kù)，每份100 件，然后生成10 把鎖，每把鎖對(duì)應(yīng)一份商品庫(kù)。代碼業(yè)務(wù)中誰(shuí)拿到鎖，誰(shuí)就可以產(chǎn)生交易，沒(méi)有鎖的請(qǐng)求則處于等待狀態(tài)。使用redis 分布式鎖來(lái)保護(hù)秒殺的數(shù)據(jù)庫(kù)操作如圖3所示。

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

Redis 加鎖代碼示例（使用Redis+SpringAOP 的方式實(shí)現(xiàn)分布式鎖）

2.5 RocketMQ 消息隊(duì)列和MySQL 數(shù)據(jù)庫(kù)

系統(tǒng)使用RocketMQ 的削峰特性來(lái)更新下單信息到數(shù)據(jù)庫(kù)，預(yù)防因秒殺時(shí)大量訂單直接更新數(shù)據(jù)庫(kù)，導(dǎo)致數(shù)據(jù)庫(kù)服務(wù)宕機(jī)。RocketMQ消息隊(duì)列對(duì)訂單進(jìn)行分組存儲(chǔ)管理，然后讓多個(gè)消費(fèi)者來(lái)進(jìn)行消費(fèi)，消費(fèi)成功后把訂單信息寫入數(shù)據(jù)庫(kù)。MySQL 數(shù)據(jù)庫(kù)用來(lái)做最終持久化，將最終的交易數(shù)據(jù)寫到硬盤。如圖4所示。

圖4 使用RocketMQ 消息隊(duì)列更新數(shù)據(jù)庫(kù)示意圖

3 測(cè)試數(shù)據(jù)

JMeter 是Apache 組織基于Java 開(kāi)發(fā)的壓力測(cè)試工具，用于對(duì)軟件做壓力測(cè)試。JMeter 對(duì)秒殺系統(tǒng)的壓測(cè)結(jié)果如圖5所示。

圖5 JMeter 壓測(cè)結(jié)果圖

當(dāng)前秒殺樣本數(shù)據(jù)50 000，從壓力測(cè)試接口來(lái)看，吞吐量為929/s，表示系統(tǒng)每秒可以處理完900 個(gè)以上的工作量，基本上可以達(dá)到秒殺系統(tǒng)的使用要求。

4 結(jié)論

本系統(tǒng)結(jié)合目前市面最為流行的開(kāi)發(fā)技術(shù)Spring Cloud 架構(gòu)，運(yùn)用其相關(guān)組件完成了微服務(wù)電商平臺(tái)秒殺系統(tǒng)設(shè)計(jì)。該設(shè)計(jì)使用負(fù)載均衡Nginx 做反向代理和限流，使用緩存Redis 提高系統(tǒng)的響應(yīng)速度和利用分布式鎖防止超賣，使用RocketMQ 消息隊(duì)列在高并發(fā)環(huán)境下進(jìn)行削峰和服務(wù)間的解耦。當(dāng)然，電商實(shí)現(xiàn)線上秒殺的方案不止一種，系統(tǒng)也可進(jìn)一步優(yōu)化。秒殺存在于大眾生活的方方面面，秒殺系統(tǒng)的研究及性能提升具有重要意義。