Hystrix は、複雑な分散システムのレイテンシとフォールト トレランスのための Netflix API であり、スレッドの分離にバルクヘッド パターン技術を使用しています。誰か詳しく教えてください。
3 に答える
全般的
一般に、バルクヘッド パターンの目的は、システムの一部で障害が発生してシステム全体が停止するのを回避することです。この用語は、船全体が浸水する単一の船体の破損を避けるために、船が別々の水密コンパートメントに分割されている船に由来します。1 つの隔壁だけが浸水します。
隔壁パターンの実装は、システムを保護したい障害の種類に応じて、さまざまな形を取ることができます。この回答では、Hystrix が処理する障害の種類についてのみ説明します。
隔壁のパターンはRelease It!という本で有名になったと思います。マイケル・T・ナイガード著。
Hystrix が解決すること
Hystrix でのバルクヘッドの実装は、コンポーネントへの同時呼び出しの数を制限します。このようにして、コンポーネントからの応答を待っているリソース (通常はスレッド) の数が制限されます。
A、B、およびCの3 つの異なるコンポーネントを使用するリクエスト ベースのマルチスレッド アプリケーション (たとえば、典型的な Web アプリケーション) があるとします。コンポーネントCへのリクエストがハングし始めると、最終的にすべてのリクエスト処理スレッドがCからの応答を待ってハングします。これにより、アプリケーションが完全に応答しなくなります。Cへのリクエストの処理が遅い場合、負荷が十分に高い場合、同様の問題が発生します。
バルクヘッド パターンの Hystrix の実装は、コンポーネントへの同時呼び出しの数を制限し、この場合、アプリケーションを保存します。30 のリクエスト処理スレッドがあり、Cへの同時呼び出しは 10 に制限されているとします。Cを呼び出すと、最大で 10 個のリクエスト処理スレッドがハングする可能性があります。残りの 20 個のスレッドは引き続きリクエストを処理し、コンポーネントAおよびBを使用できます。
ハイストリックスのアプローチ
Hystrix には、スレッド分離とセマフォ分離という、バルクヘッドに対する 2 つの異なるアプローチがあります。
スレッド分離
標準的なアプローチは、コンポーネントCへのすべての要求を、スレッド数が固定され、要求キューがない (または小さい) 別のスレッド プールに渡すことです。
セマフォ分離
もう 1 つの方法は、すべての呼び出し元がCへの要求の前に (タイムアウト 0 で) パーミットを取得するようにすることです。セマフォからパーミットを取得できない場合、Cへの呼び出しはパススルーされません。
違い
スレッド プール アプローチの利点は、Cに渡される要求をタイムアウトできることです。これは、セマフォを使用する場合には不可能です。