秒殺系統(tǒng)一般設(shè)計(jì)思路

秒殺系統(tǒng)的特點(diǎn)是：

§ 瞬時(shí)請(qǐng)求量很高

§ 持續(xù)時(shí)間較短

所以秒殺系統(tǒng)需要解決的是「在高并發(fā)情況下，用戶請(qǐng)求及數(shù)據(jù)更新的問題」！

一般的設(shè)計(jì)思路：

§ （變相）擴(kuò)容

§ 提高性能

具體方式有：

動(dòng)靜分離

對(duì)于一般的應(yīng)用來說，請(qǐng)求流程大致如下：

§ 服務(wù)端接收到請(qǐng)求，從數(shù)據(jù)庫(kù)中查詢相應(yīng)數(shù)據(jù)

§ 選擇對(duì)應(yīng)的展示模板

§ 通過模板和數(shù)據(jù)渲染出最終頁(yè)面

§ 將頁(yè)面返回給客戶端

當(dāng)訪問量很大的時(shí)候，服務(wù)器壓力會(huì)非常的大！解決方案就是動(dòng)靜分離！

做軟件開發(fā)的都知道要「將變化的內(nèi)容和不變的內(nèi)容隔離開」，以便于獨(dú)立進(jìn)化。這里其實(shí)也是一樣的思路。

模板是個(gè)靜態(tài)的內(nèi)容，部署后一般是不會(huì)變化的；而數(shù)據(jù)是個(gè)相對(duì)動(dòng)態(tài)的內(nèi)容，根據(jù)請(qǐng)求參數(shù)的不同，數(shù)據(jù)可能不同。所以我們需要將模板與數(shù)據(jù)分離。

以前的做法是后端事先生成渲染后的頁(yè)面，緩存起來或直接部署到靜態(tài)服務(wù)器或CDN，請(qǐng)求時(shí)直接從緩存（靜態(tài)服務(wù)器/CDN）中獲取頁(yè)面，而動(dòng)態(tài)數(shù)據(jù)通過AJAX請(qǐng)求的方式獲取。服務(wù)器不再需要渲染頁(yè)面，只需要返回少量的數(shù)據(jù)即可。既降低了服務(wù)器壓力，又減少了服務(wù)端數(shù)據(jù)的傳輸。

而現(xiàn)在很流行的前后端分離就能很容易的解決這個(gè)問題。頁(yè)面獨(dú)立部署，數(shù)據(jù)異步獲取，頁(yè)面渲染由瀏覽器負(fù)責(zé)。這里和普通的前后端分離還有些差異，需要將相對(duì)靜態(tài)的數(shù)據(jù)都靜態(tài)化，以減少動(dòng)態(tài)數(shù)據(jù)量。

分離后，靜態(tài)內(nèi)容和動(dòng)態(tài)內(nèi)容就可以獨(dú)立進(jìn)化。例如靜態(tài)內(nèi)容可以部署到CDN上，用戶可以從最近的服務(wù)器獲取到數(shù)據(jù)。相對(duì)熱點(diǎn)的動(dòng)態(tài)數(shù)據(jù)可以做緩存，降低數(shù)據(jù)庫(kù)壓力，進(jìn)一步提高服務(wù)端響應(yīng)。

獨(dú)立部署

「獨(dú)立部署」其實(shí)也可以看成是一種「動(dòng)靜分離」。將秒殺系統(tǒng)這個(gè)相對(duì)動(dòng)態(tài)的系統(tǒng)，和相對(duì)靜態(tài)的業(yè)務(wù)系統(tǒng)分開部署。

原因很好理解，秒殺系統(tǒng)的請(qǐng)求量很大，可能會(huì)由于預(yù)估不足或系統(tǒng)問題，導(dǎo)致了秒殺系統(tǒng)的負(fù)載過高、響應(yīng)變慢。如果秒殺系統(tǒng)是業(yè)務(wù)系統(tǒng)的一部分，則會(huì)導(dǎo)致業(yè)務(wù)系統(tǒng)響應(yīng)變慢，甚至導(dǎo)致系統(tǒng)沒有響應(yīng)。且秒殺是個(gè)短期活動(dòng)也不是核心業(yè)務(wù)，而業(yè)務(wù)系統(tǒng)是需要長(zhǎng)期穩(wěn)定運(yùn)行的。不能因?yàn)橐粋€(gè)短期非核心的活動(dòng)，而影響了核心的業(yè)務(wù)系統(tǒng)。

所以秒殺系統(tǒng)最好和業(yè)務(wù)系統(tǒng)分開獨(dú)立部署。即使秒殺系統(tǒng)掛了，也不會(huì)影響業(yè)務(wù)系統(tǒng)的正常對(duì)外服務(wù)。

