1、抽獎系統(tǒng)的背景引入

本文給大家分享一個之前經(jīng)歷過的抽獎系統(tǒng)的流量削峰架構(gòu)的設(shè)計方案。

抽獎、搶紅包、秒殺，這類系統(tǒng)其實都有一些共同的特點，那就是在某個時間點會瞬間涌入大量的人來點擊系統(tǒng)，給系統(tǒng)造成瞬間高于平時百倍、千倍甚至幾十萬倍的流量壓力。

比如抽獎，有一種場景：某個網(wǎng)站或者APP規(guī)定好了在某個時間點，所有人都可以參與抽獎，那么可能百萬級的用戶會蹲守在那個時間點，到時間大家一起參與這個抽獎。

搶紅包，可能是某個電視節(jié)目上，突然說掃碼可以搶紅包，那么電視機(jī)前可能千萬級的用戶會瞬間一起打開手機(jī)掃碼搶紅包。

秒殺更是如此，所謂秒殺，意思是讓大家都在電腦前等著，在某個時間突然就可以搶購某個限量的商品

比如某個手機(jī)平時賣5999，現(xiàn)在限量100臺價格才2999，50%的折扣，可能百萬級的用戶就會蹲守在電腦前在比如凌晨12點一起點擊按鈕搶購這款手機(jī)。

類似的場景其實現(xiàn)在是很多的，那么本文就用一個抽獎系統(tǒng)舉例，說說應(yīng)對這種瞬時超高并發(fā)的流量，應(yīng)該如何設(shè)計流量削峰的架構(gòu)來應(yīng)對，才能保證系統(tǒng)不會突然跨掉？

2、結(jié)合具體業(yè)務(wù)需求分析抽獎系統(tǒng)

假設(shè)現(xiàn)在有一個抽獎的業(yè)務(wù)場景，用戶在某個時間可以參與抽獎，比如一共有1萬個獎，獎品就是某個禮物。

然后參與抽獎的用戶可能有幾十萬，一瞬間可能幾十萬請求涌入過來，接著瞬間其中1萬人中獎了，剩余的人都是沒中獎的。然后中獎的1萬人的請求會聯(lián)動調(diào)用禮品服務(wù)，完成這1萬中獎人的禮品發(fā)放。

簡單來說，需求場景就是如此，然而這里就有很多的地方值得優(yōu)化了。

3、一個未經(jīng)過優(yōu)化的系統(tǒng)架構(gòu)

先來看一個未經(jīng)過任何優(yōu)化的系統(tǒng)架構(gòu)，簡單來說就是有一個負(fù)載均衡的設(shè)備會把瞬間涌入的超高并發(fā)的流量轉(zhuǎn)發(fā)到后臺的抽獎服務(wù)上。

這個抽獎服務(wù)就是用普通的Tomcat來部署的，里面實現(xiàn)了具體的抽獎邏輯，假設(shè)剛開始最常規(guī)的抽獎邏輯是基于MySQL來實現(xiàn)的，接著就是基于Tomcat部署的禮品服務(wù)，抽獎服務(wù)如果發(fā)現(xiàn)中獎了需要調(diào)用禮品服務(wù)去發(fā)放禮品。

如下圖所示：

4、負(fù)載均衡層的限流

4.1 防止用戶重復(fù)抽獎

首先第一次在負(fù)載均衡層可以做的事情，就是防止重復(fù)抽獎。

我們可以在負(fù)載均衡設(shè)備中做一些配置，判斷如果同一個用戶在1分鐘之內(nèi)多次發(fā)送請求來進(jìn)行抽獎，就認(rèn)為是惡意重復(fù)抽獎，或者是他們自己寫的腳本在刷獎，這種流量一律認(rèn)為是無效流量，在負(fù)載均衡設(shè)備那個層次就給直接屏蔽掉。

舉個例子，比如有幾十萬用戶瞬間同時抽獎，最多其實也就幾十萬請求而已，但是如果有人重復(fù)抽獎或者是寫腳本刷獎，那可能瞬間涌入的是幾百萬的請求，就不是幾十萬的請求了，所以這里就可以把無效流量給攔截掉。

如下圖所示：

4.2 全部開獎后暴力攔截流量

其實秒殺、搶紅包、抽獎，這類系統(tǒng)有一個共同的特點，那就是假設(shè)有50萬請求涌入進(jìn)來，可能前5萬請求就直接把事兒干完了，甚至是前500請求就把事兒干完了，后續(xù)的幾十萬流量是無效的，不需要讓他們進(jìn)入后臺系統(tǒng)執(zhí)行業(yè)務(wù)邏輯了。

