你好，大家可以叫我“小農(nóng)”，這是我更新的第 68 篇文章，點贊再看，養(yǎng)成習(xí)慣，點擊左上角藍(lán)字關(guān)注我??牧小農(nóng)。

前言

上一篇文章中，我們講解了關(guān)于sentinel基本介紹以及流控規(guī)則中直接和快速失敗的效果，有興趣的可以去看上一篇文章，今天，我們給大家?guī)砀釉敿?xì)的關(guān)于sentinel流控規(guī)則的介紹。今天的內(nèi)容我們主要圍繞四個點進(jìn)行展開介紹。

• 流控模式 ：關(guān)聯(lián)、鏈路。
• 流控效果 ：Warm Up、排隊等待。

這四點具體是什

么意思呢?別急我們一個一個來做詳細(xì)的介紹，首先我們從關(guān)聯(lián)開始。

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

關(guān)聯(lián)

在官方的介紹中是這樣說的：關(guān)聯(lián)的資源達(dá)到閾值時，就限流自己。

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

例如：當(dāng)我們關(guān)聯(lián)order接口達(dá)到我們設(shè)定的閾值時，限流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接口添加流控規(guī)則。

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

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

當(dāng)我們對order接口進(jìn)行并發(fā)訪問的時候，這個時候我們?nèi)ピL問pay接口，就可以看到pay接口返回限流信息

鏈路

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

比如在一個服務(wù)應(yīng)用中，多個(pay和order)接口都調(diào)用了同一個服務(wù)中的方法(該方法必須使用注解 SentinelResource進(jìn)行修飾)，如果頻繁的去請求pay接口，并且達(dá)到設(shè)定的閾值，這么時候我們再去請求order接口，那么調(diào)用了同一服務(wù)的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，這個配置的意思是說根據(jù)不同的URL進(jìn)行鏈路限流，否則沒有效果

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

我們訪問pay接口和order接口后，需要對end進(jìn)行流控規(guī)則的配置，也就是使用了SentinelResource注解標(biāo)注的方法進(jìn)行流控設(shè)置。

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

Warm Up

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

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

在這里我們主要弄明白兩個參數(shù)

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

預(yù)熱公式：閾值/coldFactor(默認(rèn)值為3)，經(jīng)過預(yù)熱時間后才會達(dá)到閾值。

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

一般這種在秒殺或者電商節(jié)中會設(shè)置這樣的流控規(guī)則，就是為了防止突然流量的增加導(dǎo)致系統(tǒng)的崩潰。

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

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

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

排隊等待

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

以固定的間隔時間讓請求通過，當(dāng)請求過來的時候，如果當(dāng)前請求距離上一個請求通過的時間大于 規(guī)則預(yù)設(shè)值 ，則請求通過，如果當(dāng)前請求預(yù)期通過時間小于 規(guī)則預(yù)設(shè)值 ，則進(jìn)行排隊等待，如果預(yù)期通過時間超過最大排隊時間，直接拒絕請求。

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

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

pay接口調(diào)整，這里我們給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來進(jìn)行調(diào)用，說明手速始終跟不上工具，還是工具香，這里我們設(shè)置10個請求，沒有間隔時間

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

總結(jié)

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