【系統設計】設計一個限流元件

SpringLeee 發表於 2022-05-26

限速器 (Rate Limiter) 相信大家都不會陌生,在網路系統中,限速器可以控制客戶端傳送流量的速度,比如 TCP, QUIC 等協議。而在 HTTP 的世界中, 限速器可以限制客戶端在一段時間內傳送請求的次數,如果超過設定的閾值,多餘的請求就會被丟棄。

生活中也有很多這樣的例子,比如

  • 使用者一分鐘最多能發 5 條微博
  • 使用者一天最多能投 3 次票
  • 使用者一小時登入超過5次後,需要等待一段時間才能重試。

【系統設計】設計一個限流元件

限速器(Rate Limiter)有很多好處,可以防止一定程度的 Dos 攻擊,也可以遮蔽掉一些網路爬蟲的請求,避免系統資源被耗盡,導致服務不可用。

設計要求

讓我們從一個面試開始吧!

【系統設計】設計一個限流元件

面試官:你好,我想考察一下你的設計能力,如果讓你設計一個限速器 (Rate Limiter),你會怎麼做?

面試者: 我們需要什麼樣的限速器? 它是在客戶端限速還是在服務端限速?

面試官:這個問題很好,沒有固定要求,取決於你的設計。

面試者:我想了解一下限速的規則,我們是根據 IP、UserId,或者手機號碼進行限速嗎?

面試官:這個不固定,限速器應該是靈活的,要能很方便的支援不同的規則。

面試者:如果請求被限制了,需要提示給使用者嗎?

面試官:需要提示,要給使用者提供良好的體驗。

面試者:好吧,那系統的規模是多大的?是單機還是分散式場景?

面試官:我們是 TOC 的產品, 系統流量很大,並且是分散式的環境, 所以限速器要支援海量請求。

面試者:(小聲嘀咕)你這是造火箭呢?

我們總結一下限速器的設計要求:

  • 低延遲,效能要好
  • 需要適用於分散式場景。
  • 使用者的請求受到限制時,需要提示具體的原因。
  • 高容錯,如果限速器故障,不應該影響整個系統。

限速器應該放在哪裡?

從系統整體的角度上來看,我們的限速器應該放在哪裡?通常有三種選擇,如下

客戶端

是的,我們可以在客戶端設定限速器。但是有個問題是,我們都知道在 Web 前端做一些限制實際上是不安全的,同樣客戶端也是一樣的, 限速客戶端可以做,但是遠遠不夠。

服務端

在服務端設定限速器是很常見且安全的,如下

【系統設計】設計一個限流元件

中介軟體

還有一種做法是,我們可以提供一個單獨的限速中介軟體,如下

【系統設計】設計一個限流元件

假如限速器設定了每秒最大允許2個請求,那麼客戶端發出的多餘的請求就會被拒絕,並返回 HTTP 狀態碼 429, 表示使用者傳送了太多的請求。

【系統設計】設計一個限流元件

實際上,很多閘道器都有限速的實現,包括認證、IP 白名單功能。

限速器應該放在哪裡?沒有固定的答案,它取決於公司的技術棧,系統規模。

限速演算法

實際上,我們可以用演算法實現限速器,下面是幾種經典的限速演算法,每種演算法都有自己的優點和缺點,瞭解這些可以幫助我們選擇更適合的演算法。

  • 令牌桶 (Token bucket)
  • 漏桶(Leaking bucket)
  • 固定視窗計數器(Fixed window counter)
  • 滑動視窗日誌(Sliding window log)
  • 滑動視窗計數器(Sliding window counter)

令牌桶演算法

令牌桶演算法是實現限速使用很廣泛的演算法,它很簡單也很好理解。

令牌桶是固定容量的容器。

一方面,按照一定的速率,向桶中新增令牌,桶裝滿後,多餘的令牌就會被丟棄。

如下圖,桶的容量為4,每次填充2個令牌。

【系統設計】設計一個限流元件

另一方面,一個請求消耗一個令牌,如果桶中沒有令牌了,則拒絕請求。直到下個時間段,繼續向桶中填充新的令牌。

【系統設計】設計一個限流元件

令牌桶演算法有兩個重要的引數,分別是桶大小和填充率,另外有時候可能需要多個桶,比如多個 api 限速的規則是不一樣的。

令牌桶演算法的優點是簡單易實現,並且允許短時間的流量併發。缺點是,在應對流量變化時,正確地調整桶大小和填充率,會比較有挑戰性。

