一種高并發(fā)電商秒殺系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

劉磊

（廣東開放大學(xué)，廣州 510000）

1 秒殺業(yè)務(wù)分析

作為現(xiàn)代電商的重要促銷手段，商品秒殺、搶紅包這類“短時(shí)間、高并發(fā)”的需求越來越多。一個(gè)典型的電商秒殺系統(tǒng)圍繞著商家、庫存、用戶、訂單四者展開[1]。首先，商家會(huì)添加、調(diào)整商品庫存，庫存則會(huì)反映商家的發(fā)貨、核帳信息；用戶成功秒殺商品，庫存進(jìn)行減法操作，同時(shí)用戶訂單進(jìn)行加法操作，插入一條秒殺記錄明細(xì)；用戶的付款、退貨行為，也會(huì)反映在庫存和訂單。秒殺系統(tǒng)處理的是大量用戶瞬時(shí)對有限商品的激烈競爭，它的高并發(fā)點(diǎn)出在前端用戶秒殺商品環(huán)節(jié)，其核心是庫存的高效處理。

用戶每個(gè)成功的秒殺行為都包括兩個(gè)動(dòng)作：減去商品庫存和記錄購買明細(xì)，業(yè)務(wù)要求這兩個(gè)動(dòng)作必須同時(shí)成功，若減庫存而沒有記錄購買明細(xì)就會(huì)出現(xiàn)超賣，記錄了明細(xì)卻沒有減庫存就出現(xiàn)了少賣，這兩種現(xiàn)象都是不正常的。因此，減庫存與記明細(xì)這兩個(gè)原子操作要么都成功，要么都不成功，它們組成了一個(gè)完整的事務(wù)，秒殺業(yè)務(wù)場景具有典型的“事務(wù)”特性，如圖1所示。要保證以上操作數(shù)據(jù)順利存儲(chǔ)，有兩種方案：使用RDBMS（關(guān)系型數(shù)據(jù)庫）或使用NoSQL（非關(guān)系型數(shù)據(jù)庫），NoSQL的重要場景在緩存，對事務(wù)支持較差；RDBMS支持魯棒性事務(wù)，業(yè)界研究表明，事務(wù)機(jī)制依然是目前最可靠的數(shù)據(jù)落地方案[2-3]。

圖1 秒殺的事務(wù)特性

2 系統(tǒng)設(shè)計(jì)

2.1 功能設(shè)計(jì)

為著重驗(yàn)證秒殺功能，筆者設(shè)計(jì)了一個(gè)業(yè)務(wù)具有典型性的秒殺系統(tǒng)[4]，功能設(shè)計(jì)如下：

（1）用戶注冊登錄：用戶注冊賬號，使用賬號登錄系統(tǒng)。

（2）秒殺列表查詢：以列表形式展示秒殺商品。

（3）秒殺詳情查詢：以單頁面展示秒殺商品詳細(xì)信息，包括秒殺倒計(jì)時(shí)、秒殺按鈕。

（4）生成秒殺地址：為了避免用戶作弊，即秒殺開啟前提前在瀏覽器輸入秒殺地址進(jìn)入秒殺，設(shè)計(jì)只有在秒殺開始時(shí)才能暴露秒殺地址，使用MD5加鹽加密生成地址，防止用戶撞庫破解。

（5）執(zhí)行秒殺：系統(tǒng)最核心功能，用戶執(zhí)行秒殺，成功則依次進(jìn)行減庫存和記錄購買明細(xì)兩個(gè)動(dòng)作，同時(shí)返回秒殺成功響應(yīng)給前端用戶，秒殺失敗也返回相應(yīng)失敗信息。

（6）用戶中心：以列表形式展示用戶成功秒殺的商品，對接付款模塊，顯示訂單狀態(tài)。

2.2 數(shù)據(jù)庫設(shè)計(jì)

