高并發(fā)下的架構有哪些解決方案

高并發(fā)下的架構有哪些解決方案？相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

一、業(yè)務要求及痛點分析

紅包雨項目屬于抽獎類系統(tǒng)的一種，它要求在某段時間內(nèi)隨機派發(fā)獎品，用戶搶紅包參與活動。這個業(yè)務由管理后臺、用戶前臺和開發(fā)平臺構成。其中管理后臺需要實現(xiàn)用戶管理、獎品管理、活動管理、中獎統(tǒng)計等功能;用戶前臺用于注冊登錄、參與抽獎、個人中心查看中獎信息等。開發(fā)平臺包含微服務架構體系、注冊與服務發(fā)現(xiàn)Nacos、部署平臺、接口管理Swagger等。

由于抽獎系統(tǒng)常常涉及到大批用戶的點擊涌入，怎樣設計系統(tǒng)以達到高并發(fā)情況下的及時響應是本項目的重中之重。同時抽獎的獎品數(shù)量需要精確控制，不允許出現(xiàn)設置了5個獎品，最終6人中獎這種類似的問題。同時，在活動時間段內(nèi)，管理員設置好的獎品如何投放？

紅包何時出現(xiàn)？獎品什么時候可以被抽中？這些都涉及到投放策略的優(yōu)化。

二、庫存控制及核心流程

令牌桶算法可以把請求平均分散在時間段內(nèi)，是使用較為廣泛的限流算法。我們可以把令牌桶算法應用到紅包雨業(yè)務案例中。這時候，令牌相當于獎品票據(jù);令牌桶相當于獎品庫存;正常業(yè)務相當于中獎;限流相當于未中獎。同時要注意，有多少個獎品，就生成多少個令牌(時間戳)，未中獎返還令牌。假設活動時間間隔太短，獎品太多，極有可能產(chǎn)生的時間戳發(fā)生重復。為了解決這個問題，我們需要額外附加一個隨機因子，將( 時間戳*1000+3位隨機數(shù))作為令牌，抽獎時將抽中的令牌除以1000來還原真實的時間戳。

最后，將拿出令牌、判斷時間、放回令牌的操作下沉到Redis服務器端，利用Lua腳本避免出現(xiàn)插隊導致的令牌順序被打亂。通過這些操作和解決方案，相信可以避免打亂獎品令牌造成扎堆出現(xiàn)的問題。

三、發(fā)散思維

使用Lua腳本，將抽獎的邏輯從Java端移入Redis服務器端，作為一個整體函數(shù)暴露給Java調用，一方面實現(xiàn)中獎邏輯的原子性，另一方面減少了Java服務器與Redis服務器之間的通信次數(shù)，性能會得到提升。要實現(xiàn)活動隨時暫停，可以新增一個接口，該接口修改Redis緩存中的活動狀態(tài)。抽獎接口邏輯中增加暫停狀態(tài)判斷。如果是暫停，返回給前臺以提示。要實現(xiàn)多種投放策路，可以修改令牌生成部分代碼。按遞增、遞減、正態(tài)分布等多種函數(shù)生成時間戳。

看完上述內(nèi)容，你們掌握高并發(fā)下的架構有哪些解決方案的方法了嗎？如果還想學到更多技能或想了解更多相關內(nèi)容，歡迎關注億速云行業(yè)資訊頻道，感謝各位的閱讀！