3

このサービスはremote session pool. 他のサービスと連携するためのセッションを依頼する必要があります。ほとんどの場合、このプールには利用可能なセッションがあるため、15 ミリ秒で応答があります。ただし、場合によっては、オンデマンドでセッションを作成する必要があり、作成に最大 800 ミリ秒かかります。

この状況に対処するには、次の 2 つの選択肢があります。

  1. 15 ミリ秒のタイムアウトを設定し、800 ミリ秒まで指数関数的にバックオフする再試行ポリシーを実装します。このサービスは、接続しているかどうかに関係なく、必要なセッションを作成します。

  2. 800 ミリ秒のタイムアウトを設定し、セッションが利用可能になるまでサービスへの接続を維持するには。

どちらの場合も、800 ミリ秒後にセッションが開始されるという保証はありません。

質問は次のとおりです。各オプションの長所と短所はどれですか?

4

1 に答える 1

1

1. 15 ミリ秒のタイムアウトを設定し、800 ミリ秒まで指数関数的にバックオフする再試行ポリシーを実装します。このサービスは、接続しているかどうかに関係なく、必要なセッションを作成します。

プロ

  1. セッションがすぐに利用できないことを検出します。これを約 1 秒待つ必要はありません。
  2. セッションを再度リクエストするか、別の方法で実行するかはクライアント次第です。さまざまなユースケースに柔軟に対応できます。
  3. フォールバック戦略が実行されるたびに、15 ミリ秒を超えるセッションのレポートを待機するという望ましくないイベントを区別できます。これは、セッション プールの異常な動作の検出に役立ちます。

短所

  1. フォールバック動作のため、コードはより複雑になります。
  2. タイムアウトが異なるため、複数のパラメーター。

2. 800 ミリ秒のタイムアウトを設定し、セッションが利用可能になるまでサービスへの接続を維持するには。

プロ

  1. シンプルでわかりやすい実装
  2. 簡単なパラメータ化

短所

  1. セッション プールからのセッション作成イベントの遅延に気付くことはありません。これは、トレースと診断にとって重要です。この単純なアプローチでは、セッション プールの問題を隠すことができます。
  2. さまざまなクライアントのユース ケースに対する柔軟な実装ではありません。

-

このユースケースに適したソリューションが必要かどうか、またはこのアプローチがさまざまなクライアントとユースケースに使用されるかどうかが決定要因だと思います。

PS: さまざまなクライアント向けのソリューションを作成する必要がある場合は、次のようなより複雑なプロトコルを作成する価値があります。

// just takes a session if available, no more than 15msec delay expected
get_session(...)  : session 

// if not available, creates one
get_session_or_create(...) : session 

available_sessions(...) : int

//  between 0 and 1, the proportion of available sessions
availability(...) : double  

...

使い方はお客様次第です。

また、セッション作成の遅延の差異に応じて、タイムアウト パラメータを安全な % だけ大きくします。

于 2013-10-16T00:08:01.537 に答える