Hystrix 服務的隔離策略對比，信號量與線程池隔離的差別

hytrix支持線程池隔離和信號量隔離

• 信號量隔離適應非網絡請求，由於是同步的請求，沒法支持超時，只能依靠協議自己
• 線程池隔離，即，每一個實例都增長個線程池進行隔離

 

先給個總結對比：

隔離方式	是否支持超時	是否支持熔斷	隔離原理	是不是異步調用	資源消耗
線程池隔離	支持，可直接返回	支持，當線程池到達maxSize後，再請求會觸發fallback接口進行熔斷	每一個服務單獨用線程池	能夠是異步，也能夠是同步。看調用的方法	大，大量線程的上下文切換，容易形成機器負載高
信號量隔離	不支持，若是阻塞，只能經過調用協議（如：socket超時才能返回）	支持，當信號量達到maxConcurrentRequests後。再請求會觸發fallback	經過信號量的計數器	同步調用，不支持異步	小，只是個計數器

 

看官網的定義引用理解

信號量的隔離：

•  it executes on the calling thread and concurrent requests are limited by the semaphore count

 - 引自官網

自我理解:

每次調用線程，當前請求經過計數信號量進行限制，當信號大於了最大請求數（maxConcurrentRequests）時，進行限制，調用fallback接口快速返回。

 

最重要的是，信號量的調用是同步的，也就是說，每次調用都得阻塞調用方的線程，直到結果返回。這樣就致使了沒法對訪問作超時（只能依靠調用協議超時，沒法主動釋放）

官網對信號量隔離的描述建議

• Generally the only time you should use semaphore isolation for HystrixCommands is when the call is so high volume (hundreds per second, per instance) that the overhead of separate threads is too high; this typically only applies to non-network calls.

 理解下兩點：

1. 隔離的細粒度過高，數百個實例須要隔離，此時用線程池作隔離開銷過大
2. 一般這種都是非網絡調用的狀況下

線程池隔離:

• it executes on a separate thread and concurrent requests are limited by the number of threads in the thread-pool

經過每次都開啓一個單獨線程運行。它的隔離是經過線程池，即每一個隔離粒度都是個線程池，互相不干擾

• Commands executed in threads have an extra layer of protection against latencies beyond what network timeouts can offer.

線程池隔離方式，等於多了一層的保護措施，能夠經過hytrix直接設置超時，超時後直接返回。

 

 

 

 分享個之前的一個誤解

 

之前對zuul網關的一個誤解，覺得網關用的是線程池隔離是屬於異步調用的，覺得只要用了線程池隔離，不須要去考慮自己具體的線程池大小了。

具體看源碼：

 

調用的是hytrix command的excute方法，hytrix的官網原文說明以下：

• execute() — blocks, then returns the single response received from the dependency (or throws an exception in case of an error)

 

execute是一個阻塞方法，也就是說，若是不合理的設置線程池的大小，和超時時間，仍是有可能把zuul的線程消耗完。從而失去對服務的保護做用

 

公衆號：

何錦彬 2018.09.21