具體啟動Sentinel的步驟可以參考我的上一篇文章。

概念

資源名：唯一名稱，默認請求路徑

針對來源：Sentinel可以針對調用者進行限流，填寫微服務名，默認default (不區(qū)分來源)

閱值類型單機閱值：
        QPS(每秒鐘的請求數量)：當調用該api的QPS達到值的時候，進行限流
        線程數：當調用該api的線程數達到闊值的時候，進行限流

是否集群：不需要集群

流控模式：
        直接：api達到限流條件時，直接限流
        關聯：當關聯的資源達到聞值時，就限流自己
        鏈路：只記錄指定鏈路上的流量(指定資源從入口資源進來的流量，如果達到闊值，就進行限流)[api級別的針對來源]
流控效果：
        快速失?。褐苯邮?，拋異常
        Warm Up(預熱)：根據codeFactor (冷加載因子，默認3) 的值，從聞值/codeFactor，經過預熱時長，才達到設置的QPS閩值
        排隊等待：勻速排隊，讓請求以勻速的速度通過，闊值類型必須設置為QPS，否則無效

流控規(guī)則

直接（默認）

控制層方法如下：

@RestController
public class SentinelController {
    @GetMapping("/testA")
    public String testA(){
        return "Sentinel testA run";
    }
    @GetMapping("/testB")
    public String testB(){
        return "Sentinel testB run";
    }
}

QPS+快速失敗

通過地址欄輸入：localhost:8401/testA

測試發(fā)現當每秒刷新頁面的次數大于1則會彈出以下頁面（表示限流），否則正常

線程數+直接控制

而直接控制的線程數設置為1表示如果超過一個頁面訪問此連接那就會限流否則正常。這里就不再對線程數做測試了

QPS+Warming up

Warm Up（RuleConstant.CONTROL_BEHAVIOR_WARM_UP）方式，即預熱/冷啟動方式。當系統流量長期處于低水位的情況下，當流量突然增加時，直接把系統拉升到高水位可能瞬間把系統壓垮。通過"冷啟動"，讓通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，給冷系統一個預熱的時間，避免冷系統被壓垮。

舉例：當預熱時長=8，QPS單機閾值=3

• 當并發(fā)請求到達的時候，實際的單機閾值是：QPS單機閾值配置 / coldFactoer= 3 / 3 =1,也就是每秒鐘只能一個請求訪問成功。
• 預熱時長為8秒，實際的單機閾值在8秒鐘內逐步由1 -> 2 -> 3,最終等于QPS單機閾值配置。
• 這里有一個注意點是QPS單機閾值一定要大于或等于3否則會一直請求不成功

QPS+排隊等待

排隊等待方式會嚴格的控制請求通過的間隔時間，就是讓請求勻速的通過，對應的是漏桶算法。

言簡意賅：QPS對應每秒處理的線程為1，超時時間表示超過10s則不接受其他線程的請求。也就是說將超時時間(ms) / 單機閾值(s/個) = 線程通過數。

關聯

使用了testA關聯testB那么當二者其一越界了即二者其一或者觸犯了閾值規(guī)則，那么規(guī)則的時長內即QPS內testA是無法訪問的，換句通俗易懂的就是：其中一個犯錯，testA就得扛鍋。但要注意的是不是永久失效，只是閾值內失效。

鏈路

與關聯相反。兩者之一犯錯，那么就是入口資源背鍋。

關聯與鏈路的區(qū)別

關聯：

配置: “查詢訂單” 關聯 “下單” 接口, 當"下單"到達閾值, 限流"查詢訂單"接口

鏈路：

配置: “查詢訂單”為入口時, 當"查詢訂單"到達閾值時, 限流"查詢訂單"

到此這篇關于Sentinel流控規(guī)則實現限流保護流程詳解的文章就介紹到這了,更多相關Sentinel流控規(guī)則內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論