如今的互聯(lián)網(wǎng)已經(jīng)在海量服務(wù)領(lǐng)域有了很成熟的理論，在電商領(lǐng)域，存在著典型的秒殺業(yè)務(wù)場景，那何謂秒殺場景呢？簡單的來說就是一件商品的購買人數(shù)遠遠大于這件商品的庫存，而且這件商品在很短的時間內(nèi)就會被搶購一空。
高并發(fā)的接口/系統(tǒng)有一個共同的特性，那就是”快”。在系統(tǒng)其它條件既定的情況下，系統(tǒng)處理請求越快，用戶得到反饋的時間就越短，單位時間內(nèi)服務(wù)器能夠處理請求的數(shù)量就會越多。所以”快”幾乎可以算是高并發(fā)系統(tǒng)的要滿足的必要條件，要評估一個系統(tǒng)性能如何，某次優(yōu)化是否提高系統(tǒng)的容量，”快”是一個很直觀的衡量標準。
那么如何設(shè)計一個高可用、高并發(fā)秒殺系統(tǒng)呢？
秒殺系統(tǒng)一般設(shè)計思路
秒殺系統(tǒng)的特點是：
§ 瞬時請求量很高
§ 持續(xù)時間較短
所以秒殺系統(tǒng)需要解決的是「在高并發(fā)情況下，用戶請求及數(shù)據(jù)更新的問題」！
一般的設(shè)計思路：
§ （變相）擴容
§ 提高性能
具體方式有：
動靜分離
對于一般的應(yīng)用來說，請求流程大致如下：
§ 服務(wù)端接收到請求，從數(shù)據(jù)庫中查詢相應(yīng)數(shù)據(jù)
§ 選擇對應(yīng)的展示模板
§ 通過模板和數(shù)據(jù)渲染出最終頁面
§ 將頁面返回給客戶端
當訪問量很大的時候，服務(wù)器壓力會非常的大！解決方案就是動靜分離！
做軟件開發(fā)的都知道要「將變化的內(nèi)容和不變的內(nèi)容隔離開」，以便于獨立進化。這里其實也是一樣的思路。
模板是個靜態(tài)的內(nèi)容，部署后一般是不會變化的；而數(shù)據(jù)是個相對動態(tài)的內(nèi)容，根據(jù)請求參數(shù)的不同，數(shù)據(jù)可能不同。所以我們需要將模板與數(shù)據(jù)分離。
以前的做法是后端事先生成渲染后的頁面，緩存起來或直接部署到靜態(tài)服務(wù)器或CDN，請求時直接從緩存（靜態(tài)服務(wù)器/CDN）中獲取頁面，而動態(tài)數(shù)據(jù)通過AJAX請求的方式獲取。服務(wù)器不再需要渲染頁面，只需要返回少量的數(shù)據(jù)即可。既降低了服務(wù)器壓力，又減少了服務(wù)端數(shù)據(jù)的傳輸。
而現(xiàn)在很流行的前后端分離就能很容易的解決這個問題。頁面獨立部署，數(shù)據(jù)異步獲取，頁面渲染由瀏覽器負責(zé)。這里和普通的前后端分離還有些差異，需要將相對靜態(tài)的數(shù)據(jù)都靜態(tài)化，以減少動態(tài)數(shù)據(jù)量。
分離后，靜態(tài)內(nèi)容和動態(tài)內(nèi)容就可以獨立進化。例如靜態(tài)內(nèi)容可以部署到CDN上，用戶可以從最近的服務(wù)器獲取到數(shù)據(jù)。相對熱點的動態(tài)數(shù)據(jù)可以做緩存，降低數(shù)據(jù)庫壓力，進一步提高服務(wù)端響應(yīng)。
獨立部署
「獨立部署」其實也可以看成是一種「動靜分離」。將秒殺系統(tǒng)這個相對動態(tài)的系統(tǒng)，和相對靜態(tài)的業(yè)務(wù)系統(tǒng)分開部署。
原因很好理解，秒殺系統(tǒng)的請求量很大，可能會由于預(yù)估不足或系統(tǒng)問題，導(dǎo)致了秒殺系統(tǒng)的負載過高、響應(yīng)變慢。如果秒殺系統(tǒng)是業(yè)務(wù)系統(tǒng)的一部分，則會導(dǎo)致業(yè)務(wù)系統(tǒng)響應(yīng)變慢，甚至導(dǎo)致系統(tǒng)沒有響應(yīng)。且秒殺是個短期活動也不是核心業(yè)務(wù)，而業(yè)務(wù)系統(tǒng)是需要長期穩(wěn)定運行的。不能因為一個短期非核心的活動，而影響了核心的業(yè)務(wù)系統(tǒng)。
所以秒殺系統(tǒng)最好和業(yè)務(wù)系統(tǒng)分開獨立部署。即使秒殺系統(tǒng)掛了，也不會影響業(yè)務(wù)系統(tǒng)的正常對外服務(wù)。
同樣的道理，秒殺系統(tǒng)的數(shù)據(jù)庫也需要和業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫獨立開。
限流削峰
動靜分離，獨立部署能提高系統(tǒng)的響應(yīng)能力和容量。但是可提供的訪問量是一定的，當超過了系統(tǒng)所能承受的容量，該怎么辦呢？你可能會說，可以擴容啊。的確是可以，但是擴容也是有限度的。假設(shè)單機能承受10萬的請求量，預(yù)計有1億的請求量，你要擴容1000臺服務(wù)器？！這會導(dǎo)致嚴重的浪費。
首先，上面提到了，秒殺是短期活動，為了秒殺多部署1000臺服務(wù)器，秒殺結(jié)束后這些服務(wù)器再銷毀？既浪費硬件資源、又浪費人力資源。
其次，秒殺的商品數(shù)量其實并不多，可能秒殺賺的那點錢還不夠付服務(wù)器和帶寬的費用。真·花錢賺吆喝！
我們該如何處理呢？
上面說了，秒殺的商品數(shù)量不多，也就是說，其實最后的真實成交量并不大。再進一步講，很多的請求都是沒用的。
其次，在秒殺前，買家會頻繁的刷頁面，這又額外增加了無用請求的數(shù)量。
我們只要把這些無用的請求提前都過濾掉，最終到達服務(wù)端的請求就會少很多，也就不需要這么多的服務(wù)器了。這就是限流削峰。具體做法有很多：
§ 秒殺時間未到時，秒殺按鈕置灰：也就是說在秒殺未到時間時，不可發(fā)送下單請求。前面我們已經(jīng)將頁面靜態(tài)化，分發(fā)到了CDN，所以用戶的刷新操作只會到CDN。這就削除了刷新操作導(dǎo)致的請求。
§ 秒殺按鈕點擊后置灰：即避免double-click，一個用戶只能點擊一次。限制用戶點擊次數(shù)，避免秒殺工具帶來過量無效請求。
§ 秒殺前先做題：即在秒殺前需要先做題目，類似驗證碼功能，其實是降低了用戶的點擊頻率，也限制了秒殺工具的使用。不過體驗不好，不推薦使用。
§ 限制請求次數(shù)：可以用js判定，限制用戶多少時間間隔內(nèi)，只能請求多少次。在代理層也可以基于ip做次數(shù)限制，限制單ip的請求數(shù)量。
§ 直接跳轉(zhuǎn)：假設(shè)秒殺已結(jié)束或秒殺隊列已滿，對后續(xù)的請求，直接跳轉(zhuǎn)到秒殺結(jié)束頁面。請求不再到達服務(wù)端。
§ 請求排隊：通過消息隊列、內(nèi)存排隊等手段，對請求進行排隊。類似EDA、Reactor。當隊列滿了以后，可拒絕后續(xù)請求。
服務(wù)端優(yōu)化
上面的「請求排隊」，可以做在web服務(wù)層，也可以在服務(wù)端處理，亦可以兩處都處理。除了排隊，服務(wù)端的優(yōu)化的核心手段就是緩存，盡量減少到數(shù)據(jù)庫的數(shù)據(jù)訪問，將熱點數(shù)據(jù)緩存起來。
更極致的優(yōu)化可能還涉及到：
§ 減少序列化：大家都知道Java序列化和反序列化都是比較耗時的操作，即使使用第三方的序列化工具，也是需要消耗時間的，盡量減少序列化操作，能減少這部分的時間消耗
§ 不要使用框架：現(xiàn)在一般開發(fā)都會使用框架開發(fā)，例如SpringMVC。SpringMVC使用了前端控制器，還包括很多的Filter，攔截器等，額外的增加了請求時間。使用純Servlet，能降低此部分的時間消耗。因為畢竟秒殺邏輯簡單，用不用框架，開發(fā)效率影響不大。
§ 使用字節(jié)流：即使用InputStream、OutputStream，不要使用Writer,Reader。與「減少序列化」類似，編解碼也會消耗時間。
另外還有扣庫存邏輯處理：
§ 拍下減庫存：用戶搶到后即扣除庫存，但是如果用戶搶到了不付款，最后秒殺的商品可能實際并沒有賣出去。
§ 付款減庫存：到用戶付款后才去扣庫存。這可能導(dǎo)致下單數(shù)量遠超商品數(shù)量。導(dǎo)致的問題是，要么后付款的買家被提示付款失敗。要么就是超賣。
§ 預(yù)扣庫存：用戶搶到即扣除庫存。規(guī)定時間內(nèi)沒有付款則取消訂單，恢復(fù)庫存。這個是常用手段
上面說的秒殺系統(tǒng)的一般設(shè)計思路。然后我們就要來考慮秒殺系統(tǒng)的公平性！
公平？公平！
習(xí)慣性的思維告訴我們先到先得原則，即優(yōu)先到達的請求，優(yōu)先排隊下單。這就導(dǎo)致，在秒殺結(jié)束前或請求被處理前，都需要等待，直到服務(wù)器處理后才有返回。
這明顯增加了服務(wù)端的壓力，這也是導(dǎo)致的吞吐性能被嚴重影響到。但不是根本原因。
根本原因是這樣做就真的公平嗎？！這就要看每個人對公平的理解了！我認為這世上「沒有絕對的公平，只有相對的公平」！
你在秒殺系統(tǒng)里排隊，保證先到先得，這就是公平嗎？
§ 如果一個買家是1M帶寬，另一個買家是100M光纖，他們同時秒殺，你能保證公平嗎？
§ 如果你的服務(wù)器在北京，北京的買家是不是比廣州的買家更容易秒殺到？你能保證公平嗎？
§ 如果一個買家是萬年死宅，手速奇快；另一個買家手不太靈活。你能保證公平嗎？
既然不能，為什么要在服務(wù)端保證公平呢？！
秒殺就是拼個運氣，只要不暗箱操作，那就是公平的。所以我們不保證先到達的請求就能先買到商品！客戶哪知道他是不是先到的呢（雖然這樣說，看起來不公平，但實際確實是這樣）。所以放棄了所謂的公平。
使用了兩個隊列：
§ 前端node隊列
§ 后端下單隊列
大致請求流程如下：
§ 假設(shè)商品數(shù)量為100，那可以設(shè)定node隊列長度為1000，下單隊列長度為100
§ 秒殺開始后，node隊列接收前端請求，先到先進。當隊列滿了以后，直接響應(yīng)后面的請求，秒殺失敗/結(jié)束。
§ node隊列中的數(shù)據(jù)批量傳遞給后端的下單隊列，由消費線程從下單隊列中獲取請求進行處理
§ 如果100個商品全部處理完成（下單后，規(guī)定時間內(nèi)沒有付款，取消訂單，恢復(fù)庫存），則秒殺結(jié)束
§ 如果100個商品沒有處理結(jié)束，繼續(xù)從node隊列獲取下一批數(shù)據(jù)處理
§ 如果node隊列有空余后，后續(xù)的請求繼續(xù)進入隊列
§ node隊列中的請求設(shè)置超時，規(guī)定時間內(nèi)沒有得到處理，直接返回秒殺失敗/結(jié)束
總結(jié)
人員、技術(shù)、考量點的不同都會影響架構(gòu)設(shè)計。一個符合當前人員、技術(shù)以及適合考量點的架構(gòu)，可能能得到意想不到的效果。
目前晨通信息科技有限公司在汕頭珠港新城，聯(lián)泰時代總部中心3棟10樓，歡迎廣大客戶通過電話、微信咨詢了解，電話是：18923665588，也可以撥打免費電話：400-830-3889。
掃碼關(guān)注公眾號
隨時隨地
掌握第一手資訊
相關(guān)資訊
