回答:
一般に、隔壁パターンの目的は、システムの一部で障害を回避してシステム全体を停止させることです。この用語は、1つの船体の違反が船全体を氾濫させるのを避けるために、船が別々の水密区画に分割されている船から来ています。1つの隔壁のみを水浸しにします。
隔壁パターンの実装は、システムを保護する障害の種類に応じて、さまざまな形をとることができます。この回答では、Hystrixが処理する障害のタイプについてのみ説明します。
バルクヘッドのパターンは、Release It！マイケル・T・ナイガード
Hystrixのバルクヘッド実装は、コンポーネントへの同時呼び出しの数を制限します。このようにして、コンポーネントからの応答を待機しているリソース（通常はスレッド）の数が制限されます。
A、B、およびCの 3つの異なるコンポーネントを使用するリクエストベースのマルチスレッドアプリケーション（たとえば、一般的なWebアプリケーション）があるとします。コンポーネントCへの要求がハングし始めると、最終的にはすべての要求処理スレッドがCからの応答を待機してハングします。これにより、アプリケーションは完全に応答しなくなります。Cへのリクエストの処理が遅い場合、負荷が十分に高いと同様の問題が発生します。
Hystrixの隔壁パターンの実装は、コンポーネントへの同時呼び出しの数を制限し、この場合、アプリケーションを節約します。30のリクエスト処理スレッドがあり、Cへの同時呼び出しは10に制限されていると仮定します。Cを呼び出すと、最大10個の要求処理スレッドがハングする可能性があり、他の20個のスレッドは要求を処理してコンポーネントAおよびBを使用できます。
Hystrix 'には、隔壁への2つの異なるアプローチ、スレッド分離とセマフォ分離があります。
標準的なアプローチは、コンポーネントCへのすべてのリクエストを、固定数のスレッドを持ち、リクエストキューがない（または小さい）個別のスレッドプールに渡すことです。
もう1つの方法は、Cへの要求の前に、すべての呼び出し元に許可（タイムアウトなし）を取得させることです。セマフォからパーミットを取得できない場合、Cの呼び出しはパススルーされません。
スレッドプールアプローチの利点は、Cに渡される要求がタイムアウトになる可能性があることです。これは、セマフォを使用する場合は不可能です。
以下は、Netflix Hystrixから着想を得たResilience4jのバルクヘッドの実行時の説明の良い例です。
以下の設定例は、使用法をいくらか明確にするかもしれません。
構成例：同時に最大5つの同時呼び出しを許可します。インプロセス5の同時実行の1つが終了するまで、または最大2秒まで、他の呼び出しを待機し続けます。
システムが消費できる以上の負荷をシステムに負担させることはありません。着信負荷が消費よりも大きい場合は、適切な時間待機するか、タイムアウトして代替パスを探します。