圍繞秒殺業(yè)務(wù)和功能分析，本方案數(shù)據(jù)庫設(shè)計(jì)三個(gè)核心實(shí)體對象：用戶、商品和訂單。用戶實(shí)體記錄注冊登錄信息，用戶ID設(shè)置為主鍵；商品實(shí)體記錄一件商品的名稱、庫存量、秒殺開始時(shí)間和結(jié)束時(shí)間等庫存詳情，商品ID設(shè)置為主鍵；訂單記錄秒殺成功后的明細(xì)，即哪個(gè)用戶秒殺了哪件商品，當(dāng)前狀態(tài)是未付款還是已付款。根據(jù)業(yè)務(wù)分析，一個(gè)用戶可以秒殺多個(gè)商品，一個(gè)商品也可以被多個(gè)用戶秒殺，用戶與商品是多對多的關(guān)系，同時(shí)秒殺業(yè)務(wù)要求同一用戶對同一商品不能重復(fù)秒殺，也就是訂單表不能插入用戶ID和商品ID兩者都相同的記錄，解決策略是只需要將商品ID與用戶ID組成訂單表的聯(lián)合主鍵即可。本秒殺系統(tǒng)數(shù)據(jù)庫模型設(shè)計(jì)如圖2所示。

圖2 數(shù)據(jù)庫模型圖

2.3 流程設(shè)計(jì)

用戶秒殺商品的典型流程是：①首先，用戶查看所有的秒殺商品列表，點(diǎn)擊選中的秒殺進(jìn)入商品詳情頁；②詳情頁除了顯示商品名稱、詳情、開始時(shí)間、結(jié)束時(shí)間等“靜態(tài)信息”外，每次加載詳情頁，都要?jiǎng)討B(tài)請求服務(wù)器標(biāo)準(zhǔn)系統(tǒng)時(shí)間，若系統(tǒng)時(shí)間小于開始時(shí)間，則返回前端提示，頁面使用特效展示秒殺倒計(jì)時(shí)；③若系統(tǒng)時(shí)間大于開始時(shí)間并且小于結(jié)束時(shí)間，則意味著秒殺進(jìn)行中，系統(tǒng)生成秒殺地址并返回前端顯示秒殺按鈕，用戶需要登錄或提前登錄執(zhí)行秒殺，成功秒殺則后端數(shù)據(jù)庫執(zhí)行減庫存和記明細(xì)兩個(gè)事務(wù)操作，返回前端秒殺結(jié)果；④若系統(tǒng)時(shí)間大于結(jié)束時(shí)間，則意味著秒殺結(jié)束，返回前端結(jié)束信息。用戶在商品詳情頁的交互流程如圖3所示。

圖3 用戶秒殺流程圖

3 技術(shù)實(shí)現(xiàn)

本系統(tǒng)實(shí)現(xiàn)方案采用業(yè)界流行的技術(shù)組合：Linux+Tomcat/Nginx+SSM+Bootstrap+MySQL+Redis+Maven，這套組合被阿里、京東等互聯(lián)網(wǎng)公司廣泛應(yīng)用于大中型Web應(yīng)用，非常適于開發(fā)高并發(fā)、高性能、高擴(kuò)展的Web系統(tǒng)。

（1）SSM：SpringMVC、Spring、MyBatis三大框架的完美組合，主流的J2EE企業(yè)級開發(fā)框架，具有輕量級、代碼侵入性低、技術(shù)成熟的特點(diǎn)，支持典型的三層架構(gòu)：DAO（數(shù)據(jù)層）、Service（業(yè)務(wù)層）、Web（表示層）[5]。MyBatis是數(shù)據(jù)層框架，支持定制SQL語句，傳參自由、靈活，結(jié)果集自動(dòng)賦值，接口設(shè)計(jì)和SQL語句的分離，方便代碼Review。Spring提供了一個(gè)統(tǒng)一托管對象的容器工廠，允許通過一致的訪問接口，訪問工廠里的任意實(shí)例，也就是對象控制反轉(zhuǎn)（IoC）；Spring還支持聲明式事務(wù)，對于高并發(fā)應(yīng)用，帶事務(wù)的方法往往是瓶頸所在，一不小心就可能導(dǎo)致數(shù)據(jù)庫訪問延遲，使用聲明式事務(wù)可以方便地開發(fā)單一、純凈的事務(wù)方法。SpringMVC是Web層框架，支持RESTful風(fēng)格的URL和MVC開發(fā)模式。

