限流機制主要用於對流入系統的請求流量進行限制，保證在任何時候進入系統的請求流 量都是可控的。即不能超過系統預設的最大流量值，超過則需要排隊等待或者直接拒絕，從 而避免高併發流量全部湧入系統，導致超出了系統的處理能力而出現系統機器宕機和服務不 可用問題。
限流機制在實現層面，一般是基於漏桶演算法或令牌桶演算法來實現的，如下對這兩種演算法進行具體分析。
對於漏桶演算法，首先可以抽象為在業務服務前面，放置了乙個漏桶來接收請求流量，然 後在漏桶中開乙個指定大小的口來將這些請求流量流出給業務服務處理。由於漏桶的口是固 定的，故交給業務服務處理的請求流量也是固定的，而不會受到流入漏桶的請求流量的大小 的影響。如圖所示：
即如果請求流量較小，則可以直接通過該漏桶的口流出給業務服務處理；如果請求 流量過大，該口無法及時流出個業務服務處理，則首先會在漏桶中累計。在實際實現當中可 以使用有界佇列來實現請求的累計，如果請求流量佔滿了漏桶空間，則後續請求會溢位，即 請求被直接拒絕。
所以通過漏桶交給業務服務處理的請求流量是可控的，以及根據漏桶口的大小以恆定速 率流出請求流程給業務服務處理，不會受到突發流量的影響，從而避免了突發的、超過服務 處理能力的高併發請求流量壓垮業務服務。
與漏桶演算法將請求流入到漏桶，然後由漏桶流出給業務服務處理不同，在令牌桶演算法中， 每個請求在交給業務服務處理之前，都需要首先從令牌桶獲取乙個令牌，如果獲取成功則可 以交給對應的業務服務處理，如果獲取失敗則需要等待或者直接拒絕。如圖所示：
令牌桶中的令牌是業務服務根據自身處理能力來以恆定的速率新增到令牌桶的，如 200r/s，每秒 200 個，則業務服務每秒最多可以處理 200 個請求，超過的請求則需要阻塞等 待或者被拒絕。而每秒新增令牌可以一次性新增，也可以分多次新增，不過一般是分多次添 加，如 200r/s 可以是是每 500 毫秒新增 100 個。
除此之外，如果每秒的請求個數達不到每秒投放到令牌桶的令牌的個數，如實際請求為 每秒 100 個，而業務服務投放令牌到令牌桶為每秒 200 個，故此時的請求流量低於業務服務 的指定速率。所以多餘的令牌會在令牌桶累計，直到到達該桶的大小，如令牌桶可以最多存 放 500 個，超過的令牌則直接丟棄。其中令牌桶的大小也是按照業務服務的最大處理能力來 設定的，如業務服務每秒處理 200 個效能是最好的，但是也可以接收 500 個請求的突發流量。
由於業務服務會繼續以指定速率新增令牌，故如果實際的請求達到的速率一直達不到令牌投放的速率，則一段時間後令牌桶會保持有 500 個令牌。如果之後某段時間突然有 500 個請求過來，則這 500 個請求可以交給業務服務處理。
所以與漏桶演算法相比，令牌桶演算法除了支援對請求流量進行控制，使得請求流量以指定 速率交給業務服務處理之外，還支援處理異常突發流量，從而實現對業務服務最大處理能力 的利用。
分布式限流演算法
一 限流的作用 有高併發的系統中，由於api介面無法控制呼叫發的行為，因此如果遇到瞬時請求數量遞增，就會導致介面占用過多的伺服器子u，導致響應速度降低或者超時，甚至可能英雌導致伺服器宕機，尤其是資料庫伺服器。所以就有限流的思想，限制客戶端對伺服器端端的請求限制，如果在單位時間內超過該請求限制，就會執...
分布式 介面限流 漏桶 令牌桶演算法
簡介 每乙個對外提供的api介面都是需要做流量控制的，不然會導致系統直接崩潰，如果api上的流量請求超過核定的數值，我們就得對請求進行分流或者直接拒絕等操作。一 限流 1.作用 由於業務應用系統的負載能力有限，為了防止非預期的請求對系統壓力過大而拖垮業務應用系統 2.大流量控制策略 分流 降級 限流...
分布式技術之限流
ip限流 參看大神部落格 limit req zone 用來限制單位時間內的請求數，即速率限制,採用的漏桶演算法 leaky bucket limit req 配合 limit req zone 使用示例 limit req zone binary remote addr zone mylimit ...