什么意思呢？

舉個例子，秒殺商品，假設(shè)有50萬人搶一個特價手機(jī)，人家就準(zhǔn)備了100臺手機(jī)，那么50萬請求瞬間涌入，其實前500個請求就把手機(jī)搶完了，后續(xù)的幾十萬請求沒必要讓他轉(zhuǎn)發(fā)到Tomcat服務(wù)中去執(zhí)行秒殺業(yè)務(wù)邏輯了，不是嗎？

抽獎、紅包都是一樣的 ，可能50萬請求涌入，但是前1萬個請求就把獎品都抽完了，或者把紅包都搶完了，后續(xù)的流量其實已經(jīng)不需要放到Tomcat抽獎服務(wù)上去了，直接暴力攔截返回抽獎結(jié)束就可以了。

這樣的話，其實在負(fù)載均衡這一層（可以考慮用Nginx之類的來實現(xiàn)）就可以攔截掉99%的無效流量。

所以必須讓抽獎服務(wù)跟負(fù)載均衡之間有一個狀態(tài)共享的機(jī)制。

就是說抽獎服務(wù)一旦全部開獎完畢，直接更新一個共享狀態(tài)。然后負(fù)載均衡感知到了之后，后續(xù)請求全部攔截掉返回一個抽獎結(jié)束的標(biāo)識就可以了。

這么做可能就會做到50萬人一起請求，結(jié)果就可能2萬請求到了后臺的Tomcat抽獎服務(wù)中，48萬請求直接攔截掉了。

我們可以基于Redis來實現(xiàn)這種共享抽獎狀態(tài)，它非常輕量級，很適合兩個層次的系統(tǒng)的共享訪問。

當(dāng)然其實用ZooKeeper也是可以的，在負(fù)載均衡層可以基于zk客戶端監(jiān)聽某個znode節(jié)點狀態(tài)。一旦抽獎結(jié)束，抽獎服務(wù)更新zk狀態(tài)，負(fù)載均衡層會感知到。

下圖展示了上述所說的過程：

5、Tomcat線程數(shù)量的優(yōu)化

其次就是對于線上生產(chǎn)環(huán)境的Tomcat，有一個至關(guān)重要的參數(shù)是需要根據(jù)自己的情況調(diào)節(jié)好的，那就是他的工作線程數(shù)量。

眾所周知，對于進(jìn)入Tomcat的每個請求，其實都會交給一個獨(dú)立的工作線程來進(jìn)行處理，那么Tomcat有多少線程，就決定了并發(fā)請求處理的能力。

但是這個線程數(shù)量是需要經(jīng)過壓測來進(jìn)行判斷的，因為每個線程都會處理一個請求，這個請求又需要訪問數(shù)據(jù)庫之類的外部系統(tǒng)，所以不是每個系統(tǒng)的參數(shù)都可以一樣的，需要自己對系統(tǒng)進(jìn)行壓測。

但是給一個經(jīng)驗值的話，Tomcat的線程數(shù)量不宜過多。因為線程過多，普通虛擬機(jī)的CPU是扛不住的，反而會導(dǎo)致機(jī)器CPU負(fù)載過高，最終崩潰。

同時，Tomcat的線程數(shù)量也不宜太少，因為如果就100個線程，那么會導(dǎo)致無法充分利用Tomcat的線程資源和機(jī)器的CPU資源。

所以一般來說，Tomcat線程數(shù)量在200~500之間都是可以的，但是具體多少需要自己壓測一下，不斷的調(diào)節(jié)參數(shù)，看具體的CPU負(fù)載以及線程執(zhí)行請求的一個效率。

在CPU負(fù)載尚可，以及請求執(zhí)行性能正常的情況下，盡可能提高一些線程數(shù)量。

但是如果到一個臨界值，發(fā)現(xiàn)機(jī)器負(fù)載過高，而且線程處理請求的速度開始下降，說明這臺機(jī)扛不住這么多線程并發(fā)執(zhí)行處理請求了，此時就不能繼續(xù)上調(diào)線程數(shù)量了。

6、基于Redis實現(xiàn)抽獎業(yè)務(wù)邏輯

現(xiàn)在問題又來了，雖然在負(fù)載均衡那個層面，已經(jīng)把比如50萬流量中的48萬都攔截掉了，但是可能還是會有2萬流量進(jìn)入抽獎服務(wù)