（2）Bootstrap：簡潔、直觀、強(qiáng)悍的前端開發(fā)框架，基于 HTML5、CSS3、jQuery技術(shù)構(gòu)建，提供了導(dǎo)航、分頁、面板等可復(fù)用的靜態(tài)組件，下拉菜單、標(biāo)簽頁、彈出框等動(dòng)態(tài)插件，強(qiáng)大靈活的柵格布局系統(tǒng)，使用Bootstrap可以快速、高效地開發(fā)健壯和優(yōu)雅的響應(yīng)式靜態(tài)頁面[6]。

（3）MySQL：最流行的用于Web開發(fā)的關(guān)系型數(shù)據(jù)庫，支持事務(wù)和鎖機(jī)制，可以單點(diǎn)、主從復(fù)制、集群多種規(guī)模運(yùn)行，經(jīng)測試，MySQL執(zhí)行同一條update壓力測試約為4萬QPS，即一秒可以賣4萬個(gè)商品，能夠頂住大部分秒殺壓力，本方案使用MySQL持久化數(shù)據(jù)[7-8]。

（4）Redis：基于內(nèi)存的NoSQL型數(shù)據(jù)庫，經(jīng)測試Redis性能非常高，每秒鐘SET操作可執(zhí)行110000次、GET操作可執(zhí)行81000次，本方案使用Redis緩存熱點(diǎn)數(shù)據(jù)[9-11]。

（5）Maven：強(qiáng)大的項(xiàng)目構(gòu)建工具，以標(biāo)準(zhǔn)化的方式管理編譯、生成、發(fā)布、文檔等整個(gè)項(xiàng)目建設(shè)生命周期，提供更佳的項(xiàng)目依賴和持續(xù)集成管理。

（6）Tomcat/Nginx：Tomcat輕量、穩(wěn)定，用作應(yīng)用服務(wù)器，Nginx具備強(qiáng)大的并發(fā)處理、靈活的反向代理能力，用作負(fù)載均衡服務(wù)器。

使用以上技術(shù)組合，編碼分為SQL編碼、DAO層編碼、Service層編碼、Web層編碼，系統(tǒng)各層關(guān)鍵接口對接情況如表1所示。

表1 系統(tǒng)關(guān)鍵接口對接表

4 高并發(fā)瓶頸分析及優(yōu)化

秒殺的本質(zhì)是大量用戶瞬時(shí)集中競爭有限的商品，秒殺系統(tǒng)最大的瓶頸點(diǎn)在商品秒殺環(huán)節(jié)。當(dāng)秒殺開啟時(shí)，大量用戶涌入查詢商品詳情頁、同時(shí)點(diǎn)擊秒殺按鈕，請求流量瞬間達(dá)到高峰，若將所有請求都直接發(fā)送到服務(wù)器，將耗損服務(wù)器大量響應(yīng)資源，單臺(tái)服務(wù)器并發(fā)處理能力有限，嚴(yán)重時(shí)可能導(dǎo)致服務(wù)器宕機(jī)，為了保證大量請求的及時(shí)處理，使用其他服務(wù)器分流依然是最有效的應(yīng)對策略。

一個(gè)成功的秒殺行為在服務(wù)器要執(zhí)行兩個(gè)業(yè)務(wù)邏輯：減庫存、記明細(xì)，反映在數(shù)據(jù)庫層面，這兩個(gè)原子操作組成一個(gè)事務(wù)，要么都提交，要么都不提交，示意代碼如下：

