前言

我為什么寫這篇文章，是因為Sentinel實在是太強大太好用了，再加上阿里開源，Sentinel的發展迅猛。已有多家公司生產使用，但但凡神功，一個不慎，就有可能走火入魔，輕則離職走人，重則走火入魔踏上跑路生涯。本文本著你對官方秘籍已經通篇閱讀無一不懂的前提，來此避坑，如無上述經歷，請即刻返程回讀。

限流篇

為什么要使用Sentinel？

我們為什么要搞限流，限流的作用是什么在此不做贅述，但是在做限流前我們需要思考一個問題，為什么要用Sentinel，達到什么樣的流量需要采用限流，什么樣的應用適合Sentinel。

新的中間件的應用，尤其是這種作用在應用層的我們一定要考慮的一個問題就是能效的提升會是多少，這種提升的正面例子就是你的應用的穩定性，負面例子自然是所帶來的額外開銷，響應時間，維護成本等。

很欣慰的是Sentinel本身的設計還是很OK的，性能上的影響微乎其微，具體請參加官方wiki。

Sentinel的很多設計很多算法都是源于Guava，感興趣的同學可以試著去了解一下。

令牌桶，漏桶算法，是限流界的經典理論支柱，無論是Hystrix還是Sentinel都是在其基礎上做的變化，所謂一法通，萬法通，便是其理。

一般來講，當你的應用沒有復雜到一定程度的時候，我并不建議你入坑，假如你只是想吃米飯，但是來了一大堆食物，于你而言就是食之無味，棄之可惜。（此處對于其他中間件一樣適用）如果限流是必要的，但是應用并沒有龐大到一定地步，那么我建議你單獨使用限流，利用已有的比如RateLimit來實現你的限流，（比如京東的部分應用是采用該方式來進行的）。一般來講，底層應用只需要限流就OK了，如果說你的應用限流這快業務需求需要更靈活的，比如預熱，或者基于調用關系等更復雜更多樣的，那么沒錯，sentinel就是你的最佳選擇。

單機限流VS集群限流

如果你的應用屬于分布式應用，那么我并不推薦你使用單機限流，單機限流可以作為備選方案，而我們優先考慮的一定是集群限流，雖然集群限流的引入會導致你的應用復雜度又上升了一個級別。

我們需要明白一點，你的單機流量是你負載均衡的一個選擇結果，而你的負載均衡并不一定能夠保證流量按照你設定的理想狀態（這是負載均衡的作用，所以我們沒辦法破壞，負載均衡不同的策略導致不同的流量分配結果，受多方面影響，我司這邊采用的是最小活躍數。最小活躍數的選擇與系統的整個負載有關，某一個接口占用過多資源，亦會導致其他接口出現連鎖反應，所以流量波動較大），所以很有可能出現某臺機器流量超標，某臺機器流量相對較少，比如10000個請求，負載均衡的選擇結果，A接受了6000個，B接受了4000個，而AB的單機限流均為5000，那么理想狀態下這10000個請求會被全部接受，但實際情況是只接受了9000，那么采用集群限流則不會出現這樣的情況。

降級熔斷篇

降級熔斷也是Sentinel的一個很優秀的功能，用處不做贅述。

熔斷這塊Sentinel提供了三種方式，平均響應時間，平均失敗率，異常數目。統計方式這塊是用滑動窗口來設計的。達到熔斷條件，Sleep。目前最新的版本支持自定義統計窗口。 此處的話時間窗口會有個默認值，5，即單位窗口內，達到熔斷條件的時候并不會立即熔斷，而是處于熔斷就緒的狀態，具體熔斷與否取決于這五個請求，詳細自行觀看源碼。

再次說個題外話，我們需要明白一點，一旦采用平均值或者什么率這塊我們就需要明白一點，容易發生平均值效應。假設我們采用了平均響應時間，你前一百次的平均值都為100，但是后面系統出現問題，相應時間這塊為100000，但是sentinel這塊的話記作5000（注：基于RT的話當系統相應時間超過5000時會直接認為超時記錄為5000），平均值下來亦然達不到熔斷條件。也就是說當你的系統已經處于不正常的狀態的時候并不能第一時間進行降級。

基于異常比例亦然，只是說當你的流量數過多的時候才會呈現出較好的表現。假設你前6個流量都是異常（可能是預熱或其他并非不正常的行為導致的異常），那么系統會直接進入降級。過早地夭折。

