高并發(fā)環(huán)境下的限時(shí)搶購(gòu)服務(wù)器性能優(yōu)化方案

謝昭陽(yáng)

（四川大學(xué)計(jì)算機(jī)學(xué)院，成都 610065）

高并發(fā)環(huán)境下的限時(shí)搶購(gòu)服務(wù)器性能優(yōu)化方案

謝昭陽(yáng)

（四川大學(xué)計(jì)算機(jī)學(xué)院，成都 610065）

電商平臺(tái)中的限時(shí)搶購(gòu)類(lèi)活動(dòng)需要處理瞬時(shí)高并發(fā)的大量請(qǐng)求，給服務(wù)器后臺(tái)架構(gòu)的設(shè)計(jì)帶來(lái)一些新的問(wèn)題和挑戰(zhàn)。如何在保證數(shù)據(jù)一致性的情況下提高服務(wù)器的響應(yīng)速度，是該問(wèn)題的難點(diǎn)所在。提出一套基于消息隊(duì)列的方案，并實(shí)現(xiàn)整套系統(tǒng)，在真實(shí)服務(wù)器中測(cè)試，得到良好的結(jié)果。

高并發(fā)；性能優(yōu)化；限時(shí)搶購(gòu)；電商平臺(tái)

1 問(wèn)題描述

越來(lái)越多的電商平臺(tái)為了吸引用戶(hù)消費(fèi)，推出各種不同形式的促銷(xiāo)活動(dòng)，其中“限時(shí)搶購(gòu)”是一種比較常見(jiàn)的方式。但是限時(shí)搶購(gòu)類(lèi)活動(dòng)需要處理短時(shí)間內(nèi)高并發(fā)的大批量請(qǐng)求，給服務(wù)器后臺(tái)架構(gòu)的設(shè)計(jì)帶來(lái)了一些新的問(wèn)題和挑戰(zhàn)。

“限時(shí)搶購(gòu)”服務(wù)器架構(gòu)設(shè)計(jì)需要解決的問(wèn)題主要有兩點(diǎn)：響應(yīng)速度和數(shù)據(jù)一致性[1]。提高響應(yīng)速度是優(yōu)化的目標(biāo)，然而，同一時(shí)刻的讀和寫(xiě)的請(qǐng)求可能存在沖突，如果沒(méi)有處理好，就會(huì)導(dǎo)致數(shù)據(jù)不一致，產(chǎn)生不良后果。如何在保證數(shù)據(jù)一致性的情況下提高服務(wù)器的響應(yīng)速度，是該問(wèn)題的難點(diǎn)所在。

本文提出一套方案，采用Go語(yǔ)言[2]實(shí)現(xiàn)HTTP服務(wù)器，后端訪問(wèn)Redis數(shù)據(jù)庫(kù)[3]，使用消息隊(duì)列來(lái)緩沖請(qǐng)求，分配多worker進(jìn)行數(shù)據(jù)分發(fā)。實(shí)驗(yàn)表明，該方案部署在3臺(tái)服務(wù)器上時(shí)，可以在保證100%數(shù)據(jù)一致的情況下，達(dá)到4842（單/秒）的穩(wěn)定峰值。

2 方案設(shè)計(jì)

整個(gè)系統(tǒng)主要分為三個(gè)部分：HTTP響應(yīng)worker池、消息隊(duì)列、Redis訪問(wèn)worker池。當(dāng)客戶(hù)端發(fā)起請(qǐng)求時(shí)，系統(tǒng)將從HTTP響應(yīng)worker池中取出一個(gè)空閑的worker，用于處理該HTTP請(qǐng)求。如果該請(qǐng)求不需要訪問(wèn)數(shù)據(jù)庫(kù)，則直接返回結(jié)果；否則，將數(shù)據(jù)庫(kù)查詢(xún)?nèi)蝿?wù)和自身worker_id打包在一起，加入消息隊(duì)列中，并阻塞以等待查詢(xún)結(jié)果的返回。Redis訪問(wèn)worker池中的worker在系統(tǒng)運(yùn)行開(kāi)始時(shí)，就連接并保持了一個(gè)和Re-dis服務(wù)器的連接，然后阻塞在消息隊(duì)列上。若消息隊(duì)列上加入了新的查詢(xún)?nèi)蝿?wù)，就會(huì)觸發(fā)系統(tǒng)從池中調(diào)度一個(gè)空閑的worker到隊(duì)列中取走任務(wù)。worker拿到任務(wù)后，從已保持的Redis連接向數(shù)據(jù)庫(kù)發(fā)出操作指令，然后阻塞在該連接上。數(shù)據(jù)庫(kù)操作完成并返回后，Re-dis訪問(wèn)worker被喚醒，它把結(jié)果交給消息中指定的HTTP響應(yīng)worker，然后繼續(xù)阻塞在消息隊(duì)列上，等待下一次被系統(tǒng)調(diào)度。當(dāng)系統(tǒng)遇到瞬時(shí)高并發(fā)的訪問(wèn)時(shí)，大量沒(méi)有涉及數(shù)據(jù)庫(kù)操作的請(qǐng)求可以直接響應(yīng)。涉及數(shù)據(jù)庫(kù)操作的請(qǐng)求會(huì)按請(qǐng)求的先后順序依次進(jìn)入消息隊(duì)列等待處理。Redis訪問(wèn)worker可以持續(xù)不斷地處理隊(duì)列中的任務(wù)，不必為每一個(gè)任務(wù)單獨(dú)建立和銷(xiāo)毀連接。根據(jù)實(shí)際硬件和網(wǎng)絡(luò)環(huán)境適當(dāng)?shù)乜刂芌edis訪問(wèn)worker的數(shù)量，平衡系統(tǒng)開(kāi)銷(xiāo)和隊(duì)列等待時(shí)間，以達(dá)到最佳性能。

