轉載自:http://blog.smallerpig.com/what-hystrix-maxConcurrentRequest-meaning.html
敘述
組內同學在開發過程中遇到了個問題,
在使用@HystrixCommand(fallbackMethod = "fallBackVisistInfo")
註解對某個負載均衡的請求方法進行操作時,在大併發請求下,總是會有大部分的請求直接進入fallback,根本不會去請求真正對應的微服務。
如下代碼:
@Override
@HystrixCommand(fallbackMethod = "fallBackVisistInfo")
public JSONObject getUserVisitInfo(String userkey ) {
String url = "http://serverid/api/ping?"
+"userKey=" +userkey ;
logger.info("請求鏈接 {}",url );
JSONObject result = restTemplate.getForObject(url ,JSONObject.class);
logger.info("request result :{}", result.toJSONString());
return result;
}
public JSONObject fallBackVisistInfo(String username) {
logger.debug("【請求異常】,使用默認值{},{}",0,0);
JSONObject jsonObject = new JSONObject();
jsonObject.put("returnCode", RequestConstants.REQUEST_SUCCESS_CODE);
jsonObject.put("returnMsg", RequestConstants.REQUEST_SUCCESS_MSG);
jsonObject.put("returnData", new JSONObject());
return jsonObject;
}
當然,定位到該問題需要個過程,今天分享的是怎樣解決這個問題。
解決方案
從google中找到了這樣的一個問題:
https://stackoverflow.com/questions/39609636/hystrixruntimeexception-testcommand-fallback-execution-rejected
https://github.com/Netflix/Hystrix/issues/796
正如上面的回覆,
默認的Hystrix會限制某個請求的最大併發量:默認10,如果超過了這個默認的併發值且開啓了fallback,則丟棄剩下的請求直接進入fallback方法,找到方法之後就是修改配置的事情了。
不過作者也建議謹慎修改該值,該值的合理性會影響生產環境的穩定性
在配置文件中加上如下配置:
hystrix.command.default.execution.isolation.strategy=SEMAPHORE
# 核心的兩個設置,允許併發量1000的請求,默認情況下下面兩個值都是10,也就是超過10個的併發會直接進入fallback方法,不會去真正請求
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests=1000
hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests=1000
hystrix.command.default.execution.timeout.enabled=false
hystrix.command.default.circuitBreaker.enabled=false
hystrix.command.default.fallback.enabled=true
上述代碼將允許的最大併發請求設置爲1000,不過在生產環境下還是需要謹慎設置該值,
另外需要讀者好好了解的是hystrix的兩種策略
也就是配置項hystrix.command.default.execution.isolation.strategy
的兩個值
THREAD 默認
運行在獨立的線程裏,併發請求量受線程池數量限制
SEMAPHORE
併發請求量受 semaphore設置量大小。
在設置爲SEMAPHORE
之後可以設置maxConcurrentRequests的數量了。
關於上述兩個關鍵值,官方文檔的解釋是:
設置好值之後就可以解決