轉載自??系統自適應限流

Sentinel 系統自適應限流從整體維度對應用入口流量進行控制，結合應用的 Load、CPU 使用率、總體平均 RT、入口 QPS 和并發線程數等幾個維度的監控指標，通過自適應的流控策略，讓系統的入口流量和系統的負載達到一個平衡，讓系統盡可能跑在最大吞吐量的同時保證系統整體的穩定性。

背景

在開始之前，我們先了解一下系統保護的目的：

• 保證系統不被拖垮
• 在系統穩定的前提下，保持系統的吞吐量

長期以來，系統保護的思路是根據硬指標，即系統的負載 (load1) 來做系統過載保護。當系統負載高于某個閾值，就禁止或者減少流量的進入；當 load 開始好轉，則恢復流量的進入。這個思路給我們帶來了不可避免的兩個問題：

• load 是一個“結果”，如果根據 load 的情況來調節流量的通過率，那么就始終有延遲性。也就意味著通過率的任何調整，都會過一段時間才能看到效果。當前通過率是使 load 惡化的一個動作，那么也至少要過 1 秒之后才能觀測到；同理，如果當前通過率調整是讓 load 好轉的一個動作，也需要 1 秒之后才能繼續調整，這樣就浪費了系統的處理能力。所以我們看到的曲線，總是會有抖動。
• 恢復慢。想象一下這樣的一個場景（真實），出現了這樣一個問題，下游應用不可靠，導致應用 RT 很高，從而 load 到了一個很高的點。過了一段時間之后下游應用恢復了，應用 RT 也相應減少。這個時候，其實應該大幅度增大流量的通過率；但是由于這個時候 load 仍然很高，通過率的恢復仍然不高。

TCP BBR?的思想給了我們一個很大的啟發。我們應該根據系統能夠處理的請求，和允許進來的請求，來做平衡，而不是根據一個間接的指標（系統 load）來做限流。最終我們追求的目標是?在系統不被拖垮的情況下，提高系統的吞吐率，而不是 load 一定要到低于某個閾值。如果我們還是按照固有的思維，超過特定的 load 就禁止流量進入，系統 load 恢復就放開流量，這樣做的結果是無論我們怎么調參數，調比例，都是按照果來調節因，都無法取得良好的效果。

Sentinel 在系統自適應保護的做法是，用 load1 作為啟動自適應保護的因子，而允許通過的流量由處理請求的能力，即請求的響應時間以及當前系統正在處理的請求速率來決定。

系統規則

系統保護規則是從應用級別的入口流量進行控制，從單臺機器的 load、CPU 使用率、平均 RT、入口 QPS 和并發線程數等幾個維度監控應用指標，讓系統盡可能跑在最大吞吐量的同時保證系統整體的穩定性。

系統保護規則是應用整體維度的，而不是資源維度的，并且僅對入口流量生效。入口流量指的是進入應用的流量（EntryType.IN），比如 Web 服務或 Dubbo 服務端接收的請求，都屬于入口流量。

系統規則支持以下的模式：

• Load 自適應（僅對 Linux/Unix-like 機器生效）：系統的 load1 作為啟發指標，進行自適應系統保護。當系統 load1 超過設定的啟發值，且系統當前的并發線程數超過估算的系統容量時才會觸發系統保護（BBR 階段）。系統容量由系統的?maxQps * minRt?估算得出。設定參考值一般是?CPU cores * 2.5。
• CPU usage（1.5.0+ 版本）：當系統 CPU 使用率超過閾值即觸發系統保護（取值范圍 0.0-1.0），比較靈敏。
• 平均 RT：當單臺機器上所有入口流量的平均 RT 達到閾值即觸發系統保護，單位是毫秒。
• 并發線程數：當單臺機器上所有入口流量的并發線程數達到閾值即觸發系統保護。
• 入口 QPS：當單臺機器上所有入口流量的 QPS 達到閾值即觸發系統保護。

原理

先用經典圖來鎮樓:

我們把系統處理請求的過程想象為一個水管，到來的請求是往這個水管灌水，當系統處理順暢的時候，請求不需要排隊，直接從水管中穿過，這個請求的RT是最短的；反之，當請求堆積的時候，那么處理請求的時間則會變為：排隊時間 + 最短處理時間。

• 推論一: 如果我們能夠保證水管里的水量，能夠讓水順暢的流動，則不會增加排隊的請求；也就是說，這個時候的系統負載不會進一步惡化。

我們用 T 來表示(水管內部的水量)，用RT來表示請求的處理時間，用P來表示進來的請求數，那么一個請求從進入水管道到從水管出來，這個水管會存在?P * RT　個請求。換一句話來說，當?T ≈ QPS * Avg(RT)?的時候，我們可以認為系統的處理能力和允許進入的請求個數達到了平衡，系統的負載不會進一步惡化。

接下來的問題是，水管的水位是可以達到了一個平衡點，但是這個平衡點只能保證水管的水位不再繼續增高，但是還面臨一個問題，就是在達到平衡點之前，這個水管里已經堆積了多少水。如果之前水管的水已經在一個量級了，那么這個時候系統允許通過的水量可能只能緩慢通過，RT會大，之前堆積在水管里的水會滯留；反之，如果之前的水管水位偏低，那么又會浪費了系統的處理能力。

• 推論二:　當保持入口的流量是水管出來的流量的最大的值的時候，可以最大利用水管的處理能力。

然而，和 TCP BBR 的不一樣的地方在于，還需要用一個系統負載的值（load1）來激發這套機制啟動。

注：這種系統自適應算法對于低 load 的請求，它的效果是一個“兜底”的角色。對于不是應用本身造成的 load 高的情況（如其它進程導致的不穩定的情況），效果不明顯。

示例

我們提供了系統自適應限流的示例：SystemGuardDemo。

總結

以上是生活随笔為你收集整理的Sentinel（十）之系统自适应限流的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。