Start Transaction

Update減庫存

Insert記明細(xì)

Commit/Rollback

大量用戶在有限的時(shí)間內(nèi)競爭有限商品，意味著很多用戶同時(shí)去執(zhí)行同一個(gè)商品ID的減庫存操作（如：update table set num=num-1 where id=1001），但是數(shù)據(jù)庫對同一行數(shù)據(jù)修改是有行級鎖機(jī)制的，即一次運(yùn)行完提交后，下一個(gè)才能運(yùn)行，這就讓很多用戶“堵塞”在update操作，并發(fā)量大時(shí)系統(tǒng)響應(yīng)性能呈指數(shù)級下降，這也是秒殺業(yè)務(wù)邏輯的并發(fā)瓶頸所在。對于秒殺系統(tǒng)來說，高并發(fā)優(yōu)化就是疏通“堵塞”、引導(dǎo)“分流”，讓更多人更快通過“瓶頸”參與“競爭”[5-6]。

針對以上分析提出以下具體優(yōu)化措施[12-13]。

4.1 使用C C D D N N緩存靜態(tài)化資源

CDN即內(nèi)容分發(fā)網(wǎng)絡(luò)，通過在網(wǎng)絡(luò)各處放置節(jié)點(diǎn)服務(wù)器構(gòu)成智能虛擬網(wǎng)絡(luò)，能夠?qū)崟r(shí)將用戶請求重定向到響應(yīng)最快的服務(wù)節(jié)點(diǎn)，使用戶就近取得所需內(nèi)容，開發(fā)人員可以自己搭建或租用云CDN服務(wù)。商品秒殺詳情頁是并發(fā)請求量最集中的頁面，為減少服務(wù)器請求，可將詳情頁里靜態(tài)化的資源剝離出來推送到CDN節(jié)點(diǎn)，例如JavaScript腳本、CSS、圖片等不常變化的資源，也就是在前端緩存靜態(tài)內(nèi)容，這樣一部分請求就被重定向到CDN節(jié)點(diǎn)，如果命中資源就不需訪問后端服務(wù)器，減輕了服務(wù)器壓力，也提高了響應(yīng)速度。

4.2 使用Redis優(yōu)化生成秒殺地址

詳情頁里有部分資源是不能緩存到CDN節(jié)點(diǎn)的，例如請求服務(wù)器標(biāo)準(zhǔn)時(shí)間，Java執(zhí)行一次new Date()約只需10ns，因此不會(huì)成為瓶頸。請求秒殺地址也不能緩存到CDN，秒殺地址為防止被猜到，是由服務(wù)端在秒殺期間動(dòng)態(tài)生成的，每次查詢詳情頁都要請求一次秒殺地址是否開啟，如果開啟則通過MD5加鹽后再加密生成不可逆的地址字符串發(fā)送到前端，判斷是否開啟需要查詢秒殺商品的開始時(shí)間和結(jié)束時(shí)間，為提高響應(yīng)速度，可將秒殺商品查詢結(jié)果緩存在服務(wù)端。本方案選用高性能的Redis用作服務(wù)端緩存，方法是首先在Redis查找商品，若找到則直接返回；找不到則查詢數(shù)據(jù)庫，同時(shí)緩存一份在Redis。為避免單機(jī)故障，也可以做成Redis集群使用。

4.3 使用存儲(chǔ)過程優(yōu)化行級鎖持有時(shí)間