漏桶演算法

漏桶演算法和令牌桶演算法是類似的,同樣有一個固定容量的桶。

一方面,當一個請求進來時,會被填充到桶裡,如果桶滿了,就拒絕這個請求。

另一方面,想象桶下面有一個漏洞,桶裡的元素以固定的速率流出。

通常可以用先入先出的佇列實現,如下圖

【系統設計】設計一個限流元件

漏桶演算法有兩個引數,分別是桶大小和流出率,優點是使用佇列易實現,缺點是,面對突發流量時,雖然有的請求已經推到佇列中了,但是由於消費的速率是固定的,存在效率問題。

固定視窗計數器演算法

固定視窗計數器演算法的工作原理是,把時間劃分成固定大小的時間視窗,每個視窗分配一個計數器,接收到一個請求,計數器就加一,一旦計數器達到設定的閾值,新的請求就會被丟棄,直到新的時間視窗,新的計數器。

讓我們通過下面的例子,來看看它是如何工作的。一個時間視窗是1秒,每秒最多允許3個請求,超出的請求就會被丟棄。

【系統設計】設計一個限流元件

不過這個演算法有一個問題是,如果在時間視窗的邊緣出現突發流量時,可能會導致通過的請求數超過閾值,什麼意思呢?我們看看下面的情況

【系統設計】設計一個限流元件

一個時間視窗是1分鐘,每分鐘最多允許5個請求。如果前一個時間視窗的後半段有5個請求,後一個時間視窗的前半段有5個請求,也就是 2:00:30 到 2:01:30 的一分鐘內,是可以通過10個請求的,這明顯超過了我們設定的閾值。

固定視窗計數器的優點是,簡單易於理解,缺點是,時間視窗的邊緣應對流量高峰時,可能會讓通過的請求數超過閾值。

滑動視窗日誌演算法

我們上面看到了,固定視窗計數器演算法有一個問題,在視窗邊緣可能會突破限制,而滑動視窗日誌演算法可以解決這個問題。

它的工作原理是,假如設定1分鐘內最多允許2個請求,每個請求都需要記錄請求時間,比如儲存在 Redis 的 sorted sets 中,儲存之後還需要刪除掉過時的日誌,過時日誌是如何定義的?比如某次請求的時間是 1:01:36,那麼往前推1分鐘,1:00:36 之前的日誌都算過時的,需要從集合中刪掉。同時,判斷集合中的數量是否大於閾值,如果大於2則丟棄請求,如果小於或等於2,則處理這個請求。

讓我們看看下面的例子

【系統設計】設計一個限流元件

  1. 在 1:00:01 來了一個請求,第一步,記錄請求時間到日誌中,第二步,判斷是否有過時的日誌, 也就是 0:59:01 之前的日誌,明顯沒有,第三步判斷日誌中的數量,沒有大於2,處理這次請求。
  2. 在 1:00:30 來了一個請求,執行上面的三個步驟,最後處理這次請求。
  3. 在 1:00:50 的新請求,沒有過時的日誌,然後發現日誌的數量為3,拒絕這次請求。
  4. 在 1:01:40 的新請求,清除2條過時的日誌,也就是 1:00:40 之前的日誌,此時,日誌中的數量為2,處理這次請求。

這個演算法實現的限速非常準確,但是它可能會消耗較多的記憶體。

滑動視窗計數器演算法

滑動視窗計數器可以說是固定視窗計數器的升級版,上面提到了,固定視窗計數器存在視窗邊緣可能會有超出限制的情況,如下

【系統設計】設計一個限流元件

而滑動視窗把固定的視窗又分成了很多小的視窗單位,比如下圖,每個固定視窗的大小為1分鐘,又拆分成了6份,每次移動一個小的單位,保證總和不超過閾值。

【系統設計】設計一個限流元件

這樣就可以避免上面的視窗邊緣超出限制的問題。

【系統設計】設計一個限流元件

使用 Redis 實現高效計數器

限速器演算法的思想其實很簡單,我們需要使用計數器記錄使用者的請求,如果超過閾值,服務這個請求,否則,拒絕這個請求。

一個很重要的問題是,我們應該把計數器放在哪裡?我們知道,磁碟速度比較慢,使用資料庫明顯是不太現實的方案,想要更快的話,可以使用記憶體快取,最常見的就是 Redis,是的,我們可以使用 Redis 實現高效計數器,如下

