深刻淺出Hystrix-隔離策略

Hystrix隔離模式目前有兩種方式：信號量模式和線程池模式。

但信號量並不支持超時，當被調服務發生問題時，有少部分用戶會長時間沒法獲得響應。

另外，使用線程池模式沒法傳遞Header，我估計是因爲線程切換，參數傳遞過程當中被去掉了。

1、信號量和線程池

	是否有線程切換	是否支持異步	是否支持超時	是否支持熔斷	開銷大小	是否支持限流
信號量	否	否	否	是	小	是
線程池	是	是	是	是	大	是

 

2、信號量隔離

信號量的使用示意圖以下圖所示，當n個併發請求去調用一個目標服務接口時，都要獲取一個信號量才能真正去調用目標服務接口，但信號量有限，默認是10個，能夠使用maxConcurrentRequests參數配置，若是併發請求數多於信號量個數，就有線程須要進入隊列排隊，但排隊隊列也有上限，默認是 5，若是排隊隊列也滿，則一定有請求線程會走fallback流程，從而達到限流和防止雪崩的目的。

信號量模式從始至終都只有請求線程自身，是同步調用模式，不支持超時調用，不支持直接熔斷，因爲沒有線程的切換，開銷很是小。

 

3、線程池隔離

線程池的使用示意圖以下圖所示，當n個請求線程併發對某個接口請求調用時，會先從hystrix管理的線程池裏面得到一個線程，而後將參數傳遞給這個線程去執行真正調用。線程池的大小有限，默認是10個線程，能夠使用maxConcurrentRequests參數配置，若是併發請求數多於線程池線程個數，就有線程須要進入隊列排隊，但排隊隊列也有上限，默認是 5，若是排隊隊列也滿，則一定有請求線程會走fallback流程。

線程池模式能夠支持異步調用，支持超時調用，支持直接熔斷，存在線程切換，開銷大。

 

優勢： 
    一、 使用線程池隔離能夠徹底隔離第三方應用，請求線程能夠快速放回。

    二、 請求線程能夠繼續接受新的請求，若是出現問題線程池隔離是獨立的不會影響其餘應用。 
    三、 當失敗的應用再次變得可用時，線程池將清理並可當即恢復，而不須要一個長時間的恢復。 
    四、 獨立的線程池提升了併發性。

    注意：儘管線程池隔離是由一個單獨的線程提供，客戶端代碼（異常方法裏面的請求）應該也 有超時機制，不能讓響應的線程無限期等待，應該適時去中斷它，阻止 Hystrix 線程池的飽和。

缺點： 
    線程池隔離的主要缺點是它們增長計算開銷（CPU）。每一個命令的執行涉及到排隊、調度和上 下文切換都是在一個單獨的線程上運行的。

 

4、 應用場景 

線程池隔離： 
    一、 第三方應用或者接口 
    二、 併發量大

信號量隔離：      一、 內部應用或者中間件（redis）      二、 併發需求不大