上面分析出秒殺環(huán)節(jié)的瓶頸點(diǎn)在對同一商品“競爭”執(zhí)行update操作，數(shù)據(jù)庫對一行數(shù)據(jù)執(zhí)行update操作時(shí)，會(huì)加上行級鎖，此時(shí)其他update操作處于等待，等事務(wù)提交或回滾后釋放行級鎖，其他update操作才能依次執(zhí)行，而insert操作是可以并發(fā)運(yùn)行的，也就是行級鎖持有時(shí)間阻塞了秒殺進(jìn)程；Java與MySQL交互，使用Java執(zhí)行SQL語句的耗時(shí)，包括SQL語句執(zhí)行耗時(shí)、發(fā)送語句到MySQL和返回結(jié)果的網(wǎng)絡(luò)延遲、GC操作耗時(shí)，一次秒殺行為的耗時(shí)計(jì)算公式為：一次秒殺耗時(shí)=update耗時(shí)+insert耗時(shí)+網(wǎng)絡(luò)延遲+GC耗時(shí)+其他耗時(shí)。所有耗時(shí)加起來，秒殺行為的總耗時(shí)就變長了，其實(shí)Java不慢，MySQL也不慢，但是使用Java操作MySQL，中間耗時(shí)浪費(fèi)，響應(yīng)就慢了[14-16]。

因此減少行級鎖的持有時(shí)間和降低網(wǎng)絡(luò)延遲即可大幅降低一次秒殺耗時(shí)，方法是：①將insert調(diào)到update之前運(yùn)行，insert可以并發(fā)執(zhí)行，若update成功，則可以同時(shí)提交，否則，則同時(shí)回滾，只有update需要鎖住，性能提升一倍；②將業(yè)務(wù)邏輯封裝成存儲(chǔ)過程放在MySQL服務(wù)端運(yùn)行，Java客戶端只需要拿到執(zhí)行結(jié)果即可，MySQL本地執(zhí)行存儲(chǔ)過程是很快的，這樣大部分網(wǎng)絡(luò)延遲和GC耗時(shí)會(huì)被消滅掉。行級鎖持有時(shí)間優(yōu)化前后對例如圖4所示。

經(jīng)過多組測試，對同一行數(shù)據(jù)執(zhí)行一次update操作，使用存儲(chǔ)過程事務(wù)的行級鎖持有時(shí)間大約為6ms，使用Java客戶端托管的事務(wù)行級鎖持有時(shí)間大約為40ms，相差34ms，這意味者如果有500人同時(shí)競爭同一個(gè)熱點(diǎn)商品，優(yōu)化后的事務(wù)排隊(duì)時(shí)間可以減少17s（34ms×500）。

圖4 行級鎖持有時(shí)間優(yōu)化

4.4 使用集群化部署提高系統(tǒng)抗壓能力

理論上，一臺(tái)服務(wù)器若能頂住1000的并發(fā)量，兩臺(tái)服務(wù)器就能頂住2000的并發(fā)量，一般來說，當(dāng)上線的Web系統(tǒng)并發(fā)量達(dá)到一定數(shù)量級時(shí)，都可以通過大規(guī)模服務(wù)器集群化部署提高系統(tǒng)的抗壓能力，也就是常說的“當(dāng)一頭牛拉不動(dòng)時(shí)，那就用三頭?！薄１痉桨冈O(shè)計(jì)的系統(tǒng)架構(gòu)、選用的開發(fā)框架都非常適于以集群的方式運(yùn)行，對于實(shí)際線上的電商秒殺系統(tǒng)，通過不斷增加服務(wù)器可以快速提高系統(tǒng)的并發(fā)處理能力[17-18]。本系統(tǒng)線上集群化部署可以分為五層：①CDN緩存層：緩存靜態(tài)化資源；②負(fù)載均衡層：根據(jù)訪問量，負(fù)責(zé)將請求智能轉(zhuǎn)發(fā)到不同服務(wù)器；③Web應(yīng)用層：在Tomcat集群上部署相同的Web應(yīng)用；④Redis緩存層：緩存數(shù)據(jù)庫查詢結(jié)果；⑤數(shù)據(jù)庫存儲(chǔ)層：數(shù)據(jù)落地，使用主從庫同步、讀寫庫分離、分庫分表等技術(shù)增強(qiáng)抗壓能力。線上秒殺系統(tǒng)集群化部署方案參考圖5所示。

