在開發介面伺服器的過程中，為了防止客戶端對於介面的濫用，保護伺服器的資源， 通常來說我們會對於伺服器上的各種介面進行呼叫次數的限制。比如對於某個 使用者，他在乙個時間段（interval）內，比如 1 分鐘，呼叫伺服器介面的次數不能夠 大於乙個上限（limit），比如說 100 次。如果使用者呼叫介面的次數超過上限的話，就直接拒絕使用者的請求，返回錯誤資訊。
服務介面的流量控制策略：分流、降級、限流等。本文討論下限流策略，雖然降低了服務介面的訪問頻率和併發量，卻換取服務介面和業務應用系統的高可用。
1、漏桶演算法
漏桶(leaky bucket)演算法思路很簡單,水(請求)先進入到漏桶裡,漏桶以一定的速度出水(介面有響應速率),當水流入速度過大會直接溢位(訪問頻率超過介面響應速率),然後就拒絕請求,可以看出漏桶演算法能強行限制資料的傳輸速率.示意圖如下:
可見這裡有兩個變數,乙個是桶的大小,支援流量突發增多時可以存多少的水(burst),另乙個是水桶漏洞的大小(rate)。
因為漏桶的漏出速率是固定的引數,所以,即使網路中不存在資源衝突(沒有發生擁塞),漏桶演算法也不能使流突發(burst)到埠速率.因此,漏桶演算法對於存在突發特性的流量來說缺乏效率.
2、令牌桶演算法
令牌桶演算法(token bucket)和 leaky bucket 效果一樣但方向相反的演算法,更加容易理解.隨著時間流逝,系統會按恆定1/qps時間間隔(如果qps=100,則間隔是10ms)往桶裡加入token(想象和漏洞漏水相反,有個水龍頭在不斷的加水),如果桶已經滿了就不再加了.新請求來臨時,會各自拿走乙個token,如果沒有token可拿了就阻塞或者拒絕服務.
令牌桶的另外乙個好處是可以方便的改變速度. 一旦需要提高速率,則按需提高放入桶中的令牌的速率. 一般會定時(比如100毫秒)往桶中增加一定數量的令牌, 有些變種演算法則實時的計算應該增加的令牌的數量.
<?php
namespace api\lib;
/** * 限流控制
*/class ratelimit
}public function getredis($key, $initnum, $expire)
redis令牌桶限流
每個ip 1秒內只能傳送一次請求 pom檔案 org.springframework.bootgroupid spring boot starter data redis reactiveartifactid 2.1.3.releaseversion dependency 啟動引導類定義 keyre...
php令牌桶限流
前端每次請求從令牌桶取走令牌，後端勻速向桶內投遞令牌，如果前端取到令牌，則說明這次請求有效，否則讓前端再次請求或者等待。避免了大量請求下伺服器壓力過大導致的崩潰問題。令牌桶演算法 class token catch redi ception exception 令牌初始化 public functi...
Redis令牌桶限流
在開發介面伺服器的過程中，為了防止客戶端對於介面的濫用，保護伺服器的資源，通常來說我們會對於伺服器上的各種介面進行呼叫次數的限制。比如對於某個 使用者，他在乙個時間段 interval 內，比如 1 分鐘，呼叫伺服器介面的次數不能夠 大於乙個上限 limit 比如說 100 次。如果使用者呼叫介面的...