一、流控規則：流控效果

流控效果有當前支持三種：直接失敗、預熱（warm up）、排隊等待。
直接失敗沒什么可說的，下面主要圍繞預熱和排隊等待展開。

一）、流控效果：預熱

主要針對開啟活動之前，系統流量是比較低的，比如秒殺活動即將開始后，系統訪問量突增，可能把系統壓垮，增加預熱流控規則，是個比較好的方案。

1、概念含義

預熱就是下圖流控效果里，Warm Up ；即 預熱/冷啟動方式；這種方式用于系統長期處于低流量的情況，當流量突然激增，由于流量的突然激增可能瞬間會把系統壓垮。通過這種“冷啟動”的方式，讓通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，給系統一個緩沖的時間，通過這種冷啟動的方式避免系統被壓垮。
預熱公式為 單機閾值/coldFactor（預熱因子，默認為3），經過預熱時間后，才會達到閾值。

設置參數后的具體含義通過案例闡述。

2、案例

這種預熱流控的設置，通常的場景類如 秒殺，主要是為了防止瞬間激增的流量打垮系統。關于設置秒殺的代碼及配置如下：

端口9101服務，秒殺接口代碼段：

   /*** 秒殺活動，設置預熱的流控規則*/@GetMapping("/secKill")public String secKill() throws InterruptedException {log.info("---secKill---流控模式為 預熱");Thread.sleep(200);return "ok";}

yaml文件配置內容如下：

server:port: 9101
spring:application:name: nacos-consumercloud:nacos:discovery:server-addr: 192.168.0.101:80sentinel:transport:dashboard: localhost:8080   port: 8720   web-context-unify: falsemanagement:endpoint:web:exposure:include:'*'
service-url:nacos-user-service: http://nacos-provider

主啟動類添加服務發現注解：

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;@EnableDiscoveryClient
@SpringBootApplication
public class NacosConsumer9101Application {public static void main(String[] args) {SpringApplication.run(NacosConsumer9101Application.class, args);}}

啟動服務訪問，初始化sentinel的簇點鏈路，訪問鏈接：http://localhost:9101/secKill

在資源 /secKill添加流控規則。

流控規則設置

該流控規則設置含義：當單機 QPS達到10，預熱時長是5秒。
在這 5s內流量有個流量突增的過程，預熱因子默認是3，根據預熱公式，當QPS超過單機閾值的三分之一，即超過3時，就開始限流，隨著5s的推移，第一秒可能是3，第二秒是4，第5s是10。這個預熱的流控效果，其實指的就是系統處理流量突增的過程。

測試結果

流控規則設置完之后，并發線程數設置為10，持續2min，開始進行壓測【工具jmeter】：

觀察資源流量的實時監控情況，可看出QPS超過10 之后，拒絕QPS那列有了數值，說明被限流了。再看下壓測接口響應失敗jmeter的顯示內容，提示被限流了：

二）、流控效果：排隊等待

1、概念含義

勻速排隊的方式，可以嚴格控制請求通過的時間間隔，就是讓請求勻速通過，對應算法為漏桶算法。
這種方式主要用來處理間隔性突發流量，類似消息隊列，在某一秒大量請求襲來，而后處于空閑狀態，可以讓空閑時間處理先前這大批量的請求，而不是第一時間拒絕多余的請求。
類似一個勻速器，在固定時間間隔讓請求通過：

• 若當前請求距離上個通過的請求通過的時間間隔大于預設值，則請求通過。
• 否則，若當前請求的預期時間<規則預設的超時時間，那當前請求就要等待直到大于預設值則請求通過。
• 若預期的通過時間超過最大排隊時長，則直接拒絕這個請求。

Sentinel的勻速排隊等待流控效果，是基于漏桶算法結合虛擬隊列等待機制實現的。
注意??：勻速排隊模式暫時不支持QPS超過1000的場景。

2、案例

比如這個例子：QPS單機閾值超過5，則進行排隊等待，在15s內 ，1s處理5個，超過15s 還沒處理完的其他請求，則視為超時。

流控規則設置

測試及結果

壓測并發量10，持續2min，訪問鏈接：http://localhost:9101/waiting
觀察Sentinel流量監控平臺的變化以及指標統計情況：

前半段超時時間設置的15s ，可以看到沒有被限流的請求。
后半段藍色折線圖，流控規則排隊等待的超時時間調整為1s，觀察圖表可以看到超過1s的請求視為超時，還沒處理的請求都被限流了：

查看響應失敗的接口響應信息展示：

二、流控規則實際使用總結

