随着現在微服務、分布式系統的發展，各個服務之間的相互調用越來越複雜。

為了保證自身服務的穩定性與高可用，當面對超過自身服務能力的請求調用時，要做一定的限流措施。

如同五一、國慶期間的旅遊出行、景區爆滿，遊客限流。我們的服務面對諸如秒殺、大促、618、雙十一以及可能的惡意攻擊、爬蟲等高并發、大流量的場景也需要做服務限流。

概念：對超出服務處理能力之外的請求進行攔截，對訪問服務的流量進行限制。

2.1 計數器法（固定窗口）

概念 ：在單位時間内，統計進入的請求數量，統計值達到限流阈值時，開始限流（如拒絕和排隊）。這個單位時間結束後，計算器清零，重新開始計數。

問題：在固定時間窗口切換處，最高可能會接收到2倍阈值的流量。

假如設置的時間窗口為5秒，限流阈值為10.

第5秒時進來10個流量，此時窗口内流量未超阈值。第6秒切換到下一個窗口，此時進來流量10，當前窗口流量仍未超阈值。但是 第5秒和第6秒的切換臨界處，短時間内進來了限流阈值的雙倍流量，此時服務可能會因為請求流量過多而發生異常。

固定窗口

2.2 滑動窗口算法

概念： 滑動窗口對固定窗口進行改良，将其細化，将一個時間窗口劃分為若幹個時間窗格，每個窗格代表固定的時間段（如1分鐘）、擁有獨立的計數器，每過固定時間（如1分鐘），将滑動窗口向前移動一格。滑動窗口中的窗格劃分越細，限流統計越精确。

假如設置的時間窗口為5秒，限流阈值為10.

第5秒時進來10個流量，此時窗口内流量未超阈值。第6秒時進來流量10,與此同時，滑動窗口右移一格，此時滑動窗口内（第2~6秒）流量為20，大于限流阈值，開始限流。

滑動窗口

2.3 漏鬥算法

概念：請求像水一樣注入漏鬥，然後以固定的速率流出。漏鬥未滿之前，請求可以一直進入；漏鬥滿，則請求拒絕。

漏鬥算法可以平滑流量，但是無法解決流量突增的問題。

漏鬥算法

2.4 令牌桶算法

概念：以恒定速率（令牌産生速率）向令牌桶中放入令牌，令牌桶滿（令牌桶大小）則無法放入。請求到達後先獲取令牌，拿到令牌後請求被處理并删除獲得的令牌。令牌不足時，請求無法獲得令牌，請求被拒絕。

令牌桶算法可以平滑限流，同時可以容忍突發流量。

3.1 服務拒絕

當請求流量達到限流阈值時，對多餘的請求直接拒絕。

可通過設計實現對指定域名、IP、客戶端、應用、用戶等不同來源的請求進行拒絕。

3.2 延時處理

通過将多餘的請求加入緩存隊列或延時隊列，來應對短期的流量突增，高峰期過後開始将堆積的請求流量逐漸處理。

3.3 請求分級（優先級）

對不同來源的請求設置優先級，先處理優先級更高的請求。如VIP客戶、重要的業務應用（如交易服務優先級高于日志服務）

3.4 動态限流

可以監控系統相關指标、評估系統壓力，通過注冊中心、配置中心等動态調整限流阈值。

3.5 監控預警&動态擴容

如果有優秀的服務監控系統與自動部署、發布系統，可以通過監控系統自動監測系統運行情況，對短期内服務壓力暴增、流量大幅寫入的情況進行郵件、短信等方式進行預警。

在滿足特定條件下，可自動部署、發布相關服務，起到動态擴容的效果。

4.1 接入層限流

可以通過Nginx、API路由網關等對域名或IP進行限流，同時可以攔截非法請求

4.2 應用限流

每個服務可以有自己的單機或集群限流措施，也可以調用第三方的限流服務

4.3 基礎服務限流

數據庫：限制數據庫連接、限制讀寫速率

消息隊列：限制消費速率（消費量、消費線程）

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!