作者：Zhisheng Tian
前提業(yè)務(wù)背景
就拿前些天的雙十一的 “搶券活動” 來說，一般是設(shè)置整點開始搶的，你想想，淘寶的用戶群體非常大，可以達到億級別，而服務(wù)接口每秒能處理的量是有限的，那么這個時候問題就會出現(xiàn)，我們?nèi)绾瓮ㄟ^程序來控制用戶搶券呢，于是就必須加上這個限流功能了。
生產(chǎn)環(huán)境
服務(wù)接口所能提供的服務(wù)上限（limit）假如是 500次/s用戶請求接口的次數(shù)未知，QPS可能達到 800次/s，1000次/s，或者更高當服務(wù)接口的訪問頻率超過 500次/s，超過的量將拒絕服務(wù)，多出的信息將會丟失線上環(huán)境是多節(jié)點部署的，但是調(diào)用的是同一個服務(wù)接口于是，為了保證服務(wù)的可用性，就要對服務(wù)接口調(diào)用的速率進行限制（接口限流）。
什么是限流？
限流是對系統(tǒng)的出入流量進行控制，防止大流量出入，導致資源不足，系統(tǒng)不穩(wěn)定。
限流系統(tǒng)是對資源訪問的控制組件，控制主要的兩個功能：限流策略和熔斷策略，對于熔斷策略，不同的系統(tǒng)有不同的熔斷策略訴求，有的系統(tǒng)希望直接拒絕、有的系統(tǒng)希望排隊等待、有的系統(tǒng)希望服務(wù)降級、有的系統(tǒng)會定制自己的熔斷策略，這里只針對限流策略這個功能做詳細的設(shè)計。
限流算法1、限制瞬時并發(fā)數(shù)
Guava RateLimiter 提供了令牌桶算法實現(xiàn)：平滑突發(fā)限流(SmoothBursty)和平滑預熱限流(SmoothWarmingUp)實現(xiàn)。
2、限制某個接口的時間窗最大請求數(shù)
即一個時間窗口內(nèi)的請求數(shù)，如想限制某個接口/服務(wù)每秒/每分鐘/每天的請求數(shù)/調(diào)用量。如一些基礎(chǔ)服務(wù)會被很多其他系統(tǒng)調(diào)用，比如商品詳情頁服務(wù)會調(diào)用基礎(chǔ)商品服務(wù)調(diào)用，但是怕因為更新量比較大將基礎(chǔ)服務(wù)打掛，這時我們要對每秒/每分鐘的調(diào)用量進行限速；一種實現(xiàn)方式如下所示：
使用Guava的Cache來存儲計數(shù)器，過期時間設(shè)置為2秒（保證1秒內(nèi)的計數(shù)器是有的），然后我們獲取當前時間戳然后取秒數(shù)來作為KEY進行計數(shù)統(tǒng)計和限流，這種方式也是簡單粗暴，剛才說的場景夠用了。
3、令牌桶
算法描述：
假如用戶配置的平均發(fā)送速率為r，則每隔1/r秒一個令牌被加入到桶中假設(shè)桶中最多可以存放b個令牌。如果令牌到達時令牌桶已經(jīng)滿了，那么這個令牌會被丟棄當流量以速率v進入，從桶中以速率v取令牌，拿到令牌的流量通過，拿不到令牌流量不通過，執(zhí)行熔斷邏輯屬性
長期來看，符合流量的速率是受到令牌添加速率的影響，被穩(wěn)定為：r因為令牌桶有一定的存儲量，可以抵擋一定的流量突發(fā)情況M是以字節(jié)/秒為單位的最大可能傳輸速率。 M>rT max = b/(M-r) 承受最大傳輸速率的時間B max = T max * M 承受最大傳輸速率的時間內(nèi)傳輸?shù)牧髁?p>優(yōu)點：流量比較平滑，并且可以抵擋一定的流量突發(fā)情況4、GOOGLE GUAVA 提供的工具庫中 RATELIMITER 類（內(nèi)部也是采用令牌桶算法實現(xiàn)）
最快的方式是使用 RateLimit 類，但是這僅限制在單節(jié)點，如果是分布式系統(tǒng)，每個節(jié)點的 QPS 是一樣的，請求量到服務(wù)接口那的話就是 QPS * 節(jié)點數(shù) 了。所以這種方案在分布式的情況下不適用！
5、基于 REDIS 實現(xiàn)，存儲兩個 KEY，一個用于計時，一個用于計數(shù)。請求每調(diào)用一次，計數(shù)器增加 1，若在計時器時間內(nèi)計數(shù)器未超過閾值，則可以處理任務(wù)。
這種能夠很好地解決了分布式環(huán)境下多實例所導致的并發(fā)問題。因為使用redis設(shè)置的計時器和計數(shù)器均是全局唯一的，不管多少個節(jié)點，它們使用的都是同樣的計時器和計數(shù)器，因此可以做到非常精準的流控。
代碼就不公布了，畢竟涉及公司隱私了。
最后
參考文章：
基于Redis的限流系統(tǒng)的設(shè)計
感興趣的可以看看別人的代碼是怎么寫的：https://github.com/wukq/rate-limiter
- 蜜度索驥：以跨模態(tài)檢索技術(shù)助力“企宣”向上生長
- 密態(tài)計算技術(shù)助力農(nóng)村普惠金融 螞蟻密算、網(wǎng)商銀行項目入選大數(shù)據(jù)“星河”案例
- 專利糾紛升級！Netflix就虛擬機專利侵權(quán)起訴博通及VMware
- 兩大難題發(fā)布！華為啟動2024奧林帕斯獎全球征集
- 2025年工業(yè)軟件市場格局：7個關(guān)鍵統(tǒng)計數(shù)據(jù)與分析
- Commvault持續(xù)業(yè)務(wù)策略：應(yīng)對現(xiàn)代數(shù)據(jù)保護挑戰(zhàn)的新范式
- 2025年網(wǎng)絡(luò)安全主要趨勢
- 2025年值得關(guān)注的數(shù)據(jù)中心可持續(xù)發(fā)展趨勢
- 量子計算火熱，投資者又在大舉尋找“量子概念股”
- 從量子威脅到人工智能防御：2025年網(wǎng)絡(luò)安全將如何發(fā)展
- 后人工智能時代：2025年，在紛擾中重塑數(shù)據(jù)、洞察和行動
免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。