平均值受最大值影響，比率受初始分子分母的影響。 基于此 ，希望各位選用自己合適的方式來講行熔斷選擇。

尾篇 熔斷設計思考題外話

Hystrix這塊當進行熔斷時，會清空統計數據，也就是說，熔斷關閉后，系統會認為是一個全新的統計開始，之前的數據都會被剔除，Sentinel這塊的設計由于要考慮整個系統的數據的準確性（數據源會被多方使用），并未做數據剔除，也就是說，如果熔斷時間過短，當熔斷關閉后仍位于同一個時間窗口的時候，此時會再次進入熔斷開啟狀態（因為統計數據的采集仍是沿用熔斷前的統計數據）。解決的話目前我所建議的方式是熔斷這塊的數據統計單獨記錄，（不能影響其他數據的準確性）這個也是Sentinel的官方維護者樂有的建議。

熔斷這塊沒有一個熔斷半開的狀態，有時候我們的系統確實被搞垮了，熔斷時間過后，仍然沒有恢復正常，這個時候我們最好的做法是放一個流量過去，而不是大多數流量，這個流量的成功與否決定著我們的系統是否恢復到熔斷關閉的狀態。

限流熔斷可以考慮是否引入其他因素來進行衡量，比如系統的負載等等。另外一點，當達到熔斷的時候我們是應該直接熔斷還是說進行一個流量的限制，是進行平緩的降級還是說粗暴的降級。

主動降級：

熔斷與降級結果是一樣的，但是目的不一樣，一個屬于主動，一個屬于被動。被熔斷后采用備用方案屬于業務方的補償機制。這個不能稱之為降級，降級應該是說當我有預感會有較大的流量的還好，我的負載比較高，那么我會梳理依賴關系，關閉一些次要服務，讓出資源來給核心服務用。而且Sentinel這里的話也完全可以把降級給做出來，用戶可以主動的在控制臺做降級操作，自定義時間窗口大小。比如說大促期間，會關閉一些非核心的業務，這塊盡可能把資源讓給核心業務。

目前Sentinel尚有許多需要修改更正的，大家可以踴躍參與。

尾篇：限流熔斷思考

限流

負載均衡保證了保證集群勞作下的均衡分工，不會出現累得累死，閑的閑死的情況，集群容錯則保證了當我們部分機器比如A犯錯回家反思的情況下其他機器可以迅速完成指派給A的任務，而不至于讓業務方成為下一個望夫石，至于限流，則是我們廣大勞動人民一直追求的朝九晚六不加班，他保證了我們的機器不會超負荷工作導致宕機。 許多剛入職場的同學不明白為什么要限流，限流后部分用戶不是提供不了服務了嘛？這個問題很簡單，人心不足蛇吞象，如是也。

熔斷

底層服務出現問題時：錯誤數過多/平均響應時間變長，上層應用怎么做？底層應用又該怎么做。 底層應用限流是必須的。熔斷的具體情況需要具體分析， 代碼錯誤導致系統資源應用不合理，比如特殊情況大對象的使用，數據庫出現慢查詢、索引未命中。這些情況出現導致系統的正常負載出現問題。限流可能已經解決不了問題了。

另外熔斷的話這里最好業務方這里做一下相關處理。核心業務，業務方應當做好熔斷/降級之后的一個備用方案。

禁用服務

禁用 --> 導致的問題不一樣，還是業務owner最清楚，根據不同的問題，處理手段也不一樣。 非核心業務如果影響面可控也是可以采用直接下線服務的方式，這樣做的好處是不會再讓業務方苦苦等待，浪費有限的資源去等一個沒有結果的響應。

擴容

擴容 --> 要速度，需要自身運維系統支持，能暫時解決問題。 擴容的主要依據，系統資源利用率飆升，內存使用爆表，頻繁GC。導致原因可能是流量過高，或者代碼不當這個時候應用服務器擴容可以暫時解決問題。注：頻繁fullGc也可以進行優化，如果代碼正確的情況下，這個時候就需要做jvm參數優化了 慢sql-> 數據庫服務器。應用sql語句優化、復雜表查詢改寬表。加緩存等等。

放任

放任不管（等修復） --> 影響范圍能接受（禁用可能會有額外的風險情況）

總結

以上是生活随笔為你收集整理的sentinel 时间窗口_Sentinel潜龙勿用篇的全部內容，希望文章能夠幫你解決所遇到的問題。

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