一：限流的作用
有高併發的系統中，由於api介面無法控制呼叫發的行為，因此如果遇到瞬時請求數量遞增，就會導致介面占用過多的伺服器子u，導致響應速度降低或者超時，甚至可能英雌導致伺服器宕機，尤其是資料庫伺服器。
所以就有限流的思想，限制客戶端對伺服器端端的請求限制，如果在單位時間內超過該請求限制，就會執行快速失敗或者服務降級。
所以限流主要應對一下情況：
熱點業務帶來的突發情況
呼叫方bug導致的突發請求
惡意攻擊請求
二：主要的限流演算法
核心思想：限制每秒的事務數
固定視窗計數器
核心思路：
1：將時間化為多個視窗
2：在每個視窗內請求一次計數器加一
3：如果計數器超過限制數量，則本視窗所有請求都丟棄到下乙個時間視窗，計數器重置。
缺陷：如果在在該視窗內前半段時間沒有請求，後半段時間請求飽和，這也會導致請求激增。
滑動視窗計數器
核心思路：
思路大致和固定視窗計數器一致，只不過是在將時間劃為多個區間，每經過乙個區間的時間，則拋棄最老的乙個區間，並納入新的區間。
這就可以避免雙倍請求的出現，不過時間區間的精度越高，所需要的空間容量越大
漏桶演算法
核心思路：
1：將每個請求視為水滴放入漏桶進行儲存
2：漏桶已固定速率向外漏出請求，如果漏桶空了則停止漏水
3：如果漏桶滿了就會直接將水滴丟棄
具體實現就是是使用佇列時間，從佇列中取出請求，如果請求過多則放在佇列外排隊或者拒絕
缺陷：短時間有大量請求，需要等待一段時間才能響應
令牌桶演算法
核心思路：
1：令牌以固定速率生成
2：生成的令牌放入令牌桶，如果桶滿了令牌直接丟棄，請求只有從令牌桶值拿到令牌才可以執行
3：如果令牌桶空了，請求直接被丟棄
這樣請可以將請求平均分布到時間區間內，又可以承受突發激增請求。是一種比較常用的限流演算法
redis lua分布式限流
註解反思 我們專案有好幾個介面，呼叫公司中颱的介面，包括定時器的分片執行還有本人的多執行緒強行壓榨，哈哈。最後加上使用者的瘋狂請求，導致中颱的介面偶爾出現問題，主要是資料庫cpu達到100 昨晚專門做了個限流，那麼技術定型使用什麼呢？ratelimiter?這好像是單機才能玩，sentinel？這個...
分布式限流實戰
由於api介面無法控制呼叫方的行為，因此當遇到瞬時請求量激增時，會導致介面占用過多伺服器資源，使得其他請求響應速度降低或是超時，更有甚者可能導致伺服器宕機。限流 rate limiting 指對應用服務的請求進行限制，例如某一介面的請求限制為100個每秒,對超過限制的請求則進行快速失敗或丟棄。限流可...
分布式技術之限流
ip限流 參看大神部落格 limit req zone 用來限制單位時間內的請求數，即速率限制,採用的漏桶演算法 leaky bucket limit req 配合 limit req zone 使用示例 limit req zone binary remote addr zone mylimit ...