同樣的道理，秒殺系統(tǒng)的數(shù)據(jù)庫(kù)也需要和業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫(kù)獨(dú)立開。

限流削峰

動(dòng)靜分離，獨(dú)立部署能提高系統(tǒng)的響應(yīng)能力和容量。但是可提供的訪問量是一定的，當(dāng)超過了系統(tǒng)所能承受的容量，該怎么辦呢？你可能會(huì)說，可以擴(kuò)容啊。的確是可以，但是擴(kuò)容也是有限度的。假設(shè)單機(jī)能承受10萬的請(qǐng)求量，預(yù)計(jì)有1億的請(qǐng)求量，你要擴(kuò)容1000臺(tái)服務(wù)器？！這會(huì)導(dǎo)致嚴(yán)重的浪費(fèi)。

首先，上面提到了，秒殺是短期活動(dòng)，為了秒殺多部署1000臺(tái)服務(wù)器，秒殺結(jié)束后這些服務(wù)器再銷毀？既浪費(fèi)硬件資源、又浪費(fèi)人力資源。

其次，秒殺的商品數(shù)量其實(shí)并不多，可能秒殺賺的那點(diǎn)錢還不夠付服務(wù)器和帶寬的費(fèi)用。真·花錢賺吆喝！

我們?cè)撊绾翁幚砟兀?/span>

上面說了，秒殺的商品數(shù)量不多，也就是說，其實(shí)最后的真實(shí)成交量并不大。再進(jìn)一步講，很多的請(qǐng)求都是沒用的。

其次，在秒殺前，買家會(huì)頻繁的刷頁(yè)面，這又額外增加了無用請(qǐng)求的數(shù)量。

我們只要把這些無用的請(qǐng)求提前都過濾掉，最終到達(dá)服務(wù)端的請(qǐng)求就會(huì)少很多，也就不需要這么多的服務(wù)器了。這就是限流削峰。具體做法有很多：

§ 秒殺時(shí)間未到時(shí)，秒殺按鈕置灰：也就是說在秒殺未到時(shí)間時(shí)，不可發(fā)送下單請(qǐng)求。前面我們已經(jīng)將頁(yè)面靜態(tài)化，分發(fā)到了CDN，所以用戶的刷新操作只會(huì)到CDN。這就削除了刷新操作導(dǎo)致的請(qǐng)求。

§ 秒殺按鈕點(diǎn)擊后置灰：即避免double-click，一個(gè)用戶只能點(diǎn)擊一次。限制用戶點(diǎn)擊次數(shù)，避免秒殺工具帶來過量無效請(qǐng)求。

§ 秒殺前先做題：即在秒殺前需要先做題目，類似驗(yàn)證碼功能，其實(shí)是降低了用戶的點(diǎn)擊頻率，也限制了秒殺工具的使用。不過體驗(yàn)不好，不推薦使用。

§ 限制請(qǐng)求次數(shù)：可以用js判定，限制用戶多少時(shí)間間隔內(nèi)，只能請(qǐng)求多少次。在代理層也可以基于ip做次數(shù)限制，限制單ip的請(qǐng)求數(shù)量。

§ 直接跳轉(zhuǎn)：假設(shè)秒殺已結(jié)束或秒殺隊(duì)列已滿，對(duì)后續(xù)的請(qǐng)求，直接跳轉(zhuǎn)到秒殺結(jié)束頁(yè)面。請(qǐng)求不再到達(dá)服務(wù)端。

§ 請(qǐng)求排隊(duì)：通過消息隊(duì)列、內(nèi)存排隊(duì)等手段，對(duì)請(qǐng)求進(jìn)行排隊(duì)。類似EDA、Reactor。當(dāng)隊(duì)列滿了以后，可拒絕后續(xù)請(qǐng)求。

服務(wù)端優(yōu)化

上面的「請(qǐng)求排隊(duì)」，可以做在web服務(wù)層，也可以在服務(wù)端處理，亦可以兩處都處理。除了排隊(duì)，服務(wù)端的優(yōu)化的核心手段就是緩存，盡量減少到數(shù)據(jù)庫(kù)的數(shù)據(jù)訪問，將熱點(diǎn)數(shù)據(jù)緩存起來。

更極致的優(yōu)化可能還涉及到：

§ 減少序列化：大家都知道Java序列化和反序列化都是比較耗時(shí)的操作，即使使用第三方的序列化工具，也是需要消耗時(shí)間的，盡量減少序列化操作，能減少這部分的時(shí)間消耗

