分布式限流算法的選擇需根據業務需求和系統特性進行權衡。1. 令牌桶允許突發流量，適合短暫高并發場景，通過redis+lua實現令牌生成與消耗的原子操作；2. 漏桶以恒定速率處理請求，輸出平滑但不適用于突發流量，可通過redis隊列模擬實現；3. 計數器分為固定窗口和滑動窗口，后者更精確但實現復雜，適合對限流精度要求高的場景；選擇時需考慮一致性、性能開銷、容錯性、突發流量容忍度及實現復雜度；使用redis時需防范單點故障、網絡延遲、lua腳本復雜度過高等問題，并通過壓測評估吞吐量、延遲和資源消耗，結合監控確保限流策略有效運行。
在構建高并發系統時，分布式限流是不可或缺的一環。簡單來說，它就是為了保護你的系統不被突發流量沖垮，或者防止惡意請求耗盡資源。常見的實現算法無外乎令牌桶（Token Bucket）、漏桶（Leaky Bucket）和計數器（Counter，包括固定窗口和滑動窗口），每種都有其獨特的脾氣和適用場景。我個人覺得，沒有哪個算法是萬能的，關鍵在于你對業務流量特性的理解和取舍。
解決方案
要實現Java的分布式限流，核心在于將限流狀態同步到所有服務實例都能訪問到的地方，比如redis、zookeeper或者數據庫。
令牌桶算法（Token Bucket）
立即學習“Java免費學習筆記（深入）”；
令牌桶就像一個固定容量的桶，系統會以恒定速率往里面投放令牌。每次請求過來，都需要從桶里取走一個令牌才能通過。如果桶里沒有令牌了，請求就得等待或者被拒絕。這個算法的優點是允許一定程度的突發流量，只要桶里有足夠的令牌，請求就能快速通過。這在我看來，對于那些允許短暫爆發性訪問的API非常友好。
- 實現思路： 可以用Redis的INCR和EXPIRE命令來模擬令牌的生成和消耗。一個Key存儲當前令牌數，另一個Key存儲上一次刷新令牌的時間戳。每次請求到來，先計算應該增加了多少令牌，更新令牌數，然后嘗試獲取令牌。Lua腳本在這里是利器，可以保證操作的原子性。
漏桶算法（Leaky Bucket）
漏桶算法則像是有一個固定流速的桶，無論請求量多大，它都以一個恒定的速率“漏”出去處理。如果請求進來時桶已經滿了，那么新來的請求就會被丟棄。這個算法的特點是輸出流量平滑，能有效保護后端系統，避免其處理能力被瞬間壓垮。但我有時候覺得它有點“死板”，不怎么擅長處理突發流量。
- 實現思路： 同樣可以基于Redis。用一個列表（List）或者有序集合（ZSet）來模擬桶。每次請求到來就嘗試入隊，如果隊列滿了就拒絕。消費者則以固定速率從隊列頭部取出請求進行處理。
計數器算法（Counting Window）
這是最直觀的限流方式。它又分為固定窗口和滑動窗口。
-
固定窗口計數器： 在一個固定的時間窗口內（比如1秒），統計請求數量，超過閾值就拒絕。它的問題在于，如果請求在窗口邊緣扎堆，可能會導致實際的瞬時流量遠超預期，這在實際應用中確實是個讓人頭疼的問題。比如，1秒的窗口，限流100次，如果99次請求都在第0.9秒發生，那第1秒開始的瞬間，系統可能瞬間涌入大量請求。
-
滑動窗口計數器： 相比固定窗口，滑動窗口更平滑、更準確。它將時間窗口分成更小的格子，每個格子有自己的計數。當時間向前滑動時，會移除舊的格子計數，并增加新的格子計數。這有效避免了固定窗口的邊緣效應。在我看來，滑動窗口雖然實現復雜一些，但效果通常是最好的。
-
實現思路： 基于Redis的ZSet，每個請求到來時，將當前時間戳作為score，請求ID作為member存入。每次檢查時，移除過期時間戳的member，然后統計當前ZSet中的member數量。
在分布式環境中，選擇限流算法時需要考慮哪些關鍵因素？
選擇分布式限流算法，可不是拍腦袋就能決定的事，這里面坑不少。在我看來，最核心的考量點有幾個：首先是一致性，你的限流規則在所有服務實例之間必須是同步且一致的，不能說這個節點放行了，那個節點卻拒絕了。這通常意味著需要一個中心化的存儲來維護狀態，比如Redis。其次是性能開銷，限流本身不能成為系統的瓶頸，每次請求都去遠程調用一次Redis或者ZooKeeper，這個延遲和網絡IO是實實在在的，你得評估它是否在可接受范圍內。
再者，容錯性也不容忽視，如果你的Redis集群掛了，限流服務是直接失效然后系統被沖垮，還是能有降級策略？這是個大問題。業務對突發流量的容忍度也至關重要，有些業務允許短時間內的爆發性流量（比如秒殺活動），這時候令牌桶就顯得很靈活；有些則需要嚴格的平滑流量輸出（比如后端處理能力有限的批處理服務），漏桶就更合適。最后，實現復雜度也是個現實因素，畢竟資源有限，滑動窗口雖然好，但實現和維護成本擺在那里。
基于Redis的分布式限流方案有哪些常見陷阱和優化建議？
Redis在分布式限流里確實是“主力軍”，但用不好也容易掉坑。一個常見的陷阱是單點故障，如果你的Redis是單實例，那它掛了，整個限流服務就癱瘓了。解決方案當然是上Redis sentinel或者Redis Cluster，保證高可用。
另一個問題是網絡延遲，每次請求都去Redis拿數據，這個網絡往返時間會累加到你的請求響應時間里。優化上，可以考慮連接池，減少連接建立的開銷。更進一步，對于一些非核心、流量巨大的接口，可以考慮在應用層做二級限流，先在本地內存里粗略地限一下，再往Redis走。
還有，Lua腳本的使用雖然能保證原子性，但如果腳本邏輯過于復雜，或者Redis實例負載過高，也可能導致執行超時。我的經驗是，Lua腳本要盡量精簡，只包含核心邏輯。另外，Key的命名和過期策略也很重要，避免Key沖突，及時清理過期Key，防止內存泄脹。對于超高并發場景，Redis的持久化方式（RDB/AOF）也需要仔細權衡，是追求數據一致性犧牲一點性能，還是追求極致性能犧牲一點點數據安全？這都是取舍。
如何評估不同限流算法在實際業務場景中的性能與開銷？
評估限流算法的性能和開銷，不能只看理論，得結合實際業務場景來。最直接的辦法就是壓測。你需要模擬不同流量模式（平穩、突發、尖峰）去壓測你的限流服務，觀察幾個關鍵指標：
- 吞吐量（Throughput）：在限流生效的情況下，系統每秒能處理多少請求？這是最直觀的指標。
- 延遲（Latency）：限流邏輯本身會引入多少額外的請求延遲？特別是P99、P999延遲，它們能反映出最慢的那批請求的表現。
- 資源消耗：限流服務本身（Redis、應用實例）的CPU、內存、網絡IO消耗如何？這直接關系到部署成本。
我通常會先在開發環境或測試環境搭建一個與生產環境盡可能一致的限流服務，然后用JMeter、Locust或者Gatling這樣的工具進行壓力測試。模擬不同的QPS、并發用戶數，觀察系統行為。比如，令牌桶在突發流量下的表現，漏桶在平穩輸出時的穩定性。
此外，監控也是不可或缺的一環。上線后，通過prometheus、grafana等工具實時監控限流計數、拒絕請求數、Redis連接數和延遲等指標，及時發現問題。有時候，算法的選擇不僅僅是技術考量，更是對業務SLA（服務等級協議）的承諾。如果業務對延遲非常敏感，那即使某個算法在理論上很優秀，但如果引入的額外延遲過高，也可能不適用。最終，選擇哪種算法，往往是性能、復雜度和業務需求之間的一個動態平衡。
