需求出現

年會將近，而年會抽獎環節必不可少，但是抽獎系統卻還沒有。所以某一天，PM走過來說：小伙，手頭的需求修完成了吧！在年會開始之前必須做出一個抽獎系統。這個系統很簡單，后臺可以設置總金額，然后每個用戶可以獲得的金額范圍，金額派完則顯示很遺憾沒有中獎，還要設置抽獎活動時間。

需求分析

一看這東西，就覺得非常簡單。最簡單的一個方案，活動時間放在一個數據表，總金額和已經使用金額存放在一個表，已經派送的日志一個表。后臺提供一個接口，客戶端手動點擊按鈕，則發送一個請求。賬號體系直接使用微信的oauth，接口首先判斷活動有沒有開始，如果開始則隨機一個金額，然后判斷如果派送該金額會不會超預算，如果不超預算，則調用微信的現金接口發放零錢。

并發問題

這個簡單方案存在一個致命的問題，就是并發下，可能導致超預算的問題。如果采用加鎖的方式，面對1000多員工同時請求，系統100%癱瘓。（因為抽獎系統的服務器是最普通的1核1G 1M帶寬的服務器）

那么不加鎖的情況，又能如何避免并發造成的派送超過預算的問題呢？ 一個簡單的辦法，把分配派送金額的操作從并行變成串行。那么就需要異步的編程方法。最簡單的處理方法，把任務寫入mysql，然后啟動一個獨立的進程來一個任務一個任務的串行處理。異步的話，客戶端如何知道服務器已經處理了呢？最簡單就是采用輪詢的方法了，客戶端每隔幾秒就請求服務器一次。

性能問題

由于抽獎是短時間大量用戶請求的，如果直接讓請求落到mysql，類似DDOS攻擊,一般的數據庫是扛不住的。而redis是1種基于內存的高并發NoSQL,在很多公司廣泛使用,由于其性能非常好，并且其豐富的數據接口完全可以勝任抽獎任務需求。 這個時候，你可能有這樣的疑問,我們的系統設計是怎么樣的呢？

• 抽獎系統相關配置存儲在redis的一個key值，直接使用json格式
• 客戶端請求的時候判斷，時間是否在活動時間范圍內
• 客戶端請求如果時間在活動范圍內，則把用戶添加到一個redis集合，用于防止用戶重復請求，只有第一次請求才會添加到集合后，再添加到一個redis列表。
• 后臺一個獨立的進程，從redis列表pop第一位用戶，然后分配一個金額，然后把金額和用戶信息壓入另一個redis列表B，同時寫入redis的hash結構，標示用戶獲得多少現金。一直循環該過程。
• 后臺另一個獨立的進程，從redis列表B pop第一位用戶，然后調用發送現金接口，一直循環該過程。
• 客戶端不停輪詢獲取用戶金額的接口，該接口從哪個hash結構獲取用戶金額，然后沒有數據，則告訴客戶端若干秒后再次請求。

前端優化

由于參與活動的人數較多，而且服務器是放在外網的，所以需要考慮帶寬的問題。

1. 第一步，把靜態資源放到cdn。
2. 第二步，抽獎頁面靜態化，同時也放到cdn，這樣子服務器只需要承受用戶請求和登錄即可。
3. 第三步，由于采用了微信登錄，所以登錄系統采用一個獨立的進程，并且使用異步框架來處理高并發。
4. 第四步，前端發送請求隊列化處理，避免用戶不停點擊，造成大量請求。

總結

• 整套系統開發沒有任何難度，唯一需要注意高并發下性能和數據問題。
• 靜態資源放到cdn，避免帶寬成為瓶頸。
• 把mysql操作變成redis操作，解決io問題