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

成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),鎮(zhèn)海企業(yè)網(wǎng)站建設(shè),鎮(zhèn)海品牌網(wǎng)站建設(shè),網(wǎng)站定制,鎮(zhèn)海網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,鎮(zhèn)海網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

一、業(yè)務(wù)要求及痛點(diǎn)分析

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

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

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

二、庫存控制及核心流程

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

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

三、發(fā)散思維

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

看完上述內(nèi)容，你們掌握高并發(fā)下的架構(gòu)有哪些解決方案的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！