關于流控規則，主要圍繞 ：閾值類型，流控模式，流控效果這三個維度，做的測試以及釋義，當然最主要還是實際應用場景，下面是具體闡述這三個維度組合起來，分別適合哪些特點的場景，以及實際對應的業務場景案例， 還有配置時注意事項。

一）、閾值類型、流控模式、流控效果組合及適用場景

其實在上一篇和本文都已陸續說過，但比較零散，還是需要單獨梳理一下，算是鞏固加強印象了，希望能對讀者在工作中有幫助；組合使用大致梳理出6個點。

1、閾值為QPS 、流控模式為直接、快速失敗[的流控效果]

1）規則適用的業務特點

直接限制單個資源每秒請求量，超出的請求會被立即拒絕。這種規則可快速響應流量突發狀況，能有效保護資源不被過度請求。

2）適用場景

• 驗證碼發送，防止惡意刷驗證碼的行為，可設置QPS閾值，同樣超出閾值則直接拒絕。

3）配置時要注意的事項

具體設置的值要參考日常流量以及歷史高峰流量倍數作壓測指標，進行摸底壓測，大促期間可以此摸底性能為閾值上限，進行設置，注意??，絕不能高于摸底上限，否則無法起到保護作用，也不能太低，否則會影響正常業務。

2、閾值為QPS 、流控模式為關聯、快速失敗[的流控效果]

1）規則適用的業務特點

根據關聯資源的QPS閾值，來控制當前資源的訪問。當關聯資源達到閾值，則對當前資源進行限流，通過關聯關系間接保護關聯資源不被壓垮。

2）適用場景

• 創單和支付，創單之后，會調用支付接口，可以創建流控規則，關聯資源為支付，設置關聯資源閾值，當支付達到該閾值，則對創單接口進行限流。
• 訂單系統中，創單和扣減庫存也是一樣的道理，避免賣超的方案之一，可以將扣減庫存設為關聯資源，當其QPS過高，超過閾值，依然要對創單接口進行限流。
• 支付系統中，支付接口和用戶的資金賬戶 同理，可將用戶的資金賬戶設為關聯資源，當QPS過高，超過其實際承載流量的閾值，這時支付的性能會受到影響，此時可對支付接口進行流控。

3）配置時要注意的事項

要準確識別到關聯資源，確保關聯的合理性，另外還要注意的點是，關聯資源的閾值設置要考慮兩個資源之間的業務邏輯關系。

一般作為關聯資源的，可以是公共服務等設置為關聯資源 或者 特點是業務鏈路的后置服務，如果該資源實際性能較差且不在核心鏈路上，可以設置為關聯資源，以此來保護該資源不被壓垮。
如果該資源在核心鏈路上，除了讓其成為關聯資源，還要進行優化，優化性能指標至少要跟核心鏈路起始資源性能對齊，如果內部涉及到第三方接口調用，無法提升性能，則要考慮技術方案的調整，比如看哪些業務數據可以前置操作，串行調用調整為并發編程，同步改為異步方式實現。具體還是要結合實際業務作技術方案調整的決策。
而且，被設置為關聯的資源，通常是該資源容易遇到性能瓶頸，就是性能不足與當前系統流量高峰或歷史高峰時的需求相匹配，所以要設置為關聯資源以此來保護其功能保持在正常水平。

3、閾值為QPS 、流控模式為鏈路、快速失敗[的流控效果]

1）規則適用的業務特點

只對指定鏈路的資源請求進行QPS限制，即當鏈路入口資源達到閾值，則對其進行限流。能精確控制特定調用鏈路流量，有效避免因該鏈路流量過大影響系統性能。

2）適用場景

• 微服務架構中，某個服務可能涉及多個調用鏈路，若其中一條調用鏈路過大，可對該鏈路進行流控。場景比如 商品詳情服務調用 加車服務，再調用結算服務這條調用鏈路，可以設置鏈路QPS閾值，超過則拒絕請求。
• 某個接口有不同的調用來源，可對該特定來源的調用鏈路進行流控，比如結算創單資源接口，可以是普通商品調用鏈路的一個節點，也可以是促銷如秒殺調用鏈路的一個節點，為了保護系統資源能正常服務，可以對秒殺等其他大流量的調用鏈路做鏈路流控配置。

3）配置時要注意的事項

明確要配置的鏈路規則，指定受流控的鏈路。同時，考慮鏈路閾值的動態變化，做出及時調控。

4、閾值為QPS 、流控模式為直接、Warm Up[的流控效果]

1）規則適用的業務特點

