2010-12-17 16 views
0

私は、別のネットワーク上に存在する多数のサーバーとのリモート通信用にRESTソリューションを設計しています。いくつかのコールは比較的短く、他のコールは数分かかることがあります。呼び出しは本質的に同期しているので、呼び出しが非同期の場合、クライアント(実際にはサーバー)は応答をポーリングする必要があります。ポーリングはパフォーマンスが低下し、ポーリング間隔の数分の一でエンドユーザーへの応答を遅らせるという点で、最適ではありません。私は同期呼び出しを使用するのが好きですが、ネットワーク接続が切断されても応答を得る手段はありません。非同期の場合、リモートサーバーはジョブIDを返すことができます。ジョブIDはポーリングすることができ、間欠的なネットワークの問題から生き残ります。再試行と冪等は重要な考慮事項です。HAアーキテクチャの非同期/ポーリングまたは同期

私は、どのアプローチをとるべきかに関するいくつかの推奨事項を探しています。また、リモートサーバーによって開始される呼び出しもあります。これらは、HA用のロードバランサを経由します。また、HA環境でのエンタプライズコミュニケーションのベストプラクティスを説明するいくつかの本の推奨事項にも興味があります。私はこのトピックをカバーするものを見つけることができないようです。

答えて

0

ネットワーク障害が発生した場合に「再接続」をサポートする同期システムを設計できます。再接続呼び出しは、クライアントが同じ呼び出しに「再接続」する方法です。サーバが切断と再接続の間にコールを完了した場合、戻り値は保存されており、再接続が発生すると直ちに返されます。再接続をサポートするには、呼び出しに識別子を割り当てる必要があります。識別子は、クライアントによってguidとして選択され、最初の呼び出しの一部としてサーバーに渡されます。次に、サーバーはこのguidを呼び出しに関連付けます。接続を切断して再接続すると、クライアントは同じguidを渡し、サーバーはこれを使用してクライアントを呼び出しに再接続します。上記のように保存された値は、おそらくプールからパージされるまでの生存期間が必要になります。どう思いますか?

+0

私は、ネットワーク接続の問題に耐えながら、同期の利点を持っているので、そのアプローチが好きです。私が見る唯一の欠点は、応答キャッシュです。問題の実績のあるエンタープライズパターンが存在することを期待していました。 – Andrew

+0

@Andrew - ネットワーク停止に耐えるように設計されたソリューションでは、応答キャッシュが必要になります。あなたは仕事をやり直さなければならないという意味でそれを破棄しない限り、ネットワークはダウンし、仕事は完了し、どこかに行く必要があります。 – killdash9

関連する問題