いくつかの会場では、複数のゲートウェイを使用してさまざまなアクティビティを実行していることに気付きました。たとえば、1つのゲートウェイは注文ルーティングに使用され、もう1つのゲートウェイは市場データにのみ使用されます。
これの利点は何ですか?
いくつかの会場では、複数のゲートウェイを使用してさまざまなアクティビティを実行していることに気付きました。たとえば、1つのゲートウェイは注文ルーティングに使用され、もう1つのゲートウェイは市場データにのみ使用されます。
これの利点は何ですか?
基本的に、2つの役割の要件はまったく異なり、2つの接続の処理を論理的に分離するのは簡単です。
市場データの接続は通常、トラフィックが非常に多く、主に一方向です。注文トラフィックがないため、ログ保持の必要性が大幅に減少します。市場データ接続に問題がある場合、それは大したことではありません。もう一度バックアップを開始して、取引を続けてください。ダウンタイムで見逃したものは、とにかく古い情報です。
オーダールーティング接続は、時間に敏感な双方向トラフィックです。後で監査する必要がある場合に備えて、ほとんどすべてをログに記録することをお勧めします。接続がダウンした場合は、復元するときに注文とプログラムの状態(注文の履行/キャンセルなど)を確認する必要がある場合があります。
私が取り組んだプロジェクトでは、MDコンポーネントとORコンポーネントがあります。2つの接続により、ハンドラーを2つのある程度独立したロジックのセットに分離できます。MDコンポーネントは、ORコンポーネントが参照する共通の場所に関連データを格納します。(この一般的な場所は、外部DBの場合もあれば、共有メモリの場合もあります。)MDコンポーネントにはログがほとんどまたはまったくなく、ORはすべてをログに記録します。
1つが失敗した場合、すべてがダウンした場合、とにかくすべてを1つにプッシュしたくないでしょう。第一に、それはあなたに頑健性を与えます、1つが失敗した場合、他の人は続けることができます。負荷のバランスをとることができます。一部のユーザーは1人に接続し、他のユーザーは別のユーザーに接続します。何かが失敗した場合、ユーザーを簡単に再ルーティングできます。私が働いている場所では、通常、すべてのゲートウェイがメッセージをダンプし、宛先のすべてのメッセージを読み取る単一のメッセージバスがあります。気まぐれではなく、必要な場合、または何かがバックアップに切り替わった場合に、可能な限り多くのゲートウェイを追加できる柔軟性があります。