2

負荷分散された n 層システム用の DB 接続マネージャーを設計するための最良のアプローチについて疑問に思っています。

従来の n 層は次のようになります。

Client -> BusinessServer -> DBServer

私が見ている負荷分散ソリューションは、次のようになります。

                    +--> ...            +--+
                    +--> BusinessServer +--+--> SessionServer --+
Client -> Gateway --+--> BusinessServer +--|                    +--> DBServer
                    +--> BusinessServer +--+--------------------+
                    +--> ...            +--+

図のように、ビジネス サーバー コンポーネントは複数のインスタンスを介して負荷分散されており、ハードウェア ゲートウェイがそれらの間で負荷を分散しています。

セッション サーバーは、重複してはならない状態を管理するため、おそらく負荷分散アレイの外に配置する必要があります。

これまでの設計に重大なエラーがなければ、DB 接続管理を実装する最良の方法は何ですか?

私はいくつかのオプションを考え出しましたが、私が気付いていない他のオプションがあるかもしれません:

  1. DBServer と他のコンポーネントの間に新しい Broker コンポーネントを導入し、DB 接続を処理させます。

    • 利点は、すべての接続を 1 つのポイントから管理できることです。これは非常に便利です。
    • 欠点は、システムに「単一障害点」が追加されることです。他のコンポーネントは、何らかの方法で DB に関係するすべての要求に対してそれを通過する必要があり、これもボトルネックになります。

  2. DB 接続管理を BusinessServer および SessionServer コンポーネントに移動し、それぞれが独自の DB 接続を処理できるようにします。

    • 利点は、追加の「単一障害点」またはボトルネック コンポーネントがないことです。
    • 欠点は、DBServer 自体が提供できるもの以外に、競合やデッドロックの可能性を制御できないことです。

他に何ができますか？

FWIW: テクノロジは .NET ですが、ベンダー固有のスタックは使用されていません (たとえば、WCF、MSMQ などはありません)。

4

1 に答える 1

0

最終的には、質問で述べた 2 つのハイブリッドのデザインを採用しました。Broker と SessionServer を動的コンポーネントにしました。これらはそれぞれ、BusinessServer とインプロセスまたはアウトオブプロセスで実行するように構成できるため、考えられるすべての組み合わせをカバーできます。

本質的に、私はシステムをカスタマイズ可能にするためにもう少し作業を行うことを選択したので、ケースバイケースで最善のアプローチを決定することができます.

于 2010-04-19T13:07:50.950 に答える