Java のダウングレードされたコンポーネント Hystrix の機能は何ですか?

#1. インタビュアー: Hystrix の機能を簡単に紹介してもらえますか?

問題分析: Hystrix の機能を理解すると同時に、アーキテクチャ設計の観点から Hystrix の優れた設計コンセプトからインスピレーションを得ます。

回答: プロジェクトで使用しました。Hystrix の保護により、システムは長期間にわたって高可用性状態に維持できます。一般的に使用される機能は次のとおりです:

1.1、フェイルファスト (フェイルファスト)

Hystrix 設計は、フェイルファスト (フェイルファスト) および高速リカバリ メカニズムを提供します。

ヒント: フェイルファスト メカニズムを以前に理解したことがあったのか、それとも Java の基礎について面接していたときかわかりませんが、HashMap のイテレータはフェイルファスト、**フェイル クイック ( failed— fast)** は Java コレクションのメカニズムです。反復子を使用してコレクション オブジェクトを走査するときに、走査プロセス中にコレクション オブジェクトの内容が変更 (追加、削除、変更) されると、同時変更例外が発生します。投げられた。

私が HashMap を初めて学んだとき、フェイルファストについてはあまり知りませんでした。ファスト フェイルは、Java の非スレッドセーフ コレクションの同時操作を防ぐために Java コレクション クラスでのみ使用されるものだと思っていました。 Hystrix を使用すると、高速障害メカニズムをシステム アーキテクチャ設計に適用して、時間内に処理できない要求をすぐに失敗 (フェイルファスト) して、キューに入れる代わりにシステム負荷を軽減できることがわかりました。

1.2. Fallback のグレースフルデグラデーションの仕組み

Fallback とは文字通り、「Fall に遭遇したら元に戻る」という意味で、Fallback の仕組みを知り、早速プロジェクトで活用してみました。

実際の例を見てください:

 @Override
    @Degrade(key = "getOrderByParamFromES", fallBackMethod = "getOrderByParamFromMysql")
    public OrderResult getOrderByParamFromES(OrderSearchParam param) {
        //走ES查询
        ......
        return OrderResult;
    }
 		//fallBack后调用getOrderByParamFromMysql方法
 		public OrderResult getOrderByParamFromMysql(OrderSearchParam param) {
        //走mysql查询
        ......
        return OrderResult;
    }

コードの説明:

fallBackMethod = "getOrderByParamFromMysql"

は ES クエリの後にあります失敗すると、システムは getOrderByParamFromMysql メソッドを自動的にダウングレードし、mysql クエリを使用します。通常の状況では、失敗しない限り getOrderByParamFromMysql は呼び出されません。

1.3. スレッド/セマフォ分離メカニズム

スレッド分離:

リクエストは、独自のキーに従って、対応するスレッド プール内のスレッド実行を取得し、動的に設定します。スレッド プール パラメーター: これにより、さまざまなリクエストが自然に分離され、非同期性がサポートされてインターフェイスのパフォーマンスが向上します。異なるリクエストは直接的な影響を与えません。たとえば、service1 リクエストは遅いですが、service2 と service3 は通常どおり動作します。欠点は、スレッドの切り替えがパフォーマンスに影響することです。

セマフォの分離:

Service1、service2、および service3 は 1 つのリクエストでアクセスされます。service1 リクエストがタイムアウトすると、セマフォ全体が解放されず、他のリクエストは受け入れられなくなります。

レイテンシが小さいリクエスト (キャッシュへのアクセスやデータベースへのローカル アクセスなど) の場合、スレッド プールによって生じるオーバーヘッドが非常に高くなります。ノンブロッキング セマフォ (タイムアウトはサポートされていません)) に依存するサービスの分離を実現します。しかし、ほとんどの場合、Netflix はスレッド プールを使用して依存サービスを分離することを好みます。これは、スレッド プールによって生じる追加のオーバーヘッドが許容範囲内であり、タイムアウトを含むすべての機能をサポートできるためです。

2. インタビュアー: 先ほどスレッド分離について触れましたが、実際の使用ではタイムアウトスレッド中断スイッチをオンにしていますか?

問題分析: 実際の使用経験に基づいて、スレッド自体の特性に従ってスレッドがタイムアウトになり、時間内に中断されないとスレッド リソースが無駄になります。

回答: 通常の状況では、スレッド リソースを時間内に解放するためにタイムアウト割り込みスイッチをオンにします。

hystrix.command.default.execution.isolation.thread.interruptOnTimeout = true によって設定されます。

