流量控制理论与Sentinel
sentinel官方文檔：https://sentinelguard.io/zh-cn/docs/introduction.html
流量控制理論策略：
漏桶算法：
適用：漏桶策略適用于間隔性突發流量且流量不用即時處理的場景
代表框架：Sentinel 中的勻速排隊限流策略，分布式追蹤系統 Jaeger 中采集策略為速率限制類型。
有一個固定容量的水桶，桶底有一個小洞，水桶可以接收任意速率的水流，但無論水桶里有多少水，水從小洞流出的速率始終不變，桶里的水滿了之后，水就會溢出。
優點：平滑流量，做到了流量整形，即無論流量多大，即便是突發的大流量，輸出依舊是一個穩定的流量。
缺點：對于突發流量的情況，因為服務器處理速度與正常流量的處理速度一致，會丟棄比較多的請求。
令牌桶算法：
適用：有突發特性的流量，且流量需要即時處理的場景。
代表框架：Guava 提供的限流工具類 RateLimiter。
有一個固定容量的存放令牌的桶，我們以固定速率向桶里放入令牌，桶滿時會丟棄多出的令牌。每當請求到來時，必須先到桶里取一個令牌才可被服務器處理，也就是說只有拿到了令牌的請求才會被服務器處理。所以，你可以將令牌理解為門卡，只有拿到了門卡才能順利進入房間。
文章參考：https://cloud.tencent.com/developer/article/1663918
服務降級與熔斷
服務降級：一般是指在服務器壓力劇增的時候，根據實際業務使用情況以及流量，對一些服務和頁面有策略的不處理或者用一種簡單的方式進行處理，從而釋放服務器資源的資源以保證核心業務的正常高效運行，提供的是不完全的服務。
例如：在雙十一期間，壓力特別大時，電商平臺完成訂單期間原本頁面上展示關聯商品推薦不再展示。
服務熔斷：應對雪崩效應的鏈路自我保護機制。當某服務出現不可用或響應超時的情況時，為了防止該鏈路的其他服務和整個系統出現雪崩，暫時停止對該服務的調用。
sentinel
參考資料：http://c.biancheng.net/springcloud/sentinel.html
sentinel 基于以下屬性組合進行流量控制。
| 資源名 | 流控規則的作用對象。 | - |
| 閾值 | 流控的閾值。 | - |
| 閾值類型 | 流控閾值的類型，包括 QPS 或并發線程數。 | QPS |
| 針對來源 | 流控針對的調用來源。 | default，表示不區分調用來源 |
| 流控模式 | 調用關系限流策略，包括直接、鏈路和關聯。 | 直接 |
| 流控效果 | 流控效果（直接拒絕、Warm Up、勻速排隊），不支持按調用關系限流。 | 直接拒絕 |
QPS ：表示并發請求數，即每秒鐘最多通過的請求數。
Sentinel 提供了 3 種熔斷策略，如下表所示。
| 慢調用比例 (SLOW_REQUEST_RATIO） | 選擇以慢調用比例作為閾值，需要設置允許的慢調用 RT（即最大響應時間），若請求的響應時間大于該值則統計為慢調用。 當單位統計時長（statIntervalMs）內請求數目大于設置的最小請求數目，且慢調用的比例大于閾值，則接下來的熔斷時長內請求會自動被熔斷。 經過熔斷時長后熔斷器會進入探測恢復狀態（HALF-OPEN 狀態），若接下來的一個請求響應時間小于設置的慢調用 RT 則結束熔斷，若大于設置的慢調用 RT 則再次被熔斷。 |
| 異常比例 (ERROR_RATIO) | 當單位統計時長（statIntervalMs）內請求數目大于設置的最小請求數目且異常的比例大于閾值，則在接下來的熔斷時長內請求會自動被熔斷。 經過熔斷時長后熔斷器會進入探測恢復狀態（HALF-OPEN 狀態），若接下來的一個請求成功完成（沒有錯誤）則結束熔斷，否則會再次被熔斷。異常比率的閾值范圍是 [0.0, 1.0]，代表 0% - 100%。 |
| 異常數 (ERROR_COUNT) | 當單位統計時長內的異常數目超過閾值之后會自動進行熔斷。 經過熔斷時長后熔斷器會進入探測恢復狀態（HALF-OPEN 狀態），若接下來的一個請求成功完成（沒有錯誤）則結束熔斷，否則會再次被熔斷。 |
官方文檔上提供了另一大類的流量控制：
基于調用關系的流量控制：
根據調用方限流
ContextUtil.enter(resourceName, origin) 方法中的 origin 參數標明了調用方身份。這些信息會在 ClusterBuilderSlot 中被統計。可通過以下命令來展示不同的調用方對同一個資源的調用數據：
調用數據示例：
id: nodeA idx origin threadNum passedQps blockedQps totalQps aRt 1m-passed 1m-blocked 1m-total 1 caller1 0 0 0 0 0 0 0 0 2 caller2 0 0 0 0 0 0 0 0上面這個命令展示了資源名為 nodeA 的資源被兩個不同的調用方調用的統計。
限流規則中的 limitApp 字段用于根據調用方進行流量控制。該字段的值有以下三種選項，分別對應不同的場景：
-
default：表示不區分調用者，來自任何調用者的請求都將進行限流統計。如果這個資源名的調用總和超過了這條規則定義的閾值，則觸發限流。
-
{some_origin_name}：表示針對特定的調用者，只有來自這個調用者的請求才會進行流量控制。例如 NodeA 配置了一條針對調用者caller1的規則，那么當且僅當來自 caller1 對 NodeA 的請求才會觸發流量控制。
-
other：表示針對除 {some_origin_name} 以外的其余調用方的流量進行流量控制。例如，資源NodeA配置了一條針對調用者 caller1 的限流規則，同時又配置了一條調用者為 other 的規則，那么任意來自非 caller1 對 NodeA 的調用，都不能超過 other 這條規則定義的閾值。
同一個資源名可以配置多條規則，規則的生效順序為：
{some_origin_name} > other > default
根據調用鏈路入口限流：鏈路限流
NodeSelectorSlot 中記錄了資源之間的調用鏈路，這些資源通過調用關系，相互之間構成一棵調用樹。這棵樹的根節點是一個名字為 machine-root 的虛擬節點，調用鏈的入口都是這個虛節點的子節點。
一棵典型的調用樹如下圖所示：
machine-root/ \/ \Entrance1 Entrance2/ \/ \DefaultNode(nodeA) DefaultNode(nodeA)上圖中來自入口 Entrance1 和 Entrance2 的請求都調用到了資源 NodeA，Sentinel 允許只根據某個入口的統計信息對資源限流。比如我們可以設置 FlowRule.strategy 為 RuleConstant.CHAIN，同時設置 FlowRule.ref_identity 為 Entrance1 來表示只有從入口 Entrance1 的調用才會記錄到 NodeA 的限流統計當中，而對來自 Entrance2 的調用漠不關心。
調用鏈的入口是通過 API 方法 ContextUtil.enter(name) 定義的。
具有關系的資源流量控制：關聯流量控制
當兩個資源之間具有資源爭搶或者依賴關系的時候，這兩個資源便具有了關聯。比如對數據庫同一個字段的讀操作和寫操作存在爭搶，讀的速度過高會影響寫得速度，寫的速度過高會影響讀的速度。如果放任讀寫操作爭搶資源，則爭搶本身帶來的開銷會降低整體的吞吐量。可使用關聯限流來避免具有關聯關系的資源之間過度的爭搶，舉例來說，read_db 和 write_db 這兩個資源分別代表數據庫讀寫，我們可以給 read_db 設置限流規則來達到寫優先的目的：設置 FlowRule.strategy 為 RuleConstant.RELATE 同時設置 FlowRule.ref_identity 為 write_db。這樣當寫庫操作過于頻繁時，讀數據的請求會被限流。
總結
以上是生活随笔為你收集整理的流量控制理论与Sentinel的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Linux下Mysql5.5的Cmake
- 下一篇： 记住这36条创业军规