限流是常見的應用保護方案
常見限流方案
- 基於IP地址和基於服務器的訪問請求限流。抵擋部分易識別的DDOS攻擊，主要對request 請求頭做解析判斷
- QPS、併發量(連接數)限流，如Tomcat，就有最大連接數、最大請求數的設置。
- 下行帶寬速率限制
限流算法
1. 令牌桶算法
單位時間內往一定容量的桶裏存入令牌，令牌消耗完則時間內的請求被拒絕。 放入令牌的速度是恆定的，但是消費令牌的速度是不定的。也就是可能在流量激增的時候把令牌都消費完了導致無法訪問。 
基於隊列實現，用隊列存儲令牌，每來一個請求就從隊列取出一個令牌，令牌爲空則拒絕請求。另一個線程穩定向隊列裏放入令牌，直到隊列滿。
2. 漏桶算法
限流更加平滑，流速是穩定的，超過流速則拒絕。消費穩定，放入流量不定。導致瞬間的流量並不會全部都消費，而是擋出去了一部分，後續新流量還是能恆定進入。 
可以用FIFO隊列模擬手痛，隊列的容量就是水桶的最大大小，超過隊列容量就拒絕，
3. 計數器算法
計數器算法是在一定時間內記錄訪問的次數，過了間隔就清零。比如一分鐘限定能有10個訪問，超過十個，拒絕訪問，到了下一分鐘又有10個可以訪問。
單機限流可以使用內存，但是分佈式集羣的情況就需要引入redis。但是不能細粒度控制流量在定時區間內的平滑性，依然會有毛刺。如臨界點就把兩個相連區間的限定給用完了。
4. 滑動窗口算法
TCP著名的滑動窗口，滑動窗口彌補了計數器算法的不足，將大區間分成獨立的小區間，只統計獨立區間(黑框)的請求數量，超出獨立格子的數量就會被丟棄。 
我們在每一秒內有5個用戶訪問，第5秒內有10個用戶訪問，那麼在0到5秒這個時間窗口內訪問量就是15。如果我們的接口設置了時間窗口內訪問上限是20，那麼當時間到第六秒的時候，這個時間窗口內的計數總和就變成了10，因爲1秒的格子已經退出了時間窗口，因此在第六秒內可以接收的訪問量就是20-10=10個。
總結
|算法|優點|缺點| |令牌桶|預存一定量令牌，允許突發流量|後臺系統壓力大| |漏桶|對於後臺系統不會有突發流量|喪失對於突發流量的處理能力| |計數器算法|簡單|有臨界問題，不平滑| |滑動窗口算法|優化計數器算法平滑問題|更大的內存開銷|
限流層
從接入層到應用層，對應不同的部件使用不同的方式進行限流，限流的要求也不同。
- 接入層： Nginx、Openresty
- 應用網關層：SpringGateway、zuul
- 應用層：根據業務情況，由應用層自行編寫限流。經典就是遊戲排隊，需要xxx分鐘進入服務器。
限流實戰
Guava Ratelimiter
流量預熱，在大促或者大流量場景預測下，將令牌桶的桶容量增大以增強突發流量應對能力。 主要獵是SmoothWarmingUp，他是SmoothRateLimiter的內部類。重點是doSetRate方法。
Redis+lua
Spring Gateway
默認提供了Lua+Redis的限流服務，當Redis服務不可用時，Gateway就直接將所有請求做放行處理。
上WAF高防
Sentinel
流行的第三方限流組件，獨立部署。應用引入依賴包，配置Sentinel的連接。實現Sentinel控制應用服務接口級別的限流。