摘要:如下圖所示負載均衡層的限流防止用戶重復(fù)抽獎首先第一次在負載均衡層可以做的事情,就是防止重復(fù)抽獎。然后負載均衡感知到了之后,后續(xù)請求全部攔截掉返回一個抽獎結(jié)束的標識就可以了。一旦抽獎結(jié)束,抽獎服務(wù)更新狀態(tài),負載均衡層會感知到。
公眾號:貍貓技術(shù)窩作者:愛釣魚的桌子哥,資深架構(gòu)師
1、抽獎系統(tǒng)的背景引入
本文給大家分享一個之前經(jīng)歷過的抽獎系統(tǒng)的流量削峰架構(gòu)的設(shè)計方案。
抽獎、搶紅包、秒殺,這類系統(tǒng)其實都有一些共同的特點,那就是在某個時間點會瞬間涌入大量的人來點擊系統(tǒng),給系統(tǒng)造成瞬間高于平時百倍、千倍甚至幾十萬倍的流量壓力。
比如抽獎,有一種場景:某個網(wǎng)站或者APP規(guī)定好了在某個時間點,所有人都可以參與抽獎,那么可能百萬級的用戶會蹲守在那個時間點,到時間大家一起參與這個抽獎。
搶紅包,可能是某個電視節(jié)目上,突然說掃碼可以搶紅包,那么電視機前可能千萬級的用戶會瞬間一起打開手機掃碼搶紅包。
秒殺更是如此,所謂秒殺,意思是讓大家都在電腦前等著,在某個時間突然就可以搶購某個限量的商品
比如某個手機平時賣5999,現(xiàn)在限量100臺價格才2999,50%的折扣,可能百萬級的用戶就會蹲守在電腦前在比如凌晨12點一起點擊按鈕搶購這款手機。
類似的場景其實現(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),簡單來說就是有一個負載均衡的設(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、負載均衡層的限流
4.1 防止用戶重復(fù)抽獎
首先第一次在負載均衡層可以做的事情,就是防止重復(fù)抽獎。
我們可以在負載均衡設(shè)備中做一些配置,判斷如果同一個用戶在1分鐘之內(nèi)多次發(fā)送請求來進行抽獎,就認為是惡意重復(fù)抽獎,或者是他們自己寫的腳本在刷獎,這種流量一律認為是無效流量,在負載均衡設(shè)備那個層次就給直接屏蔽掉。
舉個例子,比如有幾十萬用戶瞬間同時抽獎,最多其實也就幾十萬請求而已,但是如果有人重復(fù)抽獎或者是寫腳本刷獎,那可能瞬間涌入的是幾百萬的請求,就不是幾十萬的請求了,所以這里就可以把無效流量給攔截掉。
如下圖所示:
4.2 全部開獎后暴力攔截流量
其實秒殺、搶紅包、抽獎,這類系統(tǒng)有一個共同的特點,那就是假設(shè)有50萬請求涌入進來,可能前5萬請求就直接把事兒干完了,甚至是前500請求就把事兒干完了,后續(xù)的幾十萬流量是無效的,不需要讓他們進入后臺系統(tǒng)執(zhí)行業(yè)務(wù)邏輯了。
什么意思呢?
舉個例子,秒殺商品,假設(shè)有50萬人搶一個特價手機,人家就準備了100臺手機,那么50萬請求瞬間涌入,其實前500個請求就把手機搶完了,后續(xù)的幾十萬請求沒必要讓他轉(zhuǎn)發(fā)到Tomcat服務(wù)中去執(zhí)行秒殺業(yè)務(wù)邏輯了,不是嗎?
抽獎、紅包都是一樣的 ,可能50萬請求涌入,但是前1萬個請求就把獎品都抽完了,或者把紅包都搶完了,后續(xù)的流量其實已經(jīng)不需要放到Tomcat抽獎服務(wù)上去了,直接暴力攔截返回抽獎結(jié)束就可以了。
這樣的話,其實在負載均衡這一層(可以考慮用Nginx之類的來實現(xiàn))就可以攔截掉99%的無效流量。
所以必須讓抽獎服務(wù)跟負載均衡之間有一個狀態(tài)共享的機制。
就是說抽獎服務(wù)一旦全部開獎完畢,直接更新一個共享狀態(tài)。然后負載均衡感知到了之后,后續(xù)請求全部攔截掉返回一個抽獎結(jié)束的標識就可以了。
這么做可能就會做到50萬人一起請求,結(jié)果就可能2萬請求到了后臺的Tomcat抽獎服務(wù)中,48萬請求直接攔截掉了。
我們可以基于Redis來實現(xiàn)這種共享抽獎狀態(tài),它非常輕量級,很適合兩個層次的系統(tǒng)的共享訪問。
當(dāng)然其實用ZooKeeper也是可以的,在負載均衡層可以基于zk客戶端監(jiān)聽某個znode節(jié)點狀態(tài)。一旦抽獎結(jié)束,抽獎服務(wù)更新zk狀態(tài),負載均衡層會感知到。
下圖展示了上述所說的過程:
5、Tomcat線程數(shù)量的優(yōu)化
其次就是對于線上生產(chǎn)環(huán)境的Tomcat,有一個至關(guān)重要的參數(shù)是需要根據(jù)自己的情況調(diào)節(jié)好的,那就是他的工作線程數(shù)量。
眾所周知,對于進入Tomcat的每個請求,其實都會交給一個獨立的工作線程來進行處理,那么Tomcat有多少線程,就決定了并發(fā)請求處理的能力。
但是這個線程數(shù)量是需要經(jīng)過壓測來進行判斷的,因為每個線程都會處理一個請求,這個請求又需要訪問數(shù)據(jù)庫之類的外部系統(tǒng),所以不是每個系統(tǒng)的參數(shù)都可以一樣的,需要自己對系統(tǒng)進行壓測。
但是給一個經(jīng)驗值的話,Tomcat的線程數(shù)量不宜過多。因為線程過多,普通虛擬機的CPU是扛不住的,反而會導(dǎo)致機器CPU負載過高,最終崩潰。
同時,Tomcat的線程數(shù)量也不宜太少,因為如果就100個線程,那么會導(dǎo)致無法充分利用Tomcat的線程資源和機器的CPU資源。
所以一般來說,Tomcat線程數(shù)量在200~500之間都是可以的,但是具體多少需要自己壓測一下,不斷的調(diào)節(jié)參數(shù),看具體的CPU負載以及線程執(zhí)行請求的一個效率。
在CPU負載尚可,以及請求執(zhí)行性能正常的情況下,盡可能提高一些線程數(shù)量。
但是如果到一個臨界值,發(fā)現(xiàn)機器負載過高,而且線程處理請求的速度開始下降,說明這臺機扛不住這么多線程并發(fā)執(zhí)行處理請求了,此時就不能繼續(xù)上調(diào)線程數(shù)量了。
6、基于Redis實現(xiàn)抽獎業(yè)務(wù)邏輯
現(xiàn)在問題又來了,雖然在負載均衡那個層面,已經(jīng)把比如50萬流量中的48萬都攔截掉了,但是可能還是會有2萬流量進入抽獎服務(wù)
此時抽獎服務(wù)自然是可以多機器來部署的,比如假設(shè)一臺Tomcat可以抗500請求,那么2萬并發(fā)就是40臺機器。
如果你是基于云平臺來部署系統(tǒng)的,搞活動臨時租用一批機器就可以了,活動結(jié)束了機器立馬可以釋放掉,現(xiàn)在云平臺都很方便。
但是有個問題,你的數(shù)據(jù)庫MySQL能抗住2萬的并發(fā)請求嗎?
如果你基于MySQL來實現(xiàn)核心的抽獎業(yè)務(wù)邏輯,40個Tomcat部署的抽獎服務(wù)頻繁對MySQL進行增刪改查,這一個MySQL實例也是很難抗住的。
所以此時還得把MySQL給替換成Redis,通常這種場景下,建議是基于Redis來實現(xiàn)核心的業(yè)務(wù)邏輯。
Redis單機抗2萬并發(fā)那是很輕松的一件事情,所以在這里又需要做進一步的優(yōu)化。如下圖:
7、發(fā)放禮品環(huán)節(jié)進行限流削峰
接著問題又來了,假設(shè)抽獎服務(wù)在2萬請求中有1萬請求抽中了獎品,那么勢必會造成抽獎服務(wù)對禮品服務(wù)調(diào)用1萬次。
禮品服務(wù)假設(shè)也是優(yōu)化后的Tomcat,可以抗500并發(fā),難道禮品服務(wù)也要去部署20臺機器嗎?
其實這是沒必要的,因為抽獎之后完全可以讓禮品服務(wù)在后臺慢慢的把中獎的禮品給發(fā)放出去,不需要一下子就立馬對1萬個請求完成禮品的發(fā)放邏輯。
所以這里可以在抽獎服務(wù)和禮品服務(wù)之間,引入消息中間件,進行限流削峰。
也就是說,抽獎服務(wù)把中獎信息發(fā)送到MQ,然后禮品服務(wù)假設(shè)就部署兩個Tomcat,慢慢的從MQ中消費中獎消息,然后慢慢完成1完禮品的發(fā)放就可以了。
假設(shè)兩個禮品服務(wù)實例每秒可以完成100個禮品的發(fā)放,那么1萬個禮品也就是延遲100秒發(fā)放完畢罷了。
也就是你抽獎之后,可能過了一兩分鐘,會看到自己的禮品發(fā)放的一些物流配送的進度之類的。
而且禮品服務(wù)可能需要在MySQL數(shù)據(jù)庫中做很多增刪改查的操作,比如插入中獎紀錄,然后進行禮品發(fā)貨等等。
此時因為禮品服務(wù)就2個Tomcat實例,所以對MySQL的并發(fā)讀寫不會太高,那么數(shù)據(jù)庫層面也是可以抗住的。
整個過程,如下圖所示:
8、系統(tǒng)架構(gòu)設(shè)計總結(jié)
其實對于商品秒殺、抽獎活動、搶紅包類的系統(tǒng)而言,架構(gòu)設(shè)計的思路很多都是類似的,核心思路都是對于這種瞬時超高流量的系統(tǒng),盡可能在負載均衡層就把99%的無效流量攔截掉
然后在1%的流量進入核心業(yè)務(wù)服務(wù)后,此時每秒并發(fā)還是可能會上萬,那么可以基于Redis實現(xiàn)核心業(yè)務(wù)邏輯 ,抗住上萬并發(fā)。
最后對于類似秒殺商品發(fā)貨、抽獎商品發(fā)貨、紅包資金轉(zhuǎn)賬之類的非常耗時的操作,完全可以基于MQ來限流削峰,后臺有一個服務(wù)慢慢執(zhí)行即可。
作者簡介:
愛釣魚的桌子哥,資深架構(gòu)師
作者先后工作于滴滴、百度、字節(jié)跳動等國內(nèi)一線互聯(lián)網(wǎng)大廠,從事基礎(chǔ)架構(gòu)相關(guān)工作。帶領(lǐng)團隊設(shè)計與構(gòu)建了大規(guī)模的分布式存儲系統(tǒng)、分布式消息中間件、分布式數(shù)據(jù)庫,對分布式架構(gòu)設(shè)計、系統(tǒng)高可用體系構(gòu)建、基礎(chǔ)中間件架構(gòu)都有豐富的經(jīng)驗。
END
長按下圖二維碼,即刻關(guān)注【貍貓技術(shù)窩】 阿里、京東、美團、字節(jié)跳動 頂尖技術(shù)專家坐鎮(zhèn) 為IT人打造一個 “有溫度” 的技術(shù)窩!
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/6645.html
摘要:閱讀原文如何高效導(dǎo)出百萬級數(shù)據(jù)在一個具有統(tǒng)計功能的系統(tǒng)中,導(dǎo)出功能幾乎是一定的,如何導(dǎo)出導(dǎo)出的數(shù)據(jù)有多少如何高效的導(dǎo)出簡介什么是就不用介紹了,這里主要說明不同版本下每個下的行列限制。 閱讀原文:POI如何高效導(dǎo)出百萬級Excel數(shù)據(jù)? 在一個具有統(tǒng)計功能的系統(tǒng)中,導(dǎo)出excel功能幾乎是一定的,如何導(dǎo)出excel?導(dǎo)出的數(shù)據(jù)有多少?如何高效的導(dǎo)出? Excel簡介什么是excel就不用...
摘要:同盾技術(shù)總監(jiān)張新波在第二期移動時代互聯(lián)網(wǎng)金融的架構(gòu)趨勢中闡述了同盾是如何從零開始打造千萬級實時風(fēng)控云服務(wù),具體介紹了同盾系統(tǒng)平臺構(gòu)建過程中主要需要解決的三大難題,以及解決這些問題的具體時實踐過程。 同盾科技,是由阿里、Paypal 反欺詐專家創(chuàng)建的,國內(nèi)第一家風(fēng)險控制與反欺詐云服務(wù)提供商,其涉及領(lǐng)域包括電商、B2B、互聯(lián)網(wǎng)金融、游戲等。同盾技術(shù)總監(jiān)張新波在 UPYUN Open ...
閱讀 1535·2023-04-26 02:08
閱讀 3128·2021-10-14 09:42
閱讀 7177·2021-09-22 15:34
閱讀 3236·2019-08-30 13:16
閱讀 2718·2019-08-26 13:49
閱讀 1342·2019-08-26 11:59
閱讀 1251·2019-08-26 10:31
閱讀 2170·2019-08-23 17:19