你好，大家可以叫我“小農”，這是我更新的第 68 篇文章，點贊再看，養成習慣，點擊左上角藍字關注我??牧小農。

前言

上一篇文章中，我們講解了關于sentinel基本介紹以及流控規則中直接和快速失敗的效果，有興趣的可以去看上一篇文章，今天，我們給大家帶來更加詳細的關于sentinel流控規則的介紹。今天的內容我們主要圍繞四個點進行展開介紹。

• 流控模式 ：關聯、鏈路。
• 流控效果 ：Warm Up、排隊等待。

這四點具體是什

么意思呢?別急我們一個一個來做詳細的介紹，首先我們從關聯開始。

首先啟動項目：cloud-alibaba-sentinel-8006

關聯

在官方的介紹中是這樣說的：關聯的資源達到閾值時，就限流自己。

這句話是什么意思呢?用比較直白一點的話來講，假設我們有A和B兩個接口，當A關聯B接口，同時B接口的資源達到設定的閾值時，限流A。我們也可以理解成，當我們下游的服務出現訪問壓力過大時，對上游的服務進行攔截和限流操作，例如：電商系統，當我們訂單系統超出承受閾值時，對我們支付模塊進行限流。

例如：當我們關聯order接口達到我們設定的閾值時，限流pay的接口訪問。

@Slf4j
@RestController
public class TestController {
    @GetMapping("/pay")
    public String pay() {
        return "hello my name is pay ,wo shi boy";
    }
    @GetMapping("/order")
    public String order(){
        return "hi my name is order, me is girl";
    }
}

給pay接口添加流控規則。

在這里我們需要使用到postMan工具，來模擬并發訪問，用它來測試我們的order接口的并發訪問。

在這里的意思是25個線程0.25秒跑一次，當我們跑起來之后，再去訪問pay接口就可以看到以下信息

當我們對order接口進行并發訪問的時候，這個時候我們去訪問pay接口，就可以看到pay接口返回限流信息

鏈路

接下來我們就來看一下流控模式中的鏈路，鏈路的意思是當某個接口過來的資源達到閾值時，開啟限流，主要是針對于請求來源的微服務，具有更細顆粒度。

比如在一個服務應用中，多個(pay和order)接口都調用了同一個服務中的方法(該方法必須使用注解 SentinelResource進行修飾)，如果頻繁的去請求pay接口，并且達到設定的閾值，這么時候我們再去請求order接口，那么調用了同一服務的order接口就會被限流。

。

test類

@Service
public class TestService {
    // 定義限流資源
    @SentinelResource("end")
    public String end(){
        return "end method";
    }
}

controller類

@Slf4j
@RestController
public class TestController {
    @Autowired
    private TestService testService;
    @GetMapping("/pay")
    public String pay() {
        return testService.end();
    }
    @GetMapping("/order")
    public String order(){
        return testService.end();
    }
}

配置項web-context-unify，這個配置的意思是說根據不同的URL進行鏈路限流，否則沒有效果

spring:
  application:
    name: cloudalibaba-sentinel-service
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
    sentinel:
      transport:
        #配置Sentinel地址，就是我們的WEB界面
        dashboard: localhost:8080
        #Sentinel配置默認8719端口，被占用端口會自動從+1，直到找到未被占用的端口
        port: 8719
        # 配置為false
      web-context-unify: false

我們訪問pay接口和order接口后，需要對end進行流控規則的配置，也就是使用了SentinelResource注解標注的方法進行流控設置。

那么這個時候如果我們頻繁的去訪問order接口的時候，就會出現異常的情況，直接拋出錯誤提示，這個也是因為快速失敗在鏈路上的直接體現。

Warm Up

參考文檔：https://sentinelguard.io/zh-cn/docs/flow-control.html。

Warm Up 流量控制，也叫預熱或者冷啟動方式，會根據我們設定的規則，進行緩慢的流量放開，逐漸增加閾值上限，給系統一個反應時間，避免流量的突然增加，將系統壓垮的情況發生，主要用于預防我們系統長期處于穩定的流量訪問下，突然流量的增加，將系統資源直接拉滿的情況.

在這里我們主要弄明白兩個參數

單機閾值：12，這個表示我們訪問最大閾值為12，但是第一次最大訪問量為4，為什么是4呢，看下面公式

預熱公式：閾值/coldFactor(默認值為3)，經過預熱時間后才會達到閾值。

預熱時長：5 ，也就是說我們的請求會在五秒內單機閾值達到12的訪問，比如第一次為4，后續在五秒內依次5/6/8/10，最后達到12的閾值

一般這種在秒殺或者電商節中會設置這樣的流控規則，就是為了防止突然流量的增加導致系統的崩潰。

當我們設置完流控規則以后，我們就來看一下效果，我們剛才設置的order的接口，如果當我們在頻繁的去訪問order接口的時候，如果超過當前時間設定的閾值時，直接返回限流信息。

在這里我們直接用瀏覽器瘋狂的去刷新，是時候體驗單身二十幾年的手速了，當然也可以使用postman接口去試，我們這邊手速比較快，直接用瀏覽器刷新，我們可以看到下面的曲線圖：

藍色表示你拒絕的QPS，綠色表示通過的QPS，我們可以看到藍色成明顯的下降趨勢，而綠色成上升趨勢，也可以通過右邊的表格中看到，剛開始通過的只有四個，具體的有三個，后面通過慢慢增加，拒絕慢慢變少，這個就是我們Warm Up(預熱)的作用了

排隊等待

我們現在來介紹最后一個流控規則的使用，排隊等待會嚴格控制請求通過的間隔時間，讓請求穩定且勻速的通過，可以用來處理間隔性突發的高流量，例如搶票軟件，在某一秒或者一分鐘內有大量的請求到來，而接下來的一段時間里處于空閑狀態，我們希望系統能夠在接下來的空余時間里也能出去這些請求，而不是直接拒絕。

以固定的間隔時間讓請求通過，當請求過來的時候，如果當前請求距離上一個請求通過的時間大于 規則預設值 ，則請求通過，如果當前請求預期通過時間小于 規則預設值 ，則進行排隊等待，如果預期通過時間超過最大排隊時間，直接拒絕請求。

Sentinel排隊等待是 漏銅算法+虛擬隊列機制實現的，目前排隊等待中不支持QPS>1000的場景。

我們對pay接口進行設置，一秒鐘只處理一個QPS請求，其他的排隊，如果超過15秒則直接拒絕。

pay接口調整，這里我們給pay接口加上打印日志，方便我們看到具體效果。

    @GetMapping("/pay")
    public String pay() {
//        return "hello my name is pay ,wo shi boy";
        log.info("pay接口，請求線程為："+Thread.currentThread().getName());
        return testService.end();
    }

我們借助postman來進行調用，說明手速始終跟不上工具，還是工具香，這里我們設置10個請求，沒有間隔時間

從下圖中我們可以看到，對于我們的請求，是一個QPS請求。

總結

到這里呢，我們的流控規則就講完了，主要是針對不同的規則進行不同的設定，來滿足我們不用業務場景，可能會有一點點的小繞，但是如果親自操作之后，會感覺原來是這樣，感興趣的小伙伴可以自己動手試一試，源碼都已經上傳了，只有動手了才能感受到其中的快樂，趕緊去試一試吧。