系統啟動初期QPS較低，隨時間推移，閾值逐漸增加到日常流量最大值，流控效果為預熱模式，啟動階段可讓系統有個流量適應過程。

2）適用場景

新上線服務，系統初始化階段性能不穩定，可通過設置預熱流控效果，能有效避免大量流量短時間涌入系統造成崩潰；比如服務版本升級重啟，防止大量請求在瞬間擊垮系統，可設置流控效果為預熱模式。

促銷活動，在活動開始之前，就會有一個流量持續增加的過程，比如秒殺前，系統流量會在段時間內迅速增加，所以要設置預熱，即提前限流，會超過系統負載導致崩潰無法正常工作，對此場景，可設置QPS閾值，超出直接拒絕。

3）配置時要注意的事項

要合理設置預熱時間和初始閾值，預熱時間過短無法起到預熱效果，過長則影響系統響應速度。

5、閾值為QPS 、流控模式為直接、排隊[的流控效果]

1）規則適用的業務特點

請求超過QPS閾值，會進入排隊等待， 從隊列中勻速取出請求進行處理，可保證請求有序處理。此流控效果，適合非核心業務，比如某些營銷類（不是全部哈，根據當前階段業務重要程度，杠精請口下留情哈），對實時性要求不高，甚至可以滯后或降級處理的業務。

2）適用場景

• 文件上傳接口，對該操作的響應時間要求相對較低，可接受一定時間內的等待。當上傳請求過多時，超出閾值的請求進入隊列進行排隊等待，然后按順序勻速處理(類比mq的削峰填谷)。
• 處理批量任務的時候，比如批量導入商品數據，可采用排隊等待的流控效果，保證數據處理的有序性。

3）配置時要注意的事項

設置合理隊列長度和超時時間，隊列長度過長占用系統大量資源，超時時間設置過長會導致用戶等待時間過長。
其實根源還是在接口本身的性能上要有所提升，如果時間允許，還是需要提升這種批量操作的性能，從而提升用戶體驗。

6、閾值為線程數 、流控模式為直接、快速失敗[的流控效果]

1）規則適用的業務特點

設置當前資源線程數量的閾值，當線程數達到閾值則后續線程會被直接拒絕，防止系統因線程過多導致資源耗盡。

2）適用場景

比如一些計算密集型的服務，像大數據分析任務處理接口，一定程度上要限制線程數來避免cpu出現資源過度占用的情況。
還有就是數據庫的連接數，我們通常在配置連庫信息時會設置，但是粒度不夠細，可以通過限制請求庫連接的線程數，來規避過多線程競爭數據庫連接的情況，比如查庫接口。

3）配置時要注意的事項

根據系統硬件資源和業務需求合理進行設置線程數閾值，避免過低影響系統正常并發處理能力，閾值過高那么流控規則就形同虛設了。

二）、配置注意事項總結

1、閾值評估

結合系統硬件資源（如cpu ,磁盤，內存，網絡等）、資源重要度（業務的核心程度級別）以及歷史流量峰值【大促期間和日常流量】，準確預估閾值，作為摸底性能測試基礎數據，在此基礎上，中小廠2到3倍，大廠10-20倍，留足余量，以此標準作壓力測試期望指標，以系統實際性能指標，作為閾值依據。

若接口性能不達標：
對于核心流程資源接口，則要進行優化,不能一味去做限流處理。
對于非核心資源接口，則要根據當前項目周期緊急程度，評估是否作限流或降級處理。

2、規則要動態調整

隨著時間的推移，業務在不停的迭代，用戶體量以及系統的流量也會因此發生變化，以往的規則不足以恒久滿足對系統性能的要求，所以要基于當前對系統性能的要求，對規則作動態調整。

3、監控與報警

結合Sentinel控制臺或其他監控工具（如阿里云的arms監控），實時監控系統流量以及性能，cpu，磁盤，內存，網絡等指標，合理設置報警的閾值，當流量接近或超過閾值時，及時通知相關人員。

4、規則持久化

使用Nacos、Zookeeper等配置中心存儲流控規則，確保規則在服務重啟后不會丟失，且可實現動態調整。

這個會在本欄目Sentinel文章的最后通過案例形式落地

5、測試及驗證

在正式環境使用新的流控規則前，要在測試環境充分測試，驗證規則的有效性以及合理性，避免影響正式環境
的業務。

看到這的小伙伴，你真的很棒！但是要堅持奧。

小結：

在保障核心業務穩定性的同時，最大化利用系統資源，滿足不同業務場景的需求。實際應用中需結合壓測數據、監控指標和業務特性動態調整規則。