一般に、バルクヘッドパターンの目的は、システムの一部の障害を回避してシステム全体をダウンさせることです。 この用語は、船が船全体を洪水させるために単一の船体の違反を避けるために別々の水密区画に分割されている船から来ています。

隔壁パターンの実装は、システムをどのような障害から保護するかによって、さまざまな形式を取ることができます。 この回答では、hystrixが処理する障害の種類についてのみ説明します。私はバルクヘッドのパターンは、それを解放する本によって普及したと思います！ マイケルT.Nygardによって。Hystrixが解決するものhystrixのバルクヘッド実装は、コンポーネントへの同時呼び出しの数を制限します。 このようにして、コンポーネントからの応答を待機しているリソース(通常はスレッド)の数が制限されます。

a、B、Cの三つの異なるコンポーネントを使用する要求ベースのマルチスレッドアプリケーション(たとえば、一般的なwebアプリケーション)があるとします。 コンポーネントCへの要求がハングし始めると、最終的にはすべての要求処理スレッドがCからの応答を待ってハングします。 Cへの要求がゆっくりと処理される場合、負荷が十分に高い場合にも同様の問題があります。

hystrixのbulkheadパターンの実装は、コンポーネントへの同時呼び出しの数を制限し、この場合はアプリケーションを保存していました。 要求処理スレッドが30個あり、Cへの同時呼び出しが10個に制限されていると仮定します。 その後、Cを呼び出すときに最大で10個の要求処理スレッドがハングすることができますが、他の20個のスレッドは依然として要求を処理し、コンポーネ

Thread Isolation

標準的なアプローチは、コンポーネントCへのすべての要求を、スレッド数が固定され、要求キューがない（または小さい）別のスレッドプールに引き渡すことです。

セマフォ分離

もう一つのアプローチは、すべての呼び出し元がCへの要求の前に（タイムアウト0で）許可を取得することです。 セマフォから許可を取得できない場合、Cへの呼び出しは渡されません。

Differences

スレッドプールアプローチの利点は、Cに渡される要求がタイムアウトできることです。