3 具體實(shí)現(xiàn)

本方案主要采用Go語(yǔ)言實(shí)現(xiàn)整個(gè)系統(tǒng)。Go語(yǔ)言的標(biāo)準(zhǔn)庫(kù)包含一個(gè)基礎(chǔ)的HTTP服務(wù)器。為了提高URL解析速度，本文采用基于Trie樹(shù)的httprouter作為URL路由器。

Go語(yǔ)言支持一種輕量級(jí)線(xiàn)程goroutine，它類(lèi)似于協(xié)程，在goroutine之間切換成本非常低。此外，為了支持goroutine之間的通信，Go語(yǔ)言提供channel作為內(nèi)置的數(shù)據(jù)類(lèi)型，并為其配備一些語(yǔ)法層面上的操作。其中一個(gè)比較典型的是select關(guān)鍵字，使用時(shí)，類(lèi)似于switch一樣指定若干個(gè)case子表達(dá)式，也可以指定de-fault語(yǔ)句，其中每個(gè)case的條件通常是一個(gè)等待chan-nel讀或?qū)懙谋磉_(dá)式。當(dāng)執(zhí)行到select語(yǔ)句時(shí)，系統(tǒng)會(huì)從就緒的case中不確定地選擇一個(gè)執(zhí)行。若此時(shí)所有case都未就緒，且沒(méi)有指明default，則該select語(yǔ)句所在的goroutine就會(huì)阻塞，并交出控制權(quán)，系統(tǒng)就會(huì)調(diào)度其他goroutine執(zhí)行。當(dāng)一個(gè)select語(yǔ)句指明default時(shí)，則遇到?jīng)]有任何case就緒的情況就會(huì)直接執(zhí)行de-fault。

本文在實(shí)現(xiàn)所提出的方案時(shí)，以?xún)煞N不同的方式使用channel:一種是用來(lái)阻塞HTTP響應(yīng)worker的單值channel，實(shí)現(xiàn)信號(hào)量的功能；另一種是用來(lái)緩沖Re-dis訪問(wèn)的多值channel，實(shí)現(xiàn)消息隊(duì)列的功能。當(dāng)HTTP響應(yīng)worker要請(qǐng)求數(shù)據(jù)庫(kù)時(shí)，它先會(huì)創(chuàng)建一個(gè)單值channel，將其和數(shù)據(jù)庫(kù)查詢(xún)參數(shù)打包，放入消息隊(duì)列中，然后等待這個(gè)channel傳出數(shù)據(jù)的時(shí)候再繼續(xù)執(zhí)行。Redis訪問(wèn)worker從初始化開(kāi)始，就嘗試從消息隊(duì)列channel中讀取消息。由于一開(kāi)始消息隊(duì)列為空，所以所有Redis訪問(wèn)worker都阻塞。當(dāng)隊(duì)列channel可以讀取消息時(shí)，空閑的worker就會(huì)迅速將消息取走。搶到消息的worker執(zhí)行Redis訪問(wèn)，其余的繼續(xù)阻塞等待。如果Redis查詢(xún)結(jié)束，Redis訪問(wèn)worker就會(huì)把結(jié)果通過(guò)消息中的單值channel傳遞給相應(yīng)的HTTP響應(yīng)worker，使其繼續(xù)執(zhí)行。

程序中的關(guān)鍵代碼如下：