§ 不要使用框架：現(xiàn)在一般開發(fā)都會(huì)使用框架開發(fā)，例如SpringMVC。SpringMVC使用了前端控制器，還包括很多的Filter，攔截器等，額外的增加了請(qǐng)求時(shí)間。使用純Servlet，能降低此部分的時(shí)間消耗。因?yàn)楫吘姑霘⑦壿嫼?jiǎn)單，用不用框架，開發(fā)效率影響不大。

§ 使用字節(jié)流：即使用InputStream、OutputStream，不要使用Writer,Reader。與「減少序列化」類似，編解碼也會(huì)消耗時(shí)間。

另外還有扣庫(kù)存邏輯處理：

§ 拍下減庫(kù)存：用戶搶到后即扣除庫(kù)存，但是如果用戶搶到了不付款，最后秒殺的商品可能實(shí)際并沒有賣出去。

§ 付款減庫(kù)存：到用戶付款后才去扣庫(kù)存。這可能導(dǎo)致下單數(shù)量遠(yuǎn)超商品數(shù)量。導(dǎo)致的問題是，要么后付款的買家被提示付款失敗。要么就是超賣。

§ 預(yù)扣庫(kù)存：用戶搶到即扣除庫(kù)存。規(guī)定時(shí)間內(nèi)沒有付款則取消訂單，恢復(fù)庫(kù)存。這個(gè)是常用手段

上面說的秒殺系統(tǒng)的一般設(shè)計(jì)思路。然后我們就要來考慮秒殺系統(tǒng)的公平性！

公平？公平！

習(xí)慣性的思維告訴我們先到先得原則，即優(yōu)先到達(dá)的請(qǐng)求，優(yōu)先排隊(duì)下單。這就導(dǎo)致，在秒殺結(jié)束前或請(qǐng)求被處理前，都需要等待，直到服務(wù)器處理后才有返回。

這明顯增加了服務(wù)端的壓力，這也是導(dǎo)致的吞吐性能被嚴(yán)重影響到。但不是根本原因。

根本原因是這樣做就真的公平嗎？！這就要看每個(gè)人對(duì)公平的理解了！我認(rèn)為這世上「沒有絕對(duì)的公平，只有相對(duì)的公平」！

你在秒殺系統(tǒng)里排隊(duì)，保證先到先得，這就是公平嗎？

§ 如果一個(gè)買家是1M帶寬，另一個(gè)買家是100M光纖，他們同時(shí)秒殺，你能保證公平嗎？

§ 如果你的服務(wù)器在北京，北京的買家是不是比廣州的買家更容易秒殺到？你能保證公平嗎？

§ 如果一個(gè)買家是萬年死宅，手速奇快；另一個(gè)買家手不太靈活。你能保證公平嗎？

既然不能，我為什么要在服務(wù)端保證公平呢？！

我的想法

秒殺就是拼個(gè)運(yùn)氣，只要不暗箱操作，那就是公平的。所以我們不保證先到達(dá)的請(qǐng)求就能先買到商品！客戶哪知道他是不是先到的呢（雖然這樣說，看起來不公平，但實(shí)際確實(shí)是這樣）。所以我們放棄了所謂的公平。

我使用了兩個(gè)隊(duì)列：

§ 前端node隊(duì)列

§ 后端下單隊(duì)列

大致請(qǐng)求流程如下：

§ 假設(shè)商品數(shù)量為100，那可以設(shè)定node隊(duì)列長(zhǎng)度為1000，下單隊(duì)列長(zhǎng)度為100

§ 秒殺開始后，node隊(duì)列接收前端請(qǐng)求，先到先進(jìn)。當(dāng)隊(duì)列滿了以后，直接響應(yīng)后面的請(qǐng)求，秒殺失敗/結(jié)束。

§ node隊(duì)列中的數(shù)據(jù)批量傳遞給后端的下單隊(duì)列，由消費(fèi)線程從下單隊(duì)列中獲取請(qǐng)求進(jìn)行處理

§ 如果100個(gè)商品全部處理完成（下單后，規(guī)定時(shí)間內(nèi)沒有付款，取消訂單，恢復(fù)庫(kù)存），則秒殺結(jié)束

§ 如果100個(gè)商品沒有處理結(jié)束，繼續(xù)從node隊(duì)列獲取下一批數(shù)據(jù)處理

§ 如果node隊(duì)列有空余后，后續(xù)的請(qǐng)求繼續(xù)進(jìn)入隊(duì)列

§ node隊(duì)列中的請(qǐng)求設(shè)置超時(shí)，規(guī)定時(shí)間內(nèi)沒有得到處理，直接返回秒殺失敗/結(jié)束

總結(jié)

人員、技術(shù)、考量點(diǎn)的不同都會(huì)影響架構(gòu)設(shè)計(jì)。一個(gè)符合當(dāng)前人員、技術(shù)以及適合考量點(diǎn)的架構(gòu)，可能能得到意想不到的效果。