hystrix熔斷機制修改配置

0、注意

0.1、如果使用command 的 execute( )方法的話,其實在一個for循環,執行多次,其實每個的執行順序並不是固定的,如果你想固定,需要使用queue

 circuit breaker OPEN, execution not attempte

 0.2、進入短路狀態,不需要執行run,所以不需要一個新的線程,直接main就好了

 

 

具體代碼參考 https://gitlab.com/hitxujian/test_hystrix/blob/master/src/main/java/com/unisound/test_hystrix/HelloWorldCommand2.java

 

 

一、修改參數

設置參數有3個地方:通過日誌

2018-02-12 18:07:36.876 DEBUG HystrixPropertiesChainedProperty:93 - Flipping property: hystrix.command.HttpPostCommand.execution.isolation.thread.timeoutInMilliseconds to use NEXT property: hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds = 1000

2018-02-12 18:07:37.113 DEBUG HystrixPropertiesChainedProperty:236 - Property changed: 'hystrix.command.HttpPostCommand.execution.isolation.thread.timeoutInMilliseconds = 500'

可以看到3個參數  

hystrix.command.HttpPostCommand.execution.isolation.thread.timeoutInMilliseconds

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds

hystrix.command.HttpPostCommand.execution.isolation.thread.timeoutInMilliseconds

 

 》》其中default是在 command類之外

ConfigurationManager.getConfigInstance().setProperty("hystrix.command.default.circuitBreaker.forceOpen", true);

》》然後剩下的那個可以在command類內修改

 

 

二、在 callback中打印異常信息

@Override
protected String getFallback() {
// String reason=null;
// if (isCircuitBreakerOpen()) {
// reason = "Circuit Breaker Open";
// } else if (isResponseRejected()) {
// reason = "Response rejected";
// } else if (isResponseTimedOut()) {
// reason = "Response timed-out";
// }


//System.out.println("進入回調");
log.info("發生了回調異常信息是"+ getExecutionException());

return null;
}

 三、熔斷器3種狀態,

熔斷打開 就是trip,表示跳閘了

正常狀態下,電路處於關閉狀態(Closed),如果調用持續出錯或者超時,電路被打開進入熔斷狀態(Open),後續一段時間內的所有調用都會被拒絕(Fail Fast),

這個拒絕時間withCircuitBreakerSleepWindowInMilliseconds控制默認是5s

一段時間以後,保護器會嘗試進入半熔斷狀態(Half-Open),允許少量請求進來嘗試,如果調用仍然失敗,則回到熔斷狀態,如果調用成功,則回到電路閉合狀態;

 

具體解釋3種狀態

Closed State

When the service dependency is healthy and no issues are detected, the Circuit Breaker is in state closed. All invocations are passed through to the service.

Open State

The Circuit Breaker considers the following invocations as failed and factors them in when deciding whether to trip the circuit open:

    • An exception thrown (e.g., cannot connect, or service returns HTTP error 500)

    • The call takes longer than the configured timeout (by default 1 second)

    • The internal thread pool (or semaphore) used by Hystrix for the command rejects execution (Hystrix uses thread pools to limit resources used by a dependency)

The circuit opens as soon as Hystrix determines that the error threshold over a statistical time window has been reached (by default 50% errors over a 10 seconds window). In the open state, the Circuit Breaker will reject invocations by either:

    • Throwing an exception (also termed "fail fast", this is the default behavior)

    • Returning a fallback result (e.g., returning a null, empty, or stubbed result)

Half-Open State

To be able to recover from the error condition, when the Circuit Breaker is in the open state, it periodically leaves through one invocation at a configurable interval (by default 5 seconds) - this is the half-open state. If the invocation succeeds, the circuit is closed again.----

注意這的說法熔斷後,等一定時間間隔,比如5s,再次接受請求,如果這個請求成功,那麼熔斷器關閉

四、熔斷器具體執行邏輯

 

 

  1. 將遠程服務調用邏輯封裝進一個HystrixCommand。

  2. 對於每次服務調用可以使用同步或異步機制,對應執行execute()或queue()。

  3. 判斷熔斷器(circuit-breaker)是否打開或者半打開狀態,如果打開跳到步驟8,進行回退策略,如果關閉進入步驟4。

  4. 判斷線程池/隊列/信號量(使用了艙壁隔離模式)是否跑滿,如果跑滿進入回退步驟8,否則繼續後續步驟5。

  5. run方法中執行了實際的服務調用。

    a. 服務調用發生超時時,進入步驟8。

  6. 判斷run方法中的代碼是否執行成功。

    a. 執行成功返回結果。

    b. 執行中出現錯誤則進入步驟8。

  7. 所有的運行狀態(成功,失敗,拒絕,超時)上報給熔斷器,用於統計從而影響熔斷器狀態。

  8. 進入getFallback()回退邏輯。

    a. 沒有實現getFallback()回退邏輯的調用將直接拋出異常。

    b. 回退邏輯調用成功直接返回。

    c. 回退邏輯調用失敗拋出異常。

  9. 返回執行成功結果。

 五、關於線程池說明

首先說明兩個數據結構:  the set of tasks  和   a queue,然後分別介紹這兩個數據結構,具體可以網上搜索allowMaximumSizeToDivergeFromCoreSize

There are 2 data structures involved in a thread pool: the set of tasks (the actual pool), and a queue in front of the thread pool.

The thread pool contains all tasks which are currently running. Configuring this pool sets up the number of threads that may execute concurrently. Relevant config:

    • coreSize: number of threads to keep in the pool at all times
    • maximumSize: maximum number of threads in the pool
    • allowMaximumSizeToDivergeFromCoreSize: allow the prior config values to differ (previously only coreSize was exposed, and maximumSize was forced to that value)

The queue is a different data structure. It contains tasks which have not yet begun to run. Tasks first get placed in this queue, and the thread pool picks them up from there. Relevant config:

    • maxQueueSize: size of the queue (static - can only get set at startup)
    • queueRejectionThreshold: some number below the maxQueueSize that controls maximum number of tasks in the queue. If queueRejectionThreshold is 5, and there are 5 tasks in the queue, the queue will reject the next task submitted.

 

 

 

 

參考

http://www.cnblogs.com/ulysses-you/p/7281662.html

http://www.lordofthejars.com/2014/09/defend-your-application-with-hystrix.html

https://www.slideshare.net/spjelkavik/hystrix-what-did-we-learn?qid=bc5fba99-23da-41bd-9530-8c3207770cac&v=&b=&from_search=2

http://bed-con.org/2014/files/slides/uwe_friedrichsen-hystrix.pdf  關於參數配置(*)

https://tech.meituan.com/service-fault-tolerant-pattern.html

http://www.hascode.com/2017/02/resilient-architecture-circuit-breakers-for-java-hystrix-vert-x-javaslang-and-failsafe-examples/

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章