資源隔離袁滥，兩種策略，線程池隔離灾螃，信號量隔離
對資源隔離這一塊東西题翻，做稍微更加深入一些的講解，告訴你腰鬼，除了可以選擇隔離策略以外嵌赠，對你選擇的隔離策略，可以做一定的細粒度的一些控制
1熄赡、execution.isolation.strategy
指定了HystrixCommand.run()的資源隔離策略姜挺，THREAD或者SEMAPHORE，一種是基于線程池彼硫，一種是信號量
線程池機制炊豪，每個command運行在一個線程中凌箕，限流是通過線程池的大小來控制的
信號量機制，command是運行在調用線程中词渤，但是通過信號量的容量來進行限流
如何在線程池和信號量之間做選擇牵舱？
默認的策略就是線程池
線程池其實最大的好處就是對于網絡訪問請求，如果有超時的話缺虐，可以避免調用線程阻塞住
而使用信號量的場景芜壁，通常是針對超大并發(fā)量的場景下，每個服務實例每秒都幾百的QPS志笼，那么此時你用線程池的話沿盅，線程一般不會太多把篓，可能撐不住那么高的并發(fā)纫溃，如果要撐住，可能要耗費大量的線程資源韧掩，那么就是用信號量紊浩，來進行限流保護
一般用信號量常見于那種基于純內存的一些業(yè)務邏輯服務，而不涉及到任何網絡訪問請求
netflix有100+的command運行在40+的線程池中疗锐，只有少數command是不運行在線程池中的坊谁，就是從純內存中獲取一些元數據，或者是對多個command包裝起來的facacde command滑臊，是用信號量限流的
// to use thread isolation
HystrixCommandProperties.Setter()
.withExecutionIsolationStrategy(ExecutionIsolationStrategy.THREAD)
// to use semaphore isolation
HystrixCommandProperties.Setter()
.withExecutionIsolationStrategy(ExecutionIsolationStrategy.SEMAPHORE)
2口芍、command名稱和command組
線程池隔離，依賴服務->接口->線程池雇卷，如何來劃分
你的每個command鬓椭，都可以設置一個自己的名稱，同時可以設置一個自己的組
private static final Setter cachedSetter =
Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
.andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld"));
public CommandHelloWorld(String name) {
super(cachedSetter);
this.name = name;
}
command group关划，是一個非常重要的概念小染，默認情況下，因為就是通過command group來定義一個線程池的贮折，而且還會通過command group來聚合一些監(jiān)控和報警信息
同一個command group中的請求裤翩，都會進入同一個線程池中
3、command線程池
threadpool key代表了一個HystrixThreadPool调榄，用來進行統一監(jiān)控踊赠，統計，緩存
默認的threadpool key就是command group名稱
每個command都會跟它的threadpool key對應的thread pool綁定在一起
如果不想直接用command group每庆，也可以手動設置thread pool name
public CommandHelloWorld(String name) {
super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
.andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld"))
.andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("HelloWorldPool")));
this.name = name;
}
command threadpool -> command group -> command key
command key筐带，代表了一類command，一般來說扣孟，代表了底層的依賴服務的一個接口
command group烫堤，代表了某一個底層的依賴服務，合理，一個依賴服務可能會暴露出來多個接口鸽斟，每個接口就是一個command key
command group拔创，在邏輯上去組織起來一堆command key的調用，統計信息富蓄，成功次數剩燥，timeout超時次數，失敗次數立倍，可以看到某一個服務整體的一些訪問情況
command group灭红，一般來說，推薦是根據一個服務去劃分出一個線程池口注，command key默認都是屬于同一個線程池的
比如說你以一個服務為粒度变擒，估算出來這個服務每秒的所有接口加起來的整體QPS在100左右
你調用那個服務的當前服務，部署了10個服務實例寝志，每個服務實例上娇斑，其實用這個command group對應這個服務，給一個線程池材部，量大概在10個左右毫缆，就可以了，你對整個服務的整體的訪問QPS大概在每秒100左右
一般來說乐导，command group是用來在邏輯上組合一堆command的
舉個例子苦丁，對于一個服務中的某個功能模塊來說，希望將這個功能模塊內的所有command放在一個group中物臂，那么在監(jiān)控和報警的時候可以放一起看
command group旺拉，對應了一個服務，但是這個服務暴露出來的幾個接口鹦聪，訪問量很不一樣账阻，差異非常之大
你可能就希望在這個服務command group內部，包含的對應多個接口的command key泽本，做一些細粒度的資源隔離
對同一個服務的不同接口淘太，都使用不同的線程池
command key -> command group
command key -> 自己的threadpool key
邏輯上來說，多個command key屬于一個command group规丽，在做統計的時候蒲牧，會放在一起統計
每個command key有自己的線程池，每個接口有自己的線程池赌莺，去做資源隔離和限流
但是對于thread pool資源隔離來說冰抢，可能是希望能夠拆分的更加一致一些，比如在一個功能模塊內艘狭，對不同的請求可以使用不同的thread pool
command group一般來說挎扰，可以是對應一個服務翠订，多個command key對應這個服務的多個接口，多個接口的調用共享同一個線程池
如果說你的command key遵倦，要用自己的線程池尽超，可以定義自己的threadpool key，就ok了
4梧躺、coreSize
設置線程池的大小似谁，默認是10
HystrixThreadPoolProperties.Setter()
.withCoreSize(int value)
一般來說，用這個默認的10個線程大小就夠了
5掠哥、queueSizeRejectionThreshold
控制queue滿后reject的threshold巩踏，因為maxQueueSize不允許熱修改，因此提供這個參數可以熱修改续搀，控制隊列的最大大小
HystrixCommand在提交到線程池之前塞琼，其實會先進入一個隊列中，這個隊列滿了之后目代，才會reject
默認值是5
HystrixThreadPoolProperties.Setter()
.withQueueSizeRejectionThreshold(int value)
6屈梁、execution.isolation.semaphore.maxConcurrentRequests
設置使用SEMAPHORE隔離策略的時候，允許訪問的最大并發(fā)量榛了，超過這個最大并發(fā)量，請求直接被reject
這個并發(fā)量的設置煞抬，跟線程池大小的設置霜大，應該是類似的，但是基于信號量的話革答，性能會好很多战坤，而且hystrix框架本身的開銷會小很多
默認值是10，設置的小一些残拐，否則因為信號量是基于調用線程去執(zhí)行command的途茫，而且不能從timeout中抽離，因此一旦設置的太大溪食，而且有延時發(fā)生囊卜，可能瞬間導致tomcat本身的線程資源本占滿
HystrixCommandProperties.Setter()
.withExecutionIsolationSemaphoreMaxConcurrentRequests(int value)