ただし、データベース コマンドを作成している場合、またはキー ログ コマンドを記録している場合、コマンドの実行を完了する必要がある場合は、タイムアウト割り込みをオフにする必要があります。

(面接官は、私に Hystrix メンテナンスの経験があると信じて、満足そうにうなずきました)

3. 面接官: スレッド プールのサイズはどのように見積もりましたか?

回答: スレッド プールのサイズを正しく設定するには、CPU の数、メモリ サイズ、展開されたシステムのタスク タイプ (コンピューティング集中型、IO 集中型など) を分析する必要があります。コンピューティング集中型のタスクの場合、通常、スレッド プールのサイズと同様の数の CPU によって最適な使用率を実現できます。IO 集中型のタスクの場合、スレッド プールの最適なサイズの計算式は次のとおりです: スレッド プール サイズ = CPU 数 * ( 1タスク待ち時間/タスク処理時間)。

詳細な分析

Hystrix の歴史

Hystrix は、2011 年に Netflix API チームによって開始されたプロジェクトに由来します。 2012 年、Hystrix は進化と成熟を続け、Netflix 内の多くのチームがそれを採用しました。現在、Netflix では、Hystrix を介して、スレッド分離された数百億件の呼び出しとセマフォ分離された数千億件の呼び出しが毎日実行されています。これにより、稼働時間と回復力が大幅に向上します。

同時アクセスが多い場合、システムが依存するサービスの安定性はシステムに大きな影響を与えます。ネットワーク接続が遅い、リソースが突然ビジー状態になる、一時的に利用できなくなるなど、制御できない要因が多数依存します。オフラインで待機します。安定した信頼性の高い分散システムを構築したい場合は、このようなフォールトトレラントな方法が必要です。

Hystrix的主要功能特性

熔断器机制：熔断器可以理解成保险丝，项目里使用Hystrix Command，当 Hystrix Command请求后，如果服务失败数量超过一定比例(比如默认50%)，断路器自动熔断，该服务将进入熔断状态，后续请求都会进入fallback。

降级机制：通过fallbackMethod注解，当请求后端服务出现异常的时候, 为了避免影响到其他业务逻辑，可以使用fallback方法指定的方法快速返回，或启用“备胎方案”。

环境隔离：包括线程隔离和信号量隔离。

cache：Hystrix支持将一个请求结果缓存起来，下一个具有相同key的请求将直接从缓存中取出结果，减少请求开销。

Hystrix Demo

通过一个demo快速理解Hystrix fallback 的使用

@Service
public class OrderQueryService {
     /**
     * 订单查询接口
     */
    @HystrixCommand(fallbackMethod = "queryOrderBack")
    public List<Order> queryOrderFromRedis(String userId) {
      // todo  reids查询逻辑
      return orderlist;
    }
     /**
     * 订单查询接口失败降级方案
     */
    @SuppressWarnings("unused")
    private String queryOrderBack(String userId) {
      // todo  如，走ES查询逻辑  或者 直接提示用户“请稍后再试”
      // todo 通知维护人员处理故障
      return "";
    }
}

代码解释:

程序正常时，查询订单服务是走queryOrderFromRedis方法的逻辑，当queryOrderFromRedis方法抛出异常，根据设定的异常比例，或者指定哪个异常，达到阈值触法fallback开关，程序切换到queryOrderBack，设置程序走ES查询逻辑 或者 直接提示用户“请稍后再试”，根据业务自行设置。

哪些情况下会触发fallback？

FAILURE：任意RuntimeException异常都可以激活fallback。

THREAD_POOL_REJECTED：并发执行的任务数超过线程池和队列之和时，也就是Hystrix的线程隔离机制。

SEMAPHORE_REJECTED：类似 THREAD_POOL_REJECTED ，当服务的并发数大于信号量阈值时将进入fallback。比如配置程序执行并发数不能大于3，由于信号量隔离下无论调用哪种命令执行方法，Hystrix都不会创建新线程执行run()/construct()，所以调用程序需要自己创建多个线程来模拟并发调用execute()，最后看到一旦并发线程>3，后续请求都进入fallback。

SHORT_CIRCUITED：在一定时间内，用户请求超过一定的比例失败时，如超时，异常，线程并发达到限定最大值等，断路器都会打开；短路器打开后所有请求直接走fallback，可以通过。circuitBreakerErrorThresholdPercentage方法设置百分比，默认是50。

TIMEOUT：即超时请求。

附录：Hystrix策略配置

