需求出現

年會將近，而年會抽獎環節必不可少，但是抽獎系統卻還沒有。所以某一天，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問題