如今的互聯(lián)網(wǎng)已經(jīng)在海量服務(wù)領(lǐng)域有了很成熟的理論，在電商領(lǐng)域，存在著典型的秒殺業(yè)務(wù)場景，那何謂秒殺場景呢？簡單的來說就是一件商品的購買人數(shù)遠(yuǎn)遠(yuǎn)大于這件商品的庫存，而且這件商品在很短的時(shí)間內(nèi)就會(huì)被搶購一空。
高并發(fā)的接口/系統(tǒng)有一個(gè)共同的特性，那就是”快”。在系統(tǒng)其它條件既定的情況下，系統(tǒng)處理請(qǐng)求越快，用戶得到反饋的時(shí)間就越短，單位時(shí)間內(nèi)服務(wù)器能夠處理請(qǐng)求的數(shù)量就會(huì)越多。所以”快”幾乎可以算是高并發(fā)系統(tǒng)的要滿足的必要條件，要評(píng)估一個(gè)系統(tǒng)性能如何，某次優(yōu)化是否提高系統(tǒng)的容量，”快”是一個(gè)很直觀的衡量標(biāo)準(zhǔn)。
那么如何設(shè)計(jì)一個(gè)高可用、高并發(fā)秒殺系統(tǒng)呢？
秒殺系統(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ù)庫中查詢相應(yīng)數(shù)據(jù)
§ 選擇對(duì)應(yīng)的展示模板
§ 通過模板和數(shù)據(jù)渲染出最終頁面
§ 將頁面返回給客戶端
當(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ù)分離。
以前的做法是后端事先生成渲染后的頁面，緩存起來或直接部署到靜態(tài)服務(wù)器或CDN，請(qǐng)求時(shí)直接從緩存（靜態(tài)服務(wù)器/CDN）中獲取頁面，而動(dòng)態(tài)數(shù)據(jù)通過AJAX請(qǐng)求的方式獲取。服務(wù)器不再需要渲染頁面，只需要返回少量的數(shù)據(jù)即可。既降低了服務(wù)器壓力，又減少了服務(wù)端數(shù)據(jù)的傳輸。
而現(xiàn)在很流行的前后端分離就能很容易的解決這個(gè)問題。頁面獨(dú)立部署，數(shù)據(jù)異步獲取，頁面渲染由瀏覽器負(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ù)庫壓力，進(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)是需要長期穩(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ù)庫也需要和業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫獨(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è)撊绾翁幚砟兀?/p>
上面說了，秒殺的商品數(shù)量不多，也就是說，其實(shí)最后的真實(shí)成交量并不大。再進(jìn)一步講，很多的請(qǐng)求都是沒用的。
其次，在秒殺前，買家會(huì)頻繁的刷頁面，這又額外增加了無用請(qǐng)求的數(shù)量。
我們只要把這些無用的請(qǐng)求提前都過濾掉，最終到達(dá)服務(wù)端的請(qǐng)求就會(huì)少很多，也就不需要這么多的服務(wù)器了。這就是限流削峰。具體做法有很多：
§ 秒殺時(shí)間未到時(shí)，秒殺按鈕置灰：也就是說在秒殺未到時(shí)間時(shí)，不可發(fā)送下單請(qǐng)求。前面我們已經(jīng)將頁面靜態(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é)束頁面。請(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ù)庫的數(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)楫吘姑霘⑦壿嫼唵?，用不用框架，開發(fā)效率影響不大。
§ 使用字節(jié)流：即使用InputStream、OutputStream，不要使用Writer,Reader。與「減少序列化」類似，編解碼也會(huì)消耗時(shí)間。
另外還有扣庫存邏輯處理：
§ 拍下減庫存：用戶搶到后即扣除庫存，但是如果用戶搶到了不付款，最后秒殺的商品可能實(shí)際并沒有賣出去。
§ 付款減庫存：到用戶付款后才去扣庫存。這可能導(dǎo)致下單數(shù)量遠(yuǎn)超商品數(shù)量。導(dǎo)致的問題是，要么后付款的買家被提示付款失敗。要么就是超賣。
§ 預(yù)扣庫存：用戶搶到即扣除庫存。規(guī)定時(shí)間內(nèi)沒有付款則取消訂單，恢復(fù)庫存。這個(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ì)列長度為1000，下單隊(duì)列長度為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ù)庫存），則秒殺結(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)，可能能得到意想不到的效果。
目前晨通信息科技有限公司在汕頭珠港新城，聯(lián)泰時(shí)代總部中心3棟10樓，歡迎廣大客戶通過電話、微信咨詢了解，電話是：18923665588，也可以撥打免費(fèi)電話：400-830-3889。
掃碼關(guān)注公眾號(hào)
隨時(shí)隨地
掌握第一手資訊
相關(guān)資訊