此時抽獎服務(wù)自然是可以多機(jī)器來部署的，比如假設(shè)一臺Tomcat可以抗500請求，那么2萬并發(fā)就是40臺機(jī)器。

如果你是基于云平臺來部署系統(tǒng)的，搞活動臨時租用一批機(jī)器就可以了，活動結(jié)束了機(jī)器立馬可以釋放掉，現(xiàn)在云平臺都很方便。

但是有個問題，你的數(shù)據(jù)庫MySQL能抗住2萬的并發(fā)請求嗎？

如果你基于MySQL來實現(xiàn)核心的抽獎業(yè)務(wù)邏輯，40個Tomcat部署的抽獎服務(wù)頻繁對MySQL進(jìn)行增刪改查，這一個MySQL實例也是很難抗住的。

所以此時還得把MySQL給替換成Redis，通常這種場景下，建議是基于Redis來實現(xiàn)核心的業(yè)務(wù)邏輯。

Redis單機(jī)抗2萬并發(fā)那是很輕松的一件事情，所以在這里又需要做進(jìn)一步的優(yōu)化。如下圖：

7、發(fā)放禮品環(huán)節(jié)進(jìn)行限流削峰

接著問題又來了，假設(shè)抽獎服務(wù)在2萬請求中有1萬請求抽中了獎品，那么勢必會造成抽獎服務(wù)對禮品服務(wù)調(diào)用1萬次。

禮品服務(wù)假設(shè)也是優(yōu)化后的Tomcat，可以抗500并發(fā)，難道禮品服務(wù)也要去部署20臺機(jī)器嗎？

其實這是沒必要的，因為抽獎之后完全可以讓禮品服務(wù)在后臺慢慢的把中獎的禮品給發(fā)放出去，不需要一下子就立馬對1萬個請求完成禮品的發(fā)放邏輯。

所以這里可以在抽獎服務(wù)和禮品服務(wù)之間，引入消息中間件，進(jìn)行限流削峰。

也就是說，抽獎服務(wù)把中獎信息發(fā)送到MQ，然后禮品服務(wù)假設(shè)就部署兩個Tomcat，慢慢的從MQ中消費(fèi)中獎消息，然后慢慢完成1完禮品的發(fā)放就可以了。

假設(shè)兩個禮品服務(wù)實例每秒可以完成100個禮品的發(fā)放，那么1萬個禮品也就是延遲100秒發(fā)放完畢罷了。

也就是你抽獎之后，可能過了一兩分鐘，會看到自己的禮品發(fā)放的一些物流配送的進(jìn)度之類的。

而且禮品服務(wù)可能需要在MySQL數(shù)據(jù)庫中做很多增刪改查的操作，比如插入中獎紀(jì)錄，然后進(jìn)行禮品發(fā)貨等等。

此時因為禮品服務(wù)就2個Tomcat實例，所以對MySQL的并發(fā)讀寫不會太高，那么數(shù)據(jù)庫層面也是可以抗住的。

整個過程，如下圖所示：

8、系統(tǒng)架構(gòu)設(shè)計總結(jié)

其實對于商品秒殺、抽獎活動、搶紅包類的系統(tǒng)而言，架構(gòu)設(shè)計的思路很多都是類似的，核心思路都是對于這種瞬時超高流量的系統(tǒng)，盡可能在負(fù)載均衡層就把99%的無效流量攔截掉

然后在1%的流量進(jìn)入核心業(yè)務(wù)服務(wù)后，此時每秒并發(fā)還是可能會上萬，那么可以基于Redis實現(xiàn)核心業(yè)務(wù)邏輯 ，抗住上萬并發(fā)。

最后對于類似秒殺商品發(fā)貨、抽獎商品發(fā)貨、紅包資金轉(zhuǎn)賬之類的非常耗時的操作，完全可以基于MQ來限流削峰，后臺有一個服務(wù)慢慢執(zhí)行即可。

歡迎工作一到五年的Java工程師朋友們加入Java程序員開發(fā)： 721575865

群內(nèi)提供免費(fèi)的Java架構(gòu)學(xué)習(xí)資料（里面有高可用、高并發(fā)、高性能及分布式、Jvm性能調(diào)優(yōu)、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構(gòu)資料）合理利用自己每一分每一秒的時間來學(xué)習(xí)提升自己，不要再用”沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！