做了一個直播互動的功能：搶紅包
功能邏輯如下：
到一個時間點時，螢屏會出現紅包雨的效果，參與直播的用戶進行點擊拆紅包，累計紅包數量可兌換成現金，直接轉入自己的微信賬戶中。
碰到的瓶頸問題：
大量用戶同時在搶紅包時，服務器CPU會急劇飆高，導致整個頁面都卡死，甚至服務器宕機
服務器配置：
網站服務器：WinSvr 2008R2 , 30M帶寬，16核CPU，記憶體32G
資料庫服務器：WinSvr 2008R2 , 1M帶寬（內網連接），16核CPU，記憶體32G
程式實作邏輯
通過客戶端腳本記錄用戶搶到的紅包數量存盤到本地快取中，搶完后再呼叫服務端介面來計算紅包數量應得的紅包金額，最后發紅包。
以上，求各路大神給出比較好的優化方案
uj5u.com熱心網友回復：
用戶量在1500~3000個左右uj5u.com熱心網友回復：
我們不管你用戶量有多大既然是搶，拼的是“運氣”，所以能不進入服務器正式操作也是運氣
so，做個“令牌桶限流"就好，搶到令牌的進，沒搶到令牌的，直接扔掉不處理
uj5u.com熱心網友回復：
回答這類問題，我們這種實際一線處理問題的人，跟博客園那些高大上的內卷式技術大神不一樣他們告訴你是怎么內卷，怎么堵門。
我們告訴你的是，怎么向外看，怎么跟其他行業的學習。
java，go，甚至都不是這個行業的學習
比如：水利專家怎么看。
你這問題和水利專家的情況一樣，如果發洪水了，怎么保護下游
那么
1.加固下游堤壩
2.修建防洪壩
3.修建分洪壩，溢流壩。
4.建立泄洪區
5.利用上面所有設施進行，庫容調節，進行分流，消峰，錯峰，棄水等調度手段
所以借用人家玩了幾千的經驗
1.加固下游堤壩------------改善你現有的處理邏輯，盡量降低cpu
2.修建防洪壩-------------------利用mq，kafaka,redis，先將資料入水庫，然后在過壩調度
3.修建分洪壩，溢流壩-----------利用api網關，進行分流，熔斷
4.建立泄洪區----------------利用令牌桶，漏桶進行限流棄水
5.利用上面所有設施進行--------------利用上面所有的收到，進行流量調度
uj5u.com熱心網友回復：
內卷式大神主要就在加固下游堤壩------------改善你現有的處理邏輯，盡量降低cpu
這里玩
但是幾千年的洪水經驗告訴我們，這種其實作用有限。
中國歷史所有朝代都在不停加固堤防，但是洪災也沒小過。（俺們電視劇，總在修河堤，修河堤。發大水，發大水）
但是近代綜合性水利工程以后，這種情況才好很多。所以我們的建議是，進行綜合性治理和調度，而不是僅僅就討論加固堤壩
uj5u.com熱心網友回復：
2000個人請求一個介面 問題不大吧....我覺得是"搶紅包"代碼的問題...
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/268042.html
標籤：ASP.NET