1. 程式人生 > >分散式常用限流演算法

分散式常用限流演算法

1. 限流場景

在開發高併發系統時,有很多種方法可用來保護系統:快取、降級、限流等。

  • 快取:提升系統訪問速度,增大系統處理能力
  • 降級:服務出現問題或影響核心流程的效能時,需要暫時遮蔽,待高峰過去或問題解決後再開啟
  • 限流:部分場景比如:稀缺資源(秒殺,搶購)、寫服務(評論、下單)、頻繁複雜查詢(評論最後幾頁)等,需要限制這些場景的併發/請求量

限流就是通過對併發訪問/請求進行限速或一個時間視窗內的請求進行限速,從而達到保護系統的目的。一般系統可以通過壓測來預估能處理的峰值,一旦達到設定的峰值閥值,則可以拒絕服務(定向錯誤頁或告知資源沒有了)、排隊或等待(例如:秒殺、評論、下單)、降級(返回預設資料)

限流不能亂用,否則正常流量會出現一些奇怪的問題,從而導致使用者抱怨。

2. 限流演算法

常見限流演算法:技術器、令牌桶和漏桶演算法。

2.1. 計數器

計數器是最簡單粗暴的演算法。例如:一個服務每秒能處理100個請求。設定一個1s的滑動視窗,視窗有10個格子,每個格子100ms,每100ms移動一次,每次移動都記錄當前服務請求的次數。記憶體中儲存最近10次的次數(LinkedList)。格子每次移動的時候判斷一次,最後一個格子和第一個格子的次數是否相差100,如果超過,則進行限流。

當格子劃分的越多,那麼滑動視窗的滾動越平滑,限流的統計就會越精確。

2.2. 令牌桶

令牌桶演算法是一個存放固定容量令牌(token)的桶,按照固定速率往桶裡新增令牌。令牌桶的主要概念如下:

  • 令牌按固定的速率被放入令牌桶中,例如:r tokens/秒
  • 桶中最多存放b個令牌,當桶滿時,新新增的令牌被丟棄或拒絕
  • 當一個n位元組大小的資料包到達,將從桶中刪除n個令牌,接著資料包被髮送到網路上
  • 如果桶中的令牌不足n個,則不會刪除令牌,且資料包將被限流(丟棄或在緩衝區等待)

令牌桶根據放令牌的速率(r tokens/s)去控制輸出的速率(to network)

2.3. 漏桶

漏桶作為計量工具時,可用於流量整形和流量控制,漏桶的主要概念如下:

  • 一個固定容量的漏桶,按照常量固定速率流出水滴(流出請求)
  • 如果桶是空的,則不需流出水滴
  • 可以以任意速率流入水滴到漏桶(流入請求)
  • 如果流入水滴超出了桶的容量,則流入的水滴溢位了(新流入的請求被拒絕),則漏桶容量是不變的

漏桶可以看做固定容量、固定流出速率的佇列,漏桶限制的是請求的流出速率,漏桶中裝的是請求

2.4. 令牌桶和漏桶的比較

令牌桶 漏桶
請求何時拒絕 固定速率往桶中新增令牌,如果桶中令牌不夠,則拒絕新請求 流入請求速率任意,常量固定速率流出請求。當流入請求數積累到漏桶容量時,則拒絕新請求
速率限制 限制平均流入速率,允許一定程度的突發請求(支援一次拿多個令牌) 限制常量流出速率(流出速率是固定值),從而平滑突發流入速率

參考

相關推薦

分散式常用演算法

