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