Redis是一種NoSQL內(nèi)存數(shù)據(jù)庫(kù)，存取速度非?？?。Redis中的數(shù)據(jù)主要以“Key-Value”的方式存儲(chǔ)，Key限定為字符串，Value則有不同數(shù)據(jù)結(jié)構(gòu)可選，例如字符串String、集合Set、哈希表Hash、鏈表List、有序集合Sorted Set等。Redis服務(wù)器內(nèi)嵌Lua腳本解釋器，可以編寫(xiě)Lua腳本代碼作為預(yù)定義批處理操作，由客戶(hù)端提供參數(shù)，發(fā)起調(diào)用命令“EVAL”或“EVALSHA”以執(zhí)行指定的Lua代碼。Redis保證每個(gè)Lua調(diào)用都和內(nèi)置操作一樣具有原子性，當(dāng)一段Lua腳本代碼在執(zhí)行，不會(huì)有其他操作同時(shí)運(yùn)行。基于Redis提供的這個(gè)特性，我們把Redis訪問(wèn)worker的數(shù)據(jù)讀寫(xiě)操作都封裝到一個(gè)Lua腳本中，這樣實(shí)現(xiàn)，一方面可以保證數(shù)據(jù)的一致性，另一方面又可以使得多次操作合并成一個(gè)操作，減少網(wǎng)絡(luò)傳輸開(kāi)銷(xiāo)和來(lái)回傳輸?shù)木W(wǎng)絡(luò)延遲。

4 測(cè)試結(jié)果

由于本文所提出的方案沒(méi)有橫向依賴(lài)，即各個(gè)HTTP服務(wù)器之間不存在直接通信，所以在真實(shí)環(huán)境中，可以設(shè)置一臺(tái)負(fù)載均衡服務(wù)器，并橫向增加HTTP服務(wù)器，以提高整個(gè)系統(tǒng)的并發(fā)量。

我們將HTTP服務(wù)器代碼鏡像地部署在3臺(tái)雙核CPU、4GB內(nèi)存的服務(wù)器上。另外配置了一臺(tái)Redis服務(wù)器，獨(dú)立于HTTP服務(wù)器，只負(fù)責(zé)數(shù)據(jù)存儲(chǔ)與管理。配置額外的服務(wù)器運(yùn)行測(cè)試腳本，模擬1000個(gè)客戶(hù)端同時(shí)請(qǐng)求，以round robin的負(fù)載均衡策略[4]均衡地請(qǐng)求3臺(tái)HTTP服務(wù)器。

經(jīng)測(cè)試，所有請(qǐng)求都能正確地返回，并且當(dāng)Redis訪問(wèn)worker數(shù)量為250時(shí)，平均峰值達(dá)到了4842（單/秒）。

5 結(jié)語(yǔ)

本文針對(duì)高并發(fā)環(huán)境中的限時(shí)搶購(gòu)服務(wù)器后臺(tái)設(shè)計(jì)面臨的問(wèn)題，分析其中的關(guān)鍵點(diǎn)和難點(diǎn)，提出了一個(gè)解決方案。為了驗(yàn)證這套方案的可行性和性能，本文實(shí)現(xiàn)整套系統(tǒng)，并部署在服務(wù)器中進(jìn)行測(cè)試，得到了良好的結(jié)果。本文所提供的方案可以為現(xiàn)有電商平臺(tái)優(yōu)化服務(wù)器性能時(shí)提供參考。

[1]Terry D.Replicated Data Consistency Explained Through Baseball[J].Communications of the ACM,2013,56(12):82-89.

[2]Zawodny J.Redis:Lightweight Key/Value Store That Goes the Extra Mile[J].Linux Magazine,2009,79.

[3]Schmager F,Cameron N,Noble J.GoHotDraw:Evaluating the go Programming Language with Design Patterns[C].Evaluation and Usability of Programming Languages and Tools.ACM,2010:10.

[4]Shreedhar M,Varghese G.Efficient Fair Queuing Using Deficit Round-Robin[J].Networking,IEEE/ACM Transactions on,1996,4(3): 375-385.

Performance Optimization for Highly Concurrent Flash Sale Server

XIE Zhao-yang

（College of Computer Science,Sichuan University,Chengdu 610065）

Flash sale in e-commerce platform needs to deal with a large number of transient high concurrent requests,which brings some new chal-lenges and problems to back-end server architectural design.The difficulty of the problem lies in improving the response speed of the server while keeping data consistency.Presents a solution based on message queue,and implements the whole system.Tested on real hard-ware,the proposed solution shows a good performance.

High Concurrency;Performance Optimization;Flash Sale;E-Commerce

1007-1423（2016）08-0051-03

10.3969/j.issn.1007-1423.2016.08.010

謝昭陽(yáng)（1992-），男，福建泉州人，在讀碩士研究生，研究方向?yàn)槌绦蛟O(shè)計(jì)語(yǔ)言理論

2016-02-23

2016-03-03