支持的隔離策略

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

信號量的隔離：

• 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直接設置超時，超時后直接返回。

最后總結對比下：

最后總結對比下：

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

附上：

以前對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的線程消耗完。從而失去對服務的保護作用

總結

以上是生活随笔為你收集整理的Hystrix 服务的隔离策略对比，信号量与线程池隔离的差异的全部內容，希望文章能夠幫你解決所遇到的問題。

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