hystrix隔離策略

zuul的隔離實現是基于hystrix實現的，hystrix支持線程池隔離和信號量的隔離

# 信號量隔離：

• it executes on the calling thread and concurrent requests are limited by the semaphore count --引自官網
• 單每次調用線程，當前請求通過技術信號量進行限制，當信號量大于了最大請求數（maxConcurrentRequest）時候，觸發限制，調用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.
• 兩點：
  • 隔離的粒度太細，數百個實例需要隔離，此時用線程池做隔離開銷過大
  • 通常這種都是非網絡調用的情況下

# 線程池隔離

• 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.

線程池隔離方式，等于多了一層保護措施，可以通過hystryx直接設置超時時間，超時后直接返回

對比表格‘：

隔離方式是否支持超時是否支持熔斷隔離原理是否異步調用資源消耗

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

• zuul網關如果使用線程池隔離是屬于異步調用，其實查看源碼如下：

調用的是hystrix 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隔离策略对比的全部內容，希望文章能夠幫你解決所遇到的問題。

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