這個節點是sentinel流控介面，主要承擔的作用是限流和預熱，還是老套路，在介紹原始碼之前先介紹一下原始碼中用到的幾個核心原理，這樣大家看原始碼相對輕松一些，
1、核心演算法
1.1 漏洞演算法和令牌通演算法
漏桶可以看作是一個帶有常量服務時間的單服務器佇列，如果漏桶（包快取）溢位，那么資料包會被丟棄， 在網路中，漏桶演算法可以控制埠的流量輸出速率，平滑網路上的突發流量，實作流量整形，從而為網路提供一個穩定的流量，
如圖所示，把請求比作是水，水來了都先放進桶里，并以限定的速度出水，當水來得過猛而出水不夠快時就會導致水直接溢位，即拒絕服務，
1.2令牌桶演算法
令牌桶演算法的原理是系統會以一個恒定的速度往桶里放入令牌，而如果請求需要被處理，則需要先從桶里獲取一個令牌，當桶里沒有令牌可取時，則拒絕服務，從原理上看，令牌桶演算法和漏桶演算法是相反的，一個“進水”，一個是“漏水”，
1.3預熱桶演算法
系統在初始化或者長時間處于低利用率下，系統由于所依萊澩的限制，并不能立馬達到它正常的服務水平；例如系統依賴的快取過期導致新的請求會直接請求 db，再比如很多系統使用了連接池，長時間的 idle 情況下連接池只會保持少量的連接，新的請求會重新創建連接，這些都是耗時操作，完成這些操作之后，系統才能到達正常的服務水平，這時候變需要預熱桶演算法， 預熱桶演算法本質是按照一個 y=mx+b的一個線性函式，將投入令牌桶的時間間隔又大到小的程序，下面是guava原始碼中的一個函式圖，throttling
|
cold + | /
interval | | /.
| | / .
| |/ .
| + . ← "f(storedPermits)"
| /| .
| / | .
| / | .
stable +----------/ | . ← "warmup period"
interval | . | . is the area of the trapezoid between thresholdPermits and maxPermits
| . | .
| . | .
0 +----------+---|---+--------------→ storedPermits
0 thresholdPermits maxPermits我們可以定義一個冷卻因子(coldFactor) ，令系統處于最冷的狀態下獲取一個令牌的時長 coldInterval = stableInterval * coldFactor ；「預熱桶」從最冷狀態到完成預熱進入穩定期有個轉折點，到達這個轉折點時的令牌數量我們用 thresholdPermits 表示；這樣，我們就獲得了一個獲取(一個)令牌的時長隨著令牌數量變化的連續函式 f(storedPermits) ：
1） 0 <= storedPermits <= thresholdPermits 時；f(storedPermits) = stableInterval; // 常數函式，函式值始終為 stableInterval ;
2） thresholdPermits <= storedPermits <= maxPermits 時，f(storedPermits) = (coldInterval - stableInterval) * storedPermits / (maxPermits -thresholdPermits); // 正比例函式，比例常數為 (coldInterval - stableInterval) / (maxPermits - thresholdPermits) ;
在上面這張圖中，我們畫一條與 x 軸垂直的線 n，這條線與函式曲線的交點的縱坐標當前 storedPermits 數量下獲取單個令牌所需的時間；
當我們從右向左移動 n 時，表示系統接收到請求，令牌正在被消耗，假設系統連續接收到 k 個請求，獲取對應令牌所需要的時間為：t = f(maxPermits) + f(maxPermits - 1) + f(maxPermits - 2) + ... + f(maxPermits - k)，通過微積分的知識可以看出來這是在求函式 f 在 maxPermits - k 到 maxPermits 區間的定積分，可以用這個區間的函式圖形的面積表示，也就是說圖中梯形的面積為我們的預熱時間，圖中矩形的面積為預熱時間的一半，網上及guava原始碼出的解釋：英文冷卻因子是3，然后code inteval 到 stable inteval的值是stable inteval到0值的2倍所以預熱面積也是2倍的關系，具體情況如下圖：
ps:個人理解這里的解釋欠妥，如下圖如果①和②是二倍的關系還可以理解，這是個人理解歡迎大家給出合理解釋，
2、FLOW SLOT原始碼解讀
流控節點整體流程是：先驗證流量是否超過閥值，沒有的情況下載進入下一個節點，
集群限流在sentinel這個組件中個人不推薦，雖然集權能解決如下問題：
- 假設集群中有 10 臺機器，我們給每臺機器設定單機限流閾值為 10 qps，理想情況下整個集群的限流閾值就為 100 qps，不過實際情況下路由到每臺機器的流量可能會不均勻，會導致總量沒有到的情況下某些機器就開始限流，
- 每臺單機實體只關心自己的閾值，對于整個系統的全域閾值大家都漠不關心，當我們希望為某個 api 設定一個總的 qps 時(就跟為 api 設定總的呼叫次數一樣)，那這種單機模式的限流就無法滿足條件了，
四個子類對應四種限流場景：快速失敗，預熱，排隊等待，
2.1直接限流快速失敗場景
當前請求數量加上滑動時間視窗統計的前一秒的請求數量大于設定閥值直接失敗，
2.2直接限流快速預熱場景
初始化場景就不說了類似前面的預熱桶的計算方式，最終計算一個函式，穩定的減少往桶里方每個token的時間，最終達到穩定PQS，
校驗是否通過
產生令牌
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/228934.html
標籤：其他
上一篇：sentinel--核心原理篇
下一篇：面向物件基本概念2-核心