限流是什么
通過某種手段對(duì)某個(gè)時(shí)間段的并發(fā)訪問請(qǐng)求進(jìn)行流量限制，一旦流量達(dá)到限制閾值則可以拒絕服務(wù)，排隊(duì)或等待，目的是防止系統(tǒng)因大流量或突發(fā)流量導(dǎo)致服務(wù)不可用或崩潰扒磁，是一種確保系統(tǒng)高可用的手段袱箱。
限流的簡(jiǎn)單了解
對(duì)外限流：
電商秒殺（因秒殺業(yè)務(wù)特性遏乔，需要限流）：到達(dá)開賣時(shí)間瞬間大流量，此時(shí)下單人數(shù)>商品庫存发笔，服務(wù)器不可能同時(shí)全部消費(fèi)盟萨，需要進(jìn)行限流，賣完了之后就拒絕后續(xù)下單請(qǐng)求了讨。
微博熱搜（因產(chǎn)品特性捻激，需要限流）：突然出現(xiàn)了幾個(gè)大瓜，那微博是不是突然流量激增前计，重災(zāi)區(qū)就是微博熱搜胞谭，此時(shí)所有服務(wù)滿載運(yùn)行，必須有個(gè)限流策略保證服務(wù)的高可用男杈。
防止惡意攻擊（突發(fā)惡意攻擊丈屹，需要限流）：比如某一個(gè) API 被瘋狂請(qǐng)求，或者某一個(gè) IP 瘋狂請(qǐng)求公司的 API伶棒，此時(shí)就需要進(jìn)行限流旺垒，常見措施是先告警，再限流肤无。為了不影響其他服務(wù)的正常使用袖牙，需要設(shè)計(jì)限流方案。
API有償調(diào)用：用戶認(rèn)證+限流策略舅锄，顧名思義沒啥好說的，一般是 SAAS 公司最常見的業(yè)務(wù)司忱，常見于 OPEN-API 相關(guān)的小組負(fù)責(zé)的皇忿。
對(duì)內(nèi)限流：
BUG預(yù)防：核心服務(wù)的高可用是十分重要的，千萬不能掛坦仍。如果內(nèi)部應(yīng)用出現(xiàn) bug鳍烁，一直調(diào)用核心服務(wù)，核心服務(wù)就有被擊垮的風(fēng)險(xiǎn)繁扎，限流也十分重要幔荒。
緩存雪崩：請(qǐng)求直接打到 DB，那就哦豁完蛋了梳玫，所以需要根據(jù)業(yè)務(wù)場(chǎng)景來實(shí)現(xiàn)限流后是排隊(duì)還是丟棄爹梁。
限流解決了什么問題
保證服務(wù)高可用，犧牲一部分的流量提澎，換取服務(wù)的可用性姚垃。對(duì)于被限流器直接作用的應(yīng)用來說，除了保證自身不被流量擊垮盼忌，還保護(hù)了依賴它的下游應(yīng)用积糯。
限流帶來的問題
任何技術(shù)都是雙刃劍掂墓，沒有絕對(duì)的好用，能帶來優(yōu)點(diǎn)必然也會(huì)帶來問題看成。
限流組件保證了高可用君编，犧牲了性能，增加了一層 IO 環(huán)節(jié)的開銷川慌，單機(jī)限流在本地吃嘿，分布式限流還要通過網(wǎng)絡(luò)協(xié)議。
限流組件保證了高可用窘游，犧牲了一致性唠椭，在大流量的情況下，請(qǐng)求的處理會(huì)出現(xiàn)延遲的情況忍饰，這種場(chǎng)景便無法保證強(qiáng)一致性贪嫂。特殊情況下，還無法保證最終一致性艾蓝，部分請(qǐng)求直接被拋棄力崇。
限流組件擁有流控權(quán)，若限流組件掛了赢织，會(huì)引起雪崩效應(yīng)亮靴，導(dǎo)致請(qǐng)求與業(yè)務(wù)的大批量失敗。
引入限流組件于置，增加系統(tǒng)的復(fù)雜程度茧吊，開發(fā)難度增加，限流中間件的設(shè)計(jì)本身就是一個(gè)復(fù)雜的體系八毯，需要綜合業(yè)務(wù)與技術(shù)去思考與權(quán)衡搓侄，同時(shí)還要確保限流組件本身的高可用與性能，極大增加工作量话速，甚至需要一個(gè)團(tuán)隊(duì)去專門開發(fā)讶踪。
設(shè)計(jì)限流組件本身需要考慮的點(diǎn)
如果我來設(shè)計(jì)限流組件，我大致會(huì)確認(rèn)如下幾個(gè)點(diǎn)：
1.明確限流器的目的：
用在哪些模塊泊交？
應(yīng)對(duì)哪些場(chǎng)景下的什么問題?
是單機(jī)限流還是分布式限流?
確定限流模塊的使用層面乳讥？例如：?jiǎn)螒?yīng)用維度、業(yè)務(wù)域維度廓俭、網(wǎng)關(guān)維度
2.明確限流器的維度云石，例如 IP 維度，用戶授權(quán) token 維度白指，API 維度等
3.怎么保證限流組件的高可用留晚？
4.怎么解決使用限流組件后帶來的一致性問題？
5.怎么縮小限流器的粒度，實(shí)現(xiàn)平滑限流错维？
常見的限流實(shí)現(xiàn)
單機(jī)
基于Java 并發(fā)工具
（信號(hào)量 / concurrentHashMap）
基于Google Guava RateLimiter
穩(wěn)定模式(SmoothBursty:令牌生成速度恒定) / 漸進(jìn)模式(SmoothWarmingUp:令牌生成速度緩慢提升直到維持在一個(gè)穩(wěn)定值)
分布式
（Redis + Lua / Nginx + Lua）
常見限流器種類
這四種限流器雖然網(wǎng)上介紹得很多奖地，但是我寫給自己看的 ^_^，自己要每次遇到都能夠脫口而出赋焕，而不是“我經(jīng)巢未酰看到過，但是我記不起來了”或者“我知道是什么意思隆判，但是我就是說不出來犬庇，也說不清楚”。后續(xù), 等API網(wǎng)關(guān)的限流模塊代碼完成后, 對(duì)著代碼和實(shí)踐會(huì)仔細(xì)展開說說 ~
計(jì)數(shù)器（固定窗口限流器）
滑動(dòng)窗口限流器
令牌桶限流器
漏桶限流器
模擬的場(chǎng)景
模擬API 網(wǎng)關(guān)中的一個(gè) API 接口在某個(gè)時(shí)刻突然接收到 100 個(gè)并發(fā)請(qǐng)求侨嘀，但是該 API 配置的令牌桶限流器每1分鐘生成一個(gè)臭挽，每次限流間隔為 1 小時(shí)，限流上限為 60咬腕，則通過代碼模擬出最終效果欢峰，并輸出日志。
實(shí)現(xiàn)的效果
構(gòu)建請(qǐng)求
通過參數(shù)可知涨共，限流器的類別LimiterType選擇的是令牌桶纽帖，限流的時(shí)間單位timeUnit是每小時(shí)，每個(gè)限流時(shí)間內(nèi)的令牌桶內(nèi)令牌的最大數(shù)量value是 60.