圖5 秒殺系統(tǒng)集群化部署方案

5 測試與應(yīng)用

為了測試本文設(shè)計(jì)的秒殺系統(tǒng)的性能、可用性和并發(fā)處理能力，筆者使用Apache JMeter進(jìn)行了三組壓力測試，為避免硬件帶來的誤差，三組測試環(huán)境使用了相同的機(jī)器配置，統(tǒng)一CPU為Intel Core i5 3.3GHz、內(nèi)存為8GB，網(wǎng)絡(luò)環(huán)境為實(shí)驗(yàn)室局域網(wǎng)。三組測試分別為：①測試一使用1臺(tái)服務(wù)器，MySQL與Tomcat安裝在一起；②測試二使用2臺(tái)服務(wù)器，1臺(tái)安裝Tomcat，1臺(tái)安裝MySQL，Web服務(wù)器與數(shù)據(jù)庫分開部署；③測試三使用10臺(tái)服務(wù)器模擬小型集群環(huán)境，2臺(tái)安裝Nginx作負(fù)載均衡服務(wù)器，1臺(tái)安裝Nginx作靜態(tài)資源服務(wù)器，3臺(tái)安裝Tomcat作應(yīng)用服務(wù)器，1臺(tái)安裝Redis作緩存服務(wù)器，3臺(tái)安裝MySQL作數(shù)據(jù)庫服務(wù)器。從測試一到測試二再到測試三，不斷增加服務(wù)器數(shù)量和并發(fā)數(shù)，以驗(yàn)證系統(tǒng)并發(fā)承載能力，三組測試得到的并發(fā)數(shù)、服務(wù)器CPU利用率、平均響應(yīng)時(shí)間如表2-4所示。

表2 測試一

表3 測試二

表4 測試三

由此可見，通過不斷增加服務(wù)器，分層部署系統(tǒng)，將請求流量分發(fā)到不同節(jié)點(diǎn)；采取一定的優(yōu)化策略，將靜態(tài)化資源分流，將部分查詢結(jié)果緩存，將網(wǎng)絡(luò)延遲降至最低。這些措施可有效提高秒殺系統(tǒng)的性能、可用性和并發(fā)處理能力。本方案實(shí)現(xiàn)的秒殺系統(tǒng)作為筆者參與的電商平臺(tái)核心模塊已經(jīng)上線運(yùn)行，通過生產(chǎn)環(huán)境中的并發(fā)優(yōu)化和集群化部署，在多次的促銷活動(dòng)中，頂住了上萬的并發(fā)壓力，表現(xiàn)穩(wěn)定。

6 結(jié)語

本文設(shè)計(jì)和實(shí)現(xiàn)的電商秒殺系統(tǒng)解決方案，使用SSM框架實(shí)現(xiàn)高擴(kuò)展性，使用MySQL事務(wù)機(jī)制保證秒殺數(shù)據(jù)完整性，使用Redis緩存提高系統(tǒng)訪問性能，使用集群化部署增強(qiáng)系統(tǒng)并發(fā)處理能力，本方案具有典型性，對于解決秒殺、搶紅包這類“瞬時(shí)高并發(fā)搶資源”的需求有較普遍的參考價(jià)值，本文沒有更多討論秒殺系統(tǒng)的安全性，有待進(jìn)一步研究。當(dāng)然秒殺作為各大電商的促銷手段，其線上實(shí)現(xiàn)方案不止一種，也有利用分布式MQ記錄行為消息、再異步數(shù)據(jù)落地或者利用隊(duì)列在內(nèi)存中操作的方案，沒有最佳和一勞永逸的方案，只有最適應(yīng)業(yè)務(wù)需求的方案，讀者可以根據(jù)場景靈活選用。