/* --------------统计相关------------------*/ 
// 统计滚动的时间窗口,默认:5000毫秒（取自circuitBreakerSleepWindowInMilliseconds）   
private final HystrixProperty metricsRollingStatisticalWindowInMilliseconds;   
// 统计窗口的Buckets的数量,默认:10个,每秒一个Buckets统计   
private final HystrixProperty metricsRollingStatisticalWindowBuckets; // number of buckets in the statisticalWindow   
// 是否开启监控统计功能,默认:true   
private final HystrixProperty metricsRollingPercentileEnabled;   
/* --------------熔断器相关------------------*/ 
// 熔断器在整个统计时间内是否开启的阀值，默认20。也就是在metricsRollingStatisticalWindowInMilliseconds（默认10s）内至少请求20次，熔断器才发挥起作用   
private final HystrixProperty circuitBreakerRequestVolumeThreshold;   
// 熔断时间窗口，默认:5秒.熔断器中断请求5秒后会进入半打开状态,放下一个请求进来重试，如果该请求成功就关闭熔断器，否则继续等待一个熔断时间窗口
private final HystrixProperty circuitBreakerSleepWindowInMilliseconds;   
//是否启用熔断器,默认true. 启动   
private final HystrixProperty circuitBreakerEnabled;   
//默认:50%。当出错率超过50%后熔断器启动
private final HystrixProperty circuitBreakerErrorThresholdPercentage;  
//是否强制开启熔断器阻断所有请求,默认:false,不开启。置为true时，所有请求都将被拒绝，直接到fallback 
private final HystrixProperty circuitBreakerForceOpen;   
//是否允许熔断器忽略错误,默认false, 不开启   
private final HystrixProperty circuitBreakerForceClosed; 
/* --------------信号量相关------------------*/ 
//使用信号量隔离时，命令调用最大的并发数,默认:10   
private final HystrixProperty executionIsolationSemaphoreMaxConcurrentRequests;   
//使用信号量隔离时，命令fallback(降级)调用最大的并发数,默认:10   
private final HystrixProperty fallbackIsolationSemaphoreMaxConcurrentRequests; 
/* --------------其他------------------*/ 
//使用命令调用隔离方式,默认:采用线程隔离,ExecutionIsolationStrategy.THREAD   
private final HystrixProperty executionIsolationStrategy;   
//使用线程隔离时，调用超时时间，默认:1秒   
private final HystrixProperty executionIsolationThreadTimeoutInMilliseconds;   
//线程池的key,用于决定命令在哪个线程池执行   
private final HystrixProperty executionIsolationThreadPoolKeyOverride;   
//是否开启fallback降级策略 默认:true   
private final HystrixProperty fallbackEnabled;   
// 使用线程隔离时，是否对命令执行超时的线程调用中断（Thread.interrupt()）操作.默认:true   
private final HystrixProperty executionIsolationThreadInterruptOnTimeout; 
// 是否开启请求日志,默认:true   
private final HystrixProperty requestLogEnabled;   
//是否开启请求缓存,默认:true   
private final HystrixProperty requestCacheEnabled; // Whether request caching is enabled
//请求合并是允许的最大请求数,默认: Integer.MAX_VALUE   
private final HystrixProperty maxRequestsInBatch;   
//批处理过程中每个命令延迟的时间,默认:10毫秒   
private final HystrixProperty timerDelayInMilliseconds;   
//批处理过程中是否开启请求缓存,默认:开启   
private final HystrixProperty requestCacheEnabled; 
/* 配置线程池大小,默认值10个 */ 
private final HystrixProperty corePoolSize; 
/* 配置线程值等待队列长度,默认值:-1 建议值:-1表示不等待直接拒绝,测试表明线程池使用直接决绝策略+ 合适大小的非回缩线程池效率最高.所以不建议修改此值。 当使用非回缩线程池时，queueSizeRejectionThreshold,keepAliveTimeMinutes 参数无效 */
private final HystrixProperty maxQueueSize;

其他常用限流降级组件

Sentinel：阿里巴巴集团内部基础技术模块，覆盖了所有的核心场景。Sentinel 也因此积累了大量的流量归整场景以及生产实践。2018 年，Sentinel 开源，并持续演进。

Resilience4j：也是一个轻量级的容错组件，其灵感来自于 Hystrix，但主要为 Java 8 和函数式编程所设计。轻量级体现在其只用 Vavr库（前身是 Javaslang），没有任何外部依赖。而 Hystrix 依赖了 Archaius ，Archaius 本身又依赖很多第三方包，例如 Guava、Apache Commons Configuration 等。

Sentinel 与 Hystrix resilience4j 对比

以上がJava のダウングレードされたコンポーネント Hystrix の機能は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。