1. 限流場景 在開發高併發系統時,有很多種方法可用來保護系統:快取、降級、限流等。 快取:提升系統訪問速度,增大系統處理能力降級:服務出現問題或影響核心流程的效能時,需要暫時遮蔽,待高峰過去或問題解決後再開啟限流:部分場景比如:稀缺資源(秒殺,搶購)、寫服務(評論、下

常用演算法與Guava RateLimiter原始碼解析

在分散式系統中,應對高併發訪問時,快取、限流、降級是保護系統正常執行的常用方法。當請求量突發暴漲時,如果不加以限制訪問,則可能導致整個系統崩潰,服務不可用。同時有一些業務場景,比如簡訊驗證碼,或者其它第三方API呼叫,也需要提供必要的訪問限制支援。還有一些資源消耗過大的請求,比如資料匯出等(參考 [記一次線上

分散式系統演算法分析與實現

一、限流的關鍵作用 對於大型網際網路架構中,限流的設計是必不可少的一個環節。在給定的時間內, 客戶端請求次數過多, 伺服器就會攔截掉部分請求,避免請求流量過大造成資料庫負載高的問題。   二、常見限流演算法利弊分析 計數器限流 計數器限流主要有固定視窗計數器和滑動視窗計數器。固定視窗計數器即:在單位

演算法

一、什麼是限流:     限制流量請求的頻率(每秒處理多少個請求)。一般來說,當請求流量超過系統的瓶頸,則丟棄掉多餘的請求流量,保證系統的可用性。 二、解決的問題:     高併發情況下,保證系統的可用性,不會被擊垮。 三、目前主流的兩種限流演算法:

大型網站演算法的實現和改造

最近寫了一個限流的外掛,所以避免不了的接觸到了一些限流演算法。本篇文章就來分析一下這幾種常見的限流演算法 分析之前 依我個人的理解來說限流的話應該靈活到可以針對每一個介面來做。比如說一個類裡面有5個介面,那麼我的限流外掛就應該能針對每一個介面就行不同的限流方案。所

談談服務演算法的幾種實現

保障服務穩定的三大利器:熔斷降級、服務限流和故障模擬。今天和大家談談限流演算法的幾種實現方式,本文所說的限流並非是Nginx層面的限流,而是業務程式碼中的邏輯限流。 為什麼需要限流 按照服務的呼叫方,可以分為以下幾種型別服務 1、與使用者打交道的服務 比如web服

介面演算法:漏桶演算法&令牌桶演算法

工作中對外提供的API 介面設計都要考慮限流,如果不考慮限流,會成系統的連鎖反應,輕者響應緩慢,重者系統宕機,整個業務線崩潰,如何應對這種情況呢,我們可以對請求進行引流或者直接拒絕等操作,保持系統的可用性和穩定性,防止因流量暴增而導致的系統執行緩慢或宕機。 在

Java併發:分散式應用 Redis + Lua 實踐

任何限流都不是漫無目的的,也不是一個開關就可以解決的問題,常用的限流演算法有:令牌桶,漏桶。在之前的文章中,也講到過,但是那是基於單機場景來寫。 然而再牛逼的機器,再優化的設計,對於特殊場景我們也是要特殊處理的。就拿秒殺來說,可能會有百萬級別的使用者進行搶

【本人禿頂程式設計師】介面演算法之漏桶演算法&令牌桶演算法

←←←←←←←←←←←← 快,點關注! 工作中對外提供的API 介面設計都要考慮限流,如果不考慮限流,會成系統的連鎖反應,輕者響應緩慢,重者系統宕機,整個業務線崩潰,如何應對這種情況呢,我們可以對請求進行引流或者直接拒絕等操作,保持系統的可用性和穩定性,防止因流量暴增而導致的系統執行緩慢

Java併發:分散式應用實踐

任何限流都不是漫無目的的,也不是一個開關就可以解決的問題,常用的限流演算法有:令牌桶,漏桶。在之前的文章中,也講到過,但是那是基於單機場景來寫。 然而再牛逼的機器,再優化的設計,對於特殊場景我們也是要特殊處理的。就拿秒殺來說,可能會有百萬級別的使用者進行搶購,而商品數量遠遠小於使用者數量。如

常見演算法研究與實現

一、限流場景        很多做服務介面的人或多或少的遇到這樣的場景,由於業務應用系統的負載能力有限,為了防止非預期的請求對系統壓力過大而拖垮業務應用系統。也就是面對大流量時,如何進行流量控制?服務介面的流量控制策略:分流、降級、限流等。本文討論下限流策略,雖然降低了服務

網際網路閘道器設計之演算法

騰訊王卡業務第一代閘道器設計架構如上圖所示,也許有許多人會問,nginx本身就能做網關了,為什麼還需要另外開發閘道器呢? 答案是nginx開發閘道器,線上現有成員技術背景下,條件不成熟,為了快速構建我們的微服務架構,所以我們選擇了基於spring cloud zuul做

基於 Redis 實現分散式應用

限流的目的是通過對併發訪問/請求進行限速或者一個時間視窗內的的請求進行限速來保護系統,一旦達到限制速率則可以拒絕服務 實際場景中常用的限流策略: Nginx接入層限流 按照一定的規則如帳號、

常見的演算法以及應用

常見的限流演算法 令牌桶演算法 1)存放固定令牌的桶,生產令牌的速率固定 2)當令牌達到上限時候,產生的令牌被丟棄或拒絕 3)n個請求過來,拿n個令牌,若令牌不足,則請求被決絕或等待 漏桶演算法 1)桶容量固定,固定速錄流出 2)桶是空的,

演算法之令牌桶

一、令牌桶演算法和漏桶演算法1、漏桶演算法,有一個固定大小的桶,桶中的流量按照固定的速率流出,此時若有流量流入桶中,如果流入的速率比流出的速率大,則可能導致超過桶大小的流量溢位。2、令牌演算法,有一個固定大小的桶,按照一定的速率往桶中放入令牌,如果令牌超過桶大小則會溢位,此時

演算法的理解和應用場景和實現[臨界點處理]

在開發高併發系統時,有三把利器來保護系統:快取、降級和限流。一下有幾種限流的方法可以參考。 訊號量和令牌桶的區別:     訊號量限制的是併發,資源. 令牌桶如果耗時比較高的話,併發可能會比較大. 限制的是 qps. 計數器法 計數器法是限流演算法裡最簡單也是

分散式系統策略(二)

前文中介紹了系統限流的原理和基礎的使用場景,本篇將介紹應用接入層(Nginx)、分散式應用如何限流。 應用接入層限流(Nginx/OpenResty) 接入層通常是指流量的入口,主要的目的有:負載均衡、非法請求過濾、請求聚合、快取、降級、限流、A/B測

基於redis的分散式RateLimiter()實現

業務背景 系統需要對接某IM廠商rest介面,向客戶端推送訊息(以及其他IM業務) 該廠商對rest介面呼叫有頻率限制:總rest呼叫9000次/30s;訊息推送600次/30s 系統為分散式叢集,需要控制整個分散式叢集總的介面呼叫頻率滿足以

演算法之漏桶演算法、令牌桶演算法

昨天CodeReview的時候看到同時使用RateLimiter這個類用作QPS訪問限制.學習一下這個類. RateLimiter是Guava的concurrent包下的一個用於限制訪問頻率的類. 1.限流 每個API介面都是有訪問上限的,當訪問頻率或者併發量超過其承受

簡析演算法

1.簡介 限流顧名思義是限制流量,限制流量的目的是為了保障服務穩定執行,避免服務被流量沖垮。當流量超出服務處理能力時,部分請求將會被限流元件攔截。被攔截的請求可能會被丟棄,如果是 C 端請求,那麼這個請求可能會被導向指定的錯誤頁上,而不是生硬的拒絕。這裡我們丟棄掉一部分請求,以保證大部分請求可以正常響應。如果