Snetinel服務限流及熔斷的一些基本知識
Snetinel服務限流及熔斷的一些基本知識
服務限流:通過限制併發訪問資料或者限制一段時間內(時間視窗內)允許處理的請求數量來保護系統,不會出現崩潰(或者一些其他的業務關係)。表現的形式是:犧牲一部分使用者的可用性來維持系統的穩定性
常用的限流演算法
-
計算器演算法:指定的週期內累加訪問次數,當訪問次數達到設定的閾值時,觸發限流策略(返回一個預設的結果,或者拒絕服務),進入下一個週期,累加次數清除。
可以用於簡訊服務(或者一些免費服務)的次數上進行限制,比如每個使用者在同一分鐘內只能觸發一定數量的簡訊服務
這種演算法存在臨界問題,再上一個週期(0:58)和下一個週期(1:02)期間每個週期都觸發了100個請求,整體看就是4秒內有200請求,超過了設定閾值 -
滑動 視窗演算法 (為了解決計算器演算法帶來的臨界問題):一種流量控制技術,Tcp網路通訊協議中就是採用這個演算法解決網路擁堵的情況。在固定視窗(或者說週期內)中分割出多個小時間視窗,在每個時間視窗中記錄訪問的次數,滑動視窗(一定數量的小時間視窗)在小時間視窗上滑動並刪除過期的小時間視窗,最後只統計落在滑動視窗上的所有小時間視窗的總訪問次數,對訪問的請求進行限制。
像上個問題,可以將一分鐘分成4個小時間視窗,滑動視窗大小為2,在滑動視窗內只能處理50個請求。Sentinel 內部就是使用滑動視窗演算法來實現限流的。 -
令牌桶限流演算法: 網路流量和速率限制常用的一種演算法。對於每一個訪問請求,都需要從令牌桶(以一定的速率生成令牌,桶的大小可以有一個上限)中獲得一個令牌,如果沒有獲得請求就觸發限流策略。令牌桶生成令牌的效率可以根據實際的需求來。只要生成令牌的效率是恆定的,短時間內突發大量的訪問請求,對於新增的訪問請求,系統能夠正常處理。
- 請求速度大於令牌生成速度,那麼令牌會很快會被取完,後續再進來的訪問請求會被限流
- 請求速度等於令牌生成速度,處於平衡
- 請求速度等於令牌生成速度,此時系統的併發數不高,訪問請求正常處理
-
漏桶限流演算法:控制訪問請求注入的速度,平滑的處理網路上的突發請求。維護一個漏桶容器A(有大小),用於儲存訪問請求,容器以恆定的速度派發訪問的請求,漏桶容器A 流出的訪問請求的速度始終保持不變。
- 請求速度大於漏桶容器A的派發速度:訪問請求書超出當前系統處理的極限,將會觸發限流策略
- 請求速度小於等於漏桶容器A的派發速度,系統處理能力滿足客戶端需求,正常執行
漏桶演算法和令牌桶演算法的實現原理相差不大,區別漏桶演算法無法處理短時間內的突發訪問請求,漏桶限流演算法是一種速度恆定的限流演算法
服務熔斷:背景—微服務架構中,由於業務拆分的問題,一般會出現請求鏈路較長的情況,使用者發起一個訪問請求,往往需要幾個微服務才能夠完成,在高併發的場景下,這種依賴的服務(請求呼叫鏈)對系統的穩定性影響很大,只要其中某個服務的環節出現網路延遲或者請求超時等意外狀況而導致服務不可用,就會造成當前請求的阻塞,從而可能出現雪崩的效應。服務熔斷就是用於解決這種情況的,一旦某個服務提供者無法正常提供服務的時候,為了防止雪崩效應的產生,就會將當前介面和外部隔離,觸發熔斷,後續一段時間內,呼叫者的請求都會直接失敗返回,知道服務提供者恢復正常。服務熔斷之後,可以提供一個預設的處理結果。
服務降級:伺服器壓力劇增的情況下,根據實際業務情況及流量,對一些服務和頁面有策略的不處理或換種簡單的方式處理,從而釋放伺服器資源以保證核心業務正常運作或高效運作。參考的指標:
1. 平均響應時間:比如1s內5個請求,對應時刻的平均響應時間超過閾值,則在接下來固定時間視窗內,對應的方法自動熔斷
2. 異常比例:某個方法每秒呼叫所獲得異常總數比例超過設定的閾值,該方法自動進入降級狀態,在固定的時間視窗內對這個方法的呼叫會自動返回
3. 異常數量:與異常比例類似,某個方法在時間視窗內獲得異常數超過閾值時觸發
服務熔斷和服務降級的區別:熔斷由服務不可用引起,降級由業務實際情況和系統資源負載設定等關係引起,但最終的表現是類似的 框架中用DegradeRule 設定
QPS(Queries per second):每秒查詢數
QPS 超過閾值觸發流量控制行為,通過controlBehavior 設定,包含:
- 直接拒絕(RuleConstant.CONTROL_BEHAVIOR_DEFAULT):預設,請求流量超出預設,直接丟擲FlowException
- Warm Up (RuleConstant.CONTROL_BEHAVIOR_WARM_UP):冷啟動(預熱):當流量突然增大,即從空閒突然到繁忙,可能瞬間將系統壓垮,希望控制請求處理數量逐漸增大,並在預期時間內達到最大(個人感覺箱數令牌桶演算法)
- 勻速排隊(RuleConstant.CONTROL_BEHAVIOR_RATE_LIMIT):嚴格控制請求的通過時間間隔,即請求以勻速通過限制被處理(漏桶限流)
- 冷啟動(預熱)+ 勻速排隊RuleConstant.CONTROL_BEHAVIOR_WARM_UP_RATE_LIMIT)
相關文章
- 微服務架構 | 5.2 基於 Sentinel 的服務限流及熔斷微服務架構
- Envoy熔斷限流實踐(二)Rainbond基於RLS服務全侷限流AI
- 微服務熔斷限流Hystrix之Dashboard微服務
- 微服務熔斷限流Hystrix之流聚合微服務
- 微服務元件之限流器與熔斷器微服務元件
- Sentinel限流熔斷降級
- springcloud3(六) 服務降級限流熔斷元件Resilience4jSpringGCCloud元件
- .Net Core微服務——Ocelot(3):超時、熔斷、限流微服務
- go-kit微服務:服務熔斷Go微服務
- 服務的熔斷和降級的區別
- Envoy熔斷限流實踐(一)基於Rainbond外掛實現熔斷AI
- JQuery的一些基本知識jQuery
- SpringCloud-Hystrix 服務降級、熔斷SpringGCCloud
- 五. SpringCloud服務降級與熔斷SpringGCCloud
- 12.SpringCloudAlibabaSentinel實現熔斷和限流SpringGCCloud
- Spring Cloud Alibaba:Sentinel實現熔斷與限流SpringCloud
- 面試官:說說降級、熔斷、限流面試
- 一個故事理解限流熔斷降級
- SpringCloud Netflix (五) : Hystrix 服務熔斷和服務降級SpringGCCloud
- 服務限流原理及演算法演算法
- 使用springcloud gateway搭建閘道器(分流,限流,熔斷)SpringGCCloudGateway
- Sentinel入門到實操 (限流熔斷降級)
- 利用Spring Boot實現微服務的API閘道器統一限流與熔斷Spring Boot微服務API
- 服務限流
- 限流、熔斷、高可用?有些人一臉懵bi
- 微服務熔斷隔離機制及注意事項微服務
- 資料庫的一些基本知識部落格資料庫
- 總結關於CPU的一些基本知識
- SpringCloud 2020.0.4 系列之服務降級的其他用法與熔斷SpringGCCloud
- 聊聊自定義SPI如何與sentinel整合實現熔斷限流
- 微服務SpringCloud之熔斷器微服務SpringGCCloud
- Java後端分散式系統的服務降級:優雅降級與服務熔斷Java後端分散式
- 分散式服務防雪崩熔斷器,Hystrix理論+實戰。分散式
- 重新整理 .net core 實踐篇————熔斷與限流[三十五]
- 微服務技術棧:流量整形演算法,服務熔斷與降級微服務演算法
- 影像的基本知識
- asp.net core + Ocelot 實現負載均衡、熔斷、認證、限流ASP.NET負載
- .NET Core 微服務之Polly熔斷策略微服務