Hystrixを理解します
スレッドプールの分離、セマフォ分離、ヒューズ、降格バック：HystrixオープンソースのNetflixは、フォールトトレランスの一般的に使用される方法を含む、フォールト・トレラント・フレームワークです。高い同時アクセスでは、サービスシステムの安定性に影響を与えることはシステムによって異なり非常に大きく、そのような低速のネットワーク接続、オフラインなどのサービス、一時的に利用できない、突然忙しくリソースとして制御不能な要因に依存たくさんあります。我々は安定した、信頼性の高い分散システムを構築したい、そのようなAのフォールトトレラントの方法を持っていることが必要です。
紙は、これらの4つの技術のスレッドプールの分離、セマフォ分離、ヒューズ、降格原則と実践のロールバックを分析します。
ダボヒューズ、Hystrixはあまり頼みます
エラーの確率を持っています層やストレージレイヤをキャッシュするかどうか、彼らは資源とみなすことができます。リソースが利用できない場合、並行システムの大規模な量としては、それは、システム全体が使用不能に引き起こし、このリソース上のスレッドのすべてのハング（ハング）を引き起こす可能性があります。完全に正常性の高い並行システムにおけるダウングレード：例えば、推奨サービスパーソナライズされた推薦サービスが利用できない場合、あなたはホットデータを追加するためにダウングレードすることができますが、フロントページ原因ウィンドウを開くことではありません。
ダボ差と春の雲の
ヒューズを制限するサービス低下
話題に入る前に、問題がある、分散システムは、必ず出会いサービスへのこのサービスは、それが何であるか雪崩、雪崩効果ありか？
下の写真は、この問題をすることができます示して
雪崩チャートサーブ
リストはサービスが（1の商品のレビューサービスが利用できない場合、共有リストサービス・スレッド・プールに依存します3つのサービスを呼び出して、商品やサービス、価格、サービス、製品のレビューやサービスに依存します示してタイムアウト、コードの異常など）、応答がブロックされているため、プールのスレッドがすべての雪崩のサービスで、その結果、待っているスレッドが存在します。
概要については、この次のとおりです。サービスプロバイダの使用不能、発信者のサービスが利用可能であり、使用できないではないので、徐々にプロセスを拡大し、サービスがアバランシェ効果と呼ばれ、この文をよく理解しなければならない、説明することはあまりありません。
ここでは雪崩の原因は、サービスプロバイダの利用不能である知っているだろうし、サービスプロバイダの原因はそれを使用することはできません何ですか？より多くのようにいくつかのポイントよりも何もない：大流量要求（高い同時実行）、ハードウェアの問題、キャッシュ破壊、バグプログラム、タイムアウトなどのプロバイダ
、ここで解決する方法を考えますか？最初に考えたサービスプロバイダはリトライが潜在的に望ましくないので、リトライ、側に設けられた圧力を増大させる、利用できない場合、再試行です。
ここでは、ボトルネック、その後は問題ではありません場所について、端部であるにおけるサービス雪崩の根本的な原因は何だと思いますか？
それは次のようになります。
大量请求线程同步等待造成的资源耗尽
当服务调用者使用同步调用的时候，会产生大量的等待线程占用系统资源，一旦线程资源被耗尽，
服务调用者提供的服务也将处于不可用状态，于是服务雪崩效应产生了！
知道了根本原因，问题来了，怎么解决呢？这里才入正题，是不是引子有些长？
解决方案
1，超时机制
2，服务限流
3，服务熔断
4，服务降级
超时机制
如果我们加入超时机制，例如2s，那么超过2s就会直接返回了，那么这样就在一定程度上可以抑制消费者资源耗尽的问题
服务限流
通过线程池+队列的方式，通过信号量的方式。比如商品评论比较慢，最大能同时处理10个线程，队列待处理5个，那么如果同时20个线程到达的话，其中就有5个线程被限流了，其中10个先被执行，另外5个在队列中
服务熔断
这个熔断可以理解为我们自己家里的电闸。
当依赖的服务有大量超时时，在让新的请求去访问根本没有意义，只会无畏的消耗现有资源，比如我们设置了超时时间为1s，如果短时间内有大量请求在1s内都得不到响应，就意味着这个服务出现了异常，此时就没有必要再让其他的请求去访问这个服务了，这个时候就应该使用熔断器避免资源浪费
服务降级
有服务熔断，必然要有服务降级。
所谓降级，就是当某个服务熔断之后，服务将不再被调用，此时客户端可以自己准备一个本地的fallback（回退）回调，返回一个缺省值。 例如：(备用接口/缓存/mock数据)，这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强，当然这也要看适合的业务场景