【系統設計】設計一個限流元件

規則引擎

Lyft 是一個開源的限速元件,可以供我們參考,它通過 Yaml 配置檔案實現靈活的限速規則,看下面的示例

【系統設計】設計一個限流元件

這個配置表示系統每天只能傳送 5 條營銷資訊。

【系統設計】設計一個限流元件

這個配置表示 1分鐘的登入次數不能超過 5 次。

可以看到,基於配置檔案,宣告式的限速規則是非常靈活的,我們可以把配置檔案儲存到磁碟中。

返回限速資訊

當請求超過限制時,限速器會拒絕掉其他的請求,這樣其實不夠,為了更好的使用者體驗,我們需要返回友好的錯誤資訊給使用者,並提示。

首先,限速器拒絕請求後,可以返回 HTTP 狀態碼 429,表示請求過多。

其次,我們可以返回更詳細的資訊,比如,剩餘請求次數、等待時間等。一種很常見的做法時,把這些資訊放到 Http 響應的 Header 中返回,如下

  • X-Ratelimit-Remaining:表示剩餘次數
  • X-Ratelimit-Limit:表示客戶端每個時間視窗可以進行多少次呼叫
  • X-Ratelimit-Retry-After:表示等待多長時間可以進行重試

看起來不錯!讓我們看看現在的架構設計

【系統設計】設計一個限流元件

首先,限速規則儲存在磁碟上,因為要經常訪問,可以新增到快取中。當客戶端向伺服器傳送請求時,會先傳送到限速中介軟體。限速中介軟體從快取中拉取限速規則,同時把請求資料寫入到 Redis 的計數器,然後判斷是否超出限制。如果沒有超出限制,把請求轉發給我們的後端伺服器。如果超出了限制,第一種方案,丟棄多餘的請求,返回 429,第二種方案,把多餘的請求推送到訊息佇列中,後續再進行處理。使用哪種方案,取決於您的實際場景。

分散式環境

構建一個在單伺服器執行的限速器是很簡單的,但是在分散式環境中,支援多臺伺服器,那就完全是另外一回事了。

我們主要要考慮兩個問題:

  • 併發問題
  • 資料同步問題

併發問題,我們的限速器的工作原理是,當接收到新的請求時,從 Redis 中讀取計數器 counter,然後做加一的操作,在高併發場景中,可能存在多個執行緒讀到了舊的值,比如,兩個執行緒同時讀取到 counter 的值為3,然後都把 counter 改成了4,這樣是有問題的,其實最終應該是 5。

有朋友說,我們可以用鎖,但實際上,鎖的效率是不高的。解決這個問題通常有兩個方案,第一個是使用 Lua 指令碼,第二個是使用 Redis 的 sorted sets 資料結構,具體的細節本文不做過多介紹。

資料同步問題,在流量比較大的情況下,一個限速器是難以支撐的,我們需要多個限速器。由於 Web 層通常是無狀態的,客戶端的請求會隨機傳送給不同的限速器,如下

【系統設計】設計一個限流元件

這種情況下,如果沒有資料同步,我們的限速器肯定是沒辦法正常工作的。

我們可以使用像 Redis 這樣的集中式資料儲存,如下

【系統設計】設計一個限流元件

效能優化

當我們的系統是面向全球使用者時,為了讓各個地區的使用者都能有一個不錯的體驗,通常會在不同的地區設定多個資料中心。另外,現在很多雲服務商在全球各地都有邊緣伺服器,流量會自動路由到最近的邊緣伺服器,來減少網路的延遲。

【系統設計】設計一個限流元件

當然,存在多個資料中心時,可能還要考慮到資料的最終一致性。

總結

在本文中,我們討論了不同的限速演算法,以及它們有優缺點,演算法包括:

  • 令牌桶
  • 漏桶
  • 固定視窗計數器
  • 滑動視窗日誌
  • 滑動視窗計數器

然後,我們討論了分散式環境中的系統架構,併發問題和資料同步問題,和靈活配置的限速規則,最後你會發現,實現一個限速器,其實沒有那麼難!

希望對您有用!

譯:等天黑

作者:Alex Xu

來源:《System Design Interview》

簡介: Alex Xu 是一位經驗豐富的軟體工程師, 曾在 Twitter, Apple 和 Oracle 任職,來自CS名校卡內基梅隆大學,熱衷於系統設計。

【系統設計】設計一個限流元件

相關文章