需求出現(xiàn)

年會(huì)將近，而年會(huì)抽獎(jiǎng)環(huán)節(jié)必不可少亭姥，但是抽獎(jiǎng)系統(tǒng)卻還沒(méi)有。所以某一天顾稀，PM走過(guò)來(lái)說(shuō)：小伙达罗，手頭的需求修完成了吧！在年會(huì)開(kāi)始之前必須做出一個(gè)抽獎(jiǎng)系統(tǒng)础拨。這個(gè)系統(tǒng)很簡(jiǎn)單氮块，后臺(tái)可以設(shè)置總金額，然后每個(gè)用戶(hù)可以獲得的金額范圍诡宗，金額派完則顯示很遺憾沒(méi)有中獎(jiǎng)滔蝉，還要設(shè)置抽獎(jiǎng)活動(dòng)時(shí)間。

抽獎(jiǎng)系統(tǒng)業(yè)務(wù)分析圖

需求分析

一看這東西塔沃，就覺(jué)得非常簡(jiǎn)單蝠引。最簡(jiǎn)單的一個(gè)方案，活動(dòng)時(shí)間放在一個(gè)數(shù)據(jù)表蛀柴，總金額和已經(jīng)使用金額存放在一個(gè)表螃概，已經(jīng)派送的日志一個(gè)表。后臺(tái)提供一個(gè)接口鸽疾，客戶(hù)端手動(dòng)點(diǎn)擊按鈕吊洼，則發(fā)送一個(gè)請(qǐng)求。賬號(hào)體系直接使用微信的oauth制肮，接口首先判斷活動(dòng)有沒(méi)有開(kāi)始冒窍，如果開(kāi)始則隨機(jī)一個(gè)金額，然后判斷如果派送該金額會(huì)不會(huì)超預(yù)算豺鼻，如果不超預(yù)算综液，則調(diào)用微信的現(xiàn)金接口發(fā)放零錢(qián)。

最原始的架構(gòu)設(shè)計(jì)圖

并發(fā)問(wèn)題

這個(gè)簡(jiǎn)單方案存在一個(gè)致命的問(wèn)題儒飒，就是并發(fā)下谬莹，可能導(dǎo)致超預(yù)算的問(wèn)題。如果采用加鎖的方式，面對(duì)1000多員工同時(shí)請(qǐng)求附帽，系統(tǒng)100%癱瘓埠戳。（因?yàn)槌楠?jiǎng)系統(tǒng)的服務(wù)器是最普通的1核1G 1M帶寬的服務(wù)器）

超預(yù)算問(wèn)題觸發(fā)情況

那么不加鎖的情況，又能如何避免并發(fā)造成的派送超過(guò)預(yù)算的問(wèn)題呢士葫？
一個(gè)簡(jiǎn)單的辦法乞而，把分配派送金額的操作從并行變成串行。那么就需要異步的編程方法慢显。最簡(jiǎn)單的處理方法爪模，把任務(wù)寫(xiě)入mysql，然后啟動(dòng)一個(gè)獨(dú)立的進(jìn)程來(lái)一個(gè)任務(wù)一個(gè)任務(wù)的串行處理荚藻。異步的話(huà)屋灌，客戶(hù)端如何知道服務(wù)器已經(jīng)處理了呢？最簡(jiǎn)單就是采用輪詢(xún)的方法了应狱，客戶(hù)端每隔幾秒就請(qǐng)求服務(wù)器一次共郭。

異步處理抽獎(jiǎng)操作

性能問(wèn)題

由于抽獎(jiǎng)是短時(shí)間大量用戶(hù)請(qǐng)求的，如果直接讓請(qǐng)求落到mysql疾呻，類(lèi)似DDOS攻擊,一般的數(shù)據(jù)庫(kù)是扛不住的除嘹。而redis是1種基于內(nèi)存的高并發(fā)NoSQL,在很多公司廣泛使用,由于其性能非常好，并且其豐富的數(shù)據(jù)接口完全可以勝任抽獎(jiǎng)任務(wù)需求岸蜗。
這個(gè)時(shí)候尉咕，你可能有這樣的疑問(wèn),我們的系統(tǒng)設(shè)計(jì)是怎么樣的呢？

• 抽獎(jiǎng)系統(tǒng)相關(guān)配置存儲(chǔ)在redis的一個(gè)key值璃岳，直接使用json格式
• 客戶(hù)端請(qǐng)求的時(shí)候判斷年缎，時(shí)間是否在活動(dòng)時(shí)間范圍內(nèi)
• 客戶(hù)端請(qǐng)求如果時(shí)間在活動(dòng)范圍內(nèi)，則把用戶(hù)添加到一個(gè)redis集合铃慷，用于防止用戶(hù)重復(fù)請(qǐng)求单芜，只有第一次請(qǐng)求才會(huì)添加到集合后，再添加到一個(gè)redis列表犁柜。
• 后臺(tái)一個(gè)獨(dú)立的進(jìn)程洲鸠，從redis列表pop第一位用戶(hù)，然后分配一個(gè)金額馋缅，然后把金額和用戶(hù)信息壓入另一個(gè)redis列表B坛怪，同時(shí)寫(xiě)入redis的hash結(jié)構(gòu)，標(biāo)示用戶(hù)獲得多少現(xiàn)金股囊。一直循環(huán)該過(guò)程。
• 后臺(tái)另一個(gè)獨(dú)立的進(jìn)程更啄，從redis列表B pop第一位用戶(hù)稚疹，然后調(diào)用發(fā)送現(xiàn)金接口，一直循環(huán)該過(guò)程。
• 客戶(hù)端不停輪詢(xún)獲取用戶(hù)金額的接口内狗，該接口從哪個(gè)hash結(jié)構(gòu)獲取用戶(hù)金額怪嫌，然后沒(méi)有數(shù)據(jù)，則告訴客戶(hù)端若干秒后再次請(qǐng)求柳沙。

最終架構(gòu)圖

前端優(yōu)化

由于參與活動(dòng)的人數(shù)較多岩灭，而且服務(wù)器是放在外網(wǎng)的，所以需要考慮帶寬的問(wèn)題赂鲤。

1. 第一步噪径，把靜態(tài)資源放到cdn。
2. 第二步数初，抽獎(jiǎng)頁(yè)面靜態(tài)化找爱，同時(shí)也放到cdn，這樣子服務(wù)器只需要承受用戶(hù)請(qǐng)求和登錄即可泡孩。
3. 第三步车摄，由于采用了微信登錄，所以登錄系統(tǒng)采用一個(gè)獨(dú)立的進(jìn)程仑鸥，并且使用異步框架來(lái)處理高并發(fā)吮播。
4. 第四步，前端發(fā)送請(qǐng)求隊(duì)列化處理眼俊，避免用戶(hù)不停點(diǎn)擊意狠，造成大量請(qǐng)求。

靜態(tài)資源cdn化

總結(jié)

• 整套系統(tǒng)開(kāi)發(fā)沒(méi)有任何難度泵琳，唯一需要注意高并發(fā)下性能和數(shù)據(jù)問(wèn)題摄职。
• 靜態(tài)資源放到cdn，避免帶寬成為瓶頸获列。
• 把mysql操作變成redis操作谷市，解決io問(wèn)題