1、hystrix的做用git
2、hystrix實現中須要注意的點github
3、hystrix線程模型緩存
4、hystrix執行流程(工做機理)tomcat
附:清晰大圖運維
步驟:(配合上圖去看)ui
一、構建HystrixCommand或者HystrixObservableCommand對象線程
二、執行命令(execute()、queue()、observe())得到返回結果(僅僅是得到,並無返回給調用端)翻譯
三、若是請求結果緩存這個特性被啓用,而且緩存命中,則緩存的迴應會當即經過一個 Observable
對象的形式返回。日誌
四、檢查熔斷器狀態,肯定請求線路是不是開路,若是請求線路是開路,Hystrix 將不會執行這個命令,而是直接使用『失敗回退邏輯』(即不會執行run(),直接執行getFallback())code
五、若是和當前須要執行的命令相關聯的線程池和請求隊列(或者信號量,若是不使用線程池)滿了,Hystrix 將不會執行這個命令,而是直接使用『失敗回退邏輯』(即不會執行run(),直接執行getFallback())
六、執行HystrixCommand.run()或HystrixObservableCommand.construct(),若是這兩個方法執行超時或者執行失敗,則執行getFallback();若是正常結束,Hystrix 在添加一些日誌和監控數據採集以後,直接返回
迴應
七、Hystrix 會將請求成功,失敗,被拒絕或超時信息報告給熔斷器,熔斷器維護一些用於統計數據用的計數器。
這些計數器產生的統計數據使得熔斷器在特定的時刻,能短路某個依賴服務的後續請求,直到恢復期結束,若恢復期結束根據統計數據熔斷器斷定線路仍然未恢復健康,熔斷器會再次關閉線路。
5、熔斷器執行流程(工做機理)
附:清晰大圖
一、假設線路內的容量(請求QPS)達到必定閾值(經過 HystrixCommandProperties.circuitBreakerRequestVolumeThreshold()
配置),同時,假設線路內的錯誤率達到必定閾值(經過 HystrixCommandProperties.circuitBreakerErrorThresholdPercentage()
配置)
二、熔斷器將從『閉路』轉換成『開路』
三、若此時是『開路』狀態,熔斷器將短路後續全部通過該熔斷器的請求,這些請求直接走『失敗回退邏輯』(即不走run(),直接走getFallback())
四、通過必定時間(即『休眠窗口』,經過 HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()
配置),後續第一個請求將會被容許經過熔斷器(此時熔斷器處於『半開』狀態),若該請求失敗,熔斷器將又進入『開路』狀態,且在休眠窗口內保持此狀態;若該請求成功,熔斷器將進入『閉路』狀態,回到邏輯1循環往復。
6、線程池與信號量
使用場景:對於那些原本延遲就比較小的請求(例如訪問本地緩存成功率很高的請求)來講,線程池帶來的開銷是很是高的,這時,你能夠考慮採用其餘方法,例如非阻塞信號量(不支持超時),來實現依賴服務的隔離,使用信號量的開銷很小。但絕大多數狀況下,Netflix 更偏向於使用線程池來隔離依賴服務,由於其帶來的額外開銷能夠接受,而且能支持包括超時在內的全部功能。
若是你對客戶端庫有足夠的信任(延遲不會太高),而且你只須要控制系統負載,那麼你可使用信號量。
7、請求合併
參考:
https://github.com/Netflix/Hystrix/wiki
http://youdang.github.io/categories/%E7%BF%BB%E8%AF%91/ 對官網翻譯的很是好,惋惜沒有翻譯完