HystrixCommand 支持的參數，除了?`commandKey/observableExecutionMode/fallbackMethod`?外，都可以使用?`@DefaultProperties`?配置默認值。 * **commandKey**：用來標識一個 Hystrix 命令，默認會取被注解的方法名。需要注意：`Hystrix 里同一個鍵的唯一標識并不包括 groupKey`，建議取一個獨一二無的名字，防止多個方法之間因為鍵重復而互相影響。 * **groupKey**：一組 Hystrix 命令的集合， 用來統計、報告，默認取類名，可不配置。 * **threadPoolKey**：用來標識一個線程池，`如果沒設置的話會取 groupKey`，很多情況下都是同一個類內的方法在共用同一個線程池，如果兩個共用同一線程池的方法上配置了同樣的屬性，在第一個方法被執行后線程池的屬性就固定了，所以屬性會以第一個被執行的方法上的配置為準。 * **commandProperties**：與此命令相關的屬性。 * **threadPoolProperties**：與線程池相關的屬性， * **observableExecutionMode**：當 Hystrix 命令被包裝成 RxJava 的 Observer 異步執行時，此配置指定了 Observable 被執行的模式，默認是?`ObservableExecutionMode.EAGER`，Observable 會在被創建后立刻執行，而?`ObservableExecutionMode.EAGER`模式下，則會產生一個 Observable 被 subscribe 后執行。我們常見的命令都是同步執行的，此配置項可以不配置。 * **ignoreExceptions**：默認 Hystrix 在執行方法時捕獲到異常時執行回退，并統計失敗率以修改熔斷器的狀態，而被忽略的異常則會直接拋到外層，不會執行回退方法，也不會影響熔斷器的狀態。 * **raiseHystrixExceptions**：當配置項包括?`HystrixRuntimeException`?時，所有的未被忽略的異常都會被包裝成 HystrixRuntimeException，配置其他種類的異常好像并沒有什么影響。 * **fallbackMethod**：方法執行時熔斷、錯誤、超時時會執行的回退方法，需要保持此方法與 Hystrix 方法的簽名和返回值一致。 * **defaultFallback**：默認回退方法，當配置 fallbackMethod 項時此項沒有意義，另外，默認回退方法不能有參數，返回值要與 Hystrix方法的返回值相同。 ## commandProperties * * * 配置方式 Hystrix 的命令屬性是由?`@HystrixProperty`?注解數組構成的，HystrixProperty 由 name 和 value 兩個屬性，數據類型都是字符串。 以下將所有的命令屬性分組來介紹。 線程隔離(Isolation) * **execution.isolation.strategy**： 配置請求隔離的方式，有 threadPool（線程池，默認）和 semaphore（信號量）兩種，信號量方式高效但配置不靈活，我們一般采用 Java 里常用的線程池方式。 * **execution.timeout.enabled**：是否給方法執行設置超時，默認為 true。 * **execution.isolation.thread.timeoutInMilliseconds**：方法執行超時時間，默認值是 1000，即 1秒，此值根據業務場景配置。 * **execution.isolation.thread.interruptOnTimeout**：?**execution.isolation.thread.interruptOnCancel**：是否在方法執行超時/被取消時中斷方法。需要注意在 JVM 中我們無法強制中斷一個線程，如果 Hystrix 方法里沒有處理中斷信號的邏輯，那么中斷會被忽略。 * **execution.isolation.semaphore.maxConcurrentRequests**：默認值是 10，此配置項要在?`execution.isolation.strategy`?配置為?`semaphore`?時才會生效，它指定了一個 Hystrix 方法使用信號量隔離時的最大并發數，超過此并發數的請求會被拒絕。信號量隔離的配置就這么一個，也是前文說信號量隔離配置不靈活的原因。 統計器(Metrics) **`滑動窗口`**： Hystrix 的統計器是由滑動窗口來實現的，我們可以這么來理解滑動窗口：一位乘客坐在正在行駛的列車的靠窗座位上，列車行駛的公路兩側種著一排挺拔的白楊樹，隨著列車的前進，路邊的白楊樹迅速從窗口滑過，我們用每棵樹來代表一個請求，用列車的行駛代表時間的流逝，那么，列車上的這個窗口就是一個典型的滑動窗口，這個乘客能通過窗口看到的白楊樹就是 Hystrix 要統計的數據。 **`桶`**： bucket 是 Hystrix 統計滑動窗口數據時的最小單位。同樣類比列車窗口，在列車速度非常快時，如果每掠過一棵樹就統計一次窗口內樹的數據，顯然開銷非常大，如果乘客將窗口分成十分，列車前進行時每掠過窗口的十分之一就統計一次數據，開銷就完全可以接受了。 Hystrix 的 bucket （桶）也就是窗口 N分之一 的概念。 * **metrics.rollingStats.timeInMilliseconds**：此配置項指定了窗口的大小，單位是 ms，默認值是 1000，即一個滑動窗口默認統計的是 1s 內的請求數據。 * **metrics.healthSnapshot.intervalInMilliseconds**：它指定了健康數據統計器（影響 Hystrix 熔斷）中每個桶的大小，默認是 500ms，在進行統計時，Hystrix 通過?`metrics.rollingStats.timeInMilliseconds / metrics.healthSnapshot.intervalInMilliseconds`?計算出桶數，在窗口滑動時，每滑過一個桶的時間間隔時就統計一次當前窗口內請求的失敗率。 * **metrics.rollingStats.numBuckets**：Hystrix 會將命令執行的結果類型都統計匯總到一塊，給上層應用使用或生成統計圖表，此配置項即指定了，生成統計數據流時滑動窗口應該拆分的桶數。此配置項最易跟上面的?`metrics.healthSnapshot.intervalInMilliseconds`?搞混，認為此項影響健康數據流的桶數。 此項默認是 10，并且需要保持此值能被?`metrics.rollingStats.timeInMilliseconds`?整除。 * **metrics.rollingPercentile.enabled**：是否統計方法響應時間百分比，默認為 true 時，Hystrix 會統計方法執行的?`1%,10%,50%,90%,99%`?等比例請求的平均耗時用以生成統計圖表。 * **metrics.rollingPercentile.timeInMilliseconds**：統計響應時間百分比時的窗口大小，默認為 60000，即一分鐘。 * **metrics.rollingPercentile.numBuckets**：統計響應時間百分比時滑動窗口要劃分的桶用，默認為6，需要保持能被`metrics.rollingPercentile.timeInMilliseconds`?整除。 * **metrics.rollingPercentile.bucketSize**：統計響應時間百分比時，每個滑動窗口的桶內要保留的請求數，桶內的請求超出這個值后，會覆蓋最前面保存的數據。默認值為 100，在統計響應百分比配置全為默認的情況下，每個桶的時間長度為 10s = 60000ms / 6，但這 10s 內只保留最近的 100 條請求的數據。 熔斷器(Circuit Breaker) * **circuitBreaker.enabled**：是否啟用熔斷器，默認為 true; * **circuitBreaker.forceOpen**：?**circuitBreaker.forceClosed**：是否強制啟用/關閉熔斷器，強制啟用關閉都想不到什么應用的場景，保持默認值，不配置即可。 * **circuitBreaker.requestVolumeThreshold**：啟用熔斷器功能窗口時間內的最小請求數。試想如果沒有這么一個限制，我們配置了 50% 的請求失敗會打開熔斷器，窗口時間內只有 3 條請求，恰巧兩條都失敗了，那么熔斷器就被打開了，5s 內的請求都被快速失敗。此配置項的值需要根據接口的 QPS 進行計算，值太小會有誤打開熔斷器的可能，值太大超出了時間窗口內的總請求數，則熔斷永遠也不會被觸發。建議設置為?`QPS * 窗口秒數 * 60%`。 * **circuitBreaker.errorThresholdPercentage**：在通過滑動窗口獲取到當前時間段內 Hystrix 方法執行的失敗率后，就需要根據此配置來判斷是否要將熔斷器打開了。 此配置項默認值是 50，即窗口時間內超過 50% 的請求失敗后會打開熔斷器將后續請求快速失敗。 * **circuitBreaker.sleepWindowInMilliseconds**：熔斷器打開后，所有的請求都會快速失敗，但何時服務恢復正常就是下一個要面對的問題。熔斷器打開時，Hystrix 會在經過一段時間后就放行一條請求，如果這條請求執行成功了，說明此時服務很可能已經恢復了正常，那么會將熔斷器關閉，如果此請求執行失敗，則認為服務依然不可用，熔斷器繼續保持打開狀態。此配置項指定了熔斷器打開后經過多長時間允許一次請求嘗試執行，默認值是 5000。 其他(Context/Fallback) * **requestCache.enabled**：是否啟用請求結果緩存。默認是 true，但它并不意味著我們的每個請求都會被緩存。緩存請求結果和從緩存中獲取結果都需要我們配置?`cacheKey`，并且在方法上使用?`@CacheResult`?注解聲明一個緩存上下文。 * **requestLog.enabled**：是否啟用請求日志，默認為 true。 * **fallback.enabled**：是否啟用方法回退，默認為 true 即可。 * **fallback.isolation.semaphore.maxConcurrentRequests**：回退方法執行時的最大并發數，默認是10，如果大量請求的回退方法被執行時，超出此并發數的請求會拋出?`REJECTED_SEMAPHORE_FALLBACK`?異常。 ## threadPoolProperties * * * 配置方式 線程池的配置也是由 HystrixProperty 數組構成，配置方式與命令屬性一致。 配置項 * **coreSize**：核心線程池的大小，默認值是 10，一般根據?`QPS * 99% cost + redundancy count`?計算得出。 * **allowMaximumSizeToDivergeFromCoreSize**：是否允許線程池擴展到最大線程池數量，默認為 false; * **maximumSize**：線程池中線程的最大數量，默認值是 10，此配置項單獨配置時并不會生效，需要啟用?`allowMaximumSizeToDivergeFromCoreSize`?項。 * **maxQueueSize**：作業隊列的最大值，默認值為 -1，設置為此值時，隊列會使用?`SynchronousQueue`，此時其 size 為0，Hystrix 不會向隊列內存放作業。如果此值設置為一個正的 int 型，隊列會使用一個固定 size 的?`LinkedBlockingQueue`，此時在核心線程池內的線程都在忙碌時，會將作業暫時存放在此隊列內，但超出此隊列的請求依然會被拒絕。 * **queueSizeRejectionThreshold**：由于?`maxQueueSize`?值在線程池被創建后就固定了大小，如果需要動態修改隊列長度的話可以設置此值，即使隊列未滿，隊列內作業達到此值時同樣會拒絕請求。此值默認是 5，所以有時候只設置了?`maxQueueSize`?也不會起作用。 * **keepAliveTimeMinutes**：由上面的?`maximumSize`，我們知道，線程池內核心線程數目都在忙碌，再有新的請求到達時，線程池容量可以被擴充為到最大數量，等到線程池空閑后，多于核心數量的線程還會被回收，此值指定了線程被回收前的存活時間，默認為 2，即兩分鐘。 工作方式 Hystrix 內線程池的使用是基于 Java 內置線程池的簡單包裝，通常有以下三種狀態： * 如果請求量少，達不到 coreSize，通常會使用核心線程來執行任務。 * 如果設置了?`maxQueueSize`，當請求數超過了 coreSize, 通常會把請求放到 queue 里，待核心線程有空閑時消費。 * 如果 queue 長度無法存儲請求，則會創建新線程執行直到達到?`maximumSize`?最大線程數，多出核心線程數的線程會在空閑時回收。 自定義超時配置 ~~~ @HystrixCommand(commandProperties = { @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "3000") }) ~~~ ~~~ 1.默認：（方法上記得要加上@HystrixCommand，否則無效）： hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=3000 2.配置具體方法的超時時間 hystrix.command.serverMethod.execution.isolation.thread.timeoutInMilliseconds=3000 ~~~ 配置文件給commandKey配置超時時間： ``` @HystrixCommand(fallbackMethod="fallback",commandKey="userGetKey") hystrix.command.userGetKey.execution.isolation.thread.timeoutInMilliseconds = 13000 ```