10

セッション変数は通常、Web サーバーの RAM メモリに保持されます。

クラスターでは、クライアントによって行われた各要求は、異なるクラスター ノードによって処理されます。右？！

だから、この場合...

  • セッション変数はどうなりますか? それらはノードのRAMメモリに保存されていませんか?
  • セッション変数がない場合、または少なくともすべてのセッション変数がない場合、他のノードはどのようにリクエストを正しく処理しますか?
  • この問題は、Web サーバー (Apache、IIS) または言語ランタイム (PHP、ASP.NET、Ruby、JSP) によって処理されますか?

編集: Classic ASPの解決策はありますか?

4

8 に答える 8

7

@yogmanの答えを拡張するには。

Memcachedは純粋に素晴らしいです! これは、高性能の分散オブジェクト キャッシュです。

分散型とは言いましたが、基本的には、予備/アイドル サーバーの 1 つで 1 つのインスタンスを開始するだけで、IP、ポート、および使用する RAM の量を構成すれば完了です。

memcached -d -u www -m 2048 -l 10.0.0.8 -p 11211

(memcached をデーモン モードで実行します。ユーザー www として、2048 MB (2 GB) の RAM を IP 10.0.0.8、ポート 11211 で実行します。)

それ以降、memcached にデータを要求し、データがまだキャッシュされていない場合は、元のソースから取得して memcached に保存します。あなたはキャッシュの基本に精通していると思います。

クラスター環境では、memcached をクラスターにリンクし、ノード間でキャッシュを複製できます。Memcached は Linux、Unix、および Windows で実行され、RAM に余裕がある場所ならどこでも起動して、リソースを使い始めます。

memcached の API は、一般に利用可能になるはずです。Perl、Java、PHPしか知らないので、そうすべきだと言っています。しかし、たとえばPythonでは、人々もそれを活用する手段を持っていると確信しています。ポインターが必要な場合に備えて、memcached wikiがあります。または、私が熱狂しすぎていた場合は、コメントでお知らせください。;)

于 2008-10-22T01:11:01.017 に答える
6

セッション状態を ASP.NET に保存するには、3 つの方法があります。1 つ目は処理中で、変数がメモリに格納されます。2 つ目は、web.config ファイルに以下を記述して、セッション状態サービスを使用することです。

<sessionState
    mode="StateServer"
    stateConnectionString="tcpip=127.0.0.1:42424"
    sqlConnectionString="data source=127.0.0.1;user id=sa;password="
    cookieless="false"
    timeout="20" />

stateConnectionString 属性でわかるように、セッション状態サービスは別のコンピューターに配置できます。

3 番目のオプションは、一元化された SQL データベースを使用することです。これを行うには、web.config に次のように記述します。

<sessionState
    mode="SQLServer"
    stateConnectionString="tcpip=127.0.0.1:42424"
    sqlConnectionString=
     "data source=SERVERHAME;user id=sa;password="
    cookieless="false"
    timeout="20"
/>

これらすべてのオプションの詳細については、http ://www.ondotnet.com/pub/a/dotnet/2003/03/24/sessionstate.html に記載されています。

于 2008-10-22T00:03:29.657 に答える
4

Linux マシンを入手して、 http://www.danga.com/memcachedをセットアップします。その速度は、他のアプローチと比較して無敵です。(例: Cookie、フォーム隠し変数、データベース)

于 2008-10-22T00:06:11.320 に答える
3

Hazelcastを使用すると、Hazelcast分散マップを使用してクラスター全体でセッションを保存および共有するか、HazelcastWebappManagerにすべてを任せることができます。詳細については、ドキュメントを確認してください。Hazelcastは、Java向けの分散/パーティション化された、超軽量で簡単な無料のデータ分散ソリューションです。

よろしく、

-タリップ

http://www.hazelcast.com

于 2008-10-29T17:45:30.593 に答える
3

あらゆる種類のものと同様に、「場合による」。

さまざまなソリューションとアプローチがあります。

前述のように、セッション状態 (データベース、memcached、共有ファイル システムなど) の集中ストアという概念があります。

また、クラスター内のすべてのマシンでローカル データを利用できるようにする、クラスター全体のキャッシュ システムも利用できます。概念的には集中セッション状態ストアに似ていますが、このデータは永続的ではありません。むしろ、個々のノード内に存在し、プロバイダーが提供する何らかのメカニズムを使用して複製されます。

もう 1 つの方法は、サーバーのピニングです。クライアントが初めてクラスターにヒットすると、何らかのメカニズム (通常はクラスターの前にあるロード バランサー) がクライアントを特定のサーバーにピン留めします。典型的なクライアントの寿命では、そのクライアントは 1 台のマシンですべての時間を費やします。

フェールオーバー メカニズムでは、クラスタの各マシンが別のマシンとペアになるため、セッションの変更はペアになったマシンと共有されます。固定されたクライアントのマシンで問題が発生した場合、クライアントは別のマシンにヒットします。この時点で、おそらく Cookie が原因で、新しいマシンはそれがクライアントの元のマシンではないことを認識し、元のマシンとクライアント セッション データのペアリングされたマシンの両方に ping を実行します。

その時点で、クライアントは新しいマシンに固定されている可能性があります。

プラットフォームが異なれば、セッション状態がまったくないなど、さまざまな方法でそれが行われます。

于 2008-10-22T00:23:52.203 に答える
1

従来の ASP の負荷分散を実現するには、ユーザー固有の値をデータベースに格納し、次のように URL で参照の一意の IDを渡すことができます。

各レコードに一意の IDを生成するデータベース内のセッション テーブルを維持します。セッション固有のデータを初めて保存する場合は、セッション テーブルにレコードを生成し、セッション値をそこに保存します。新しいセッション レコードの一意の ID を取得し、Web アプリケーションのすべてのリンクを書き直して、クエリ文字列の一部として一意の ID を送信します。

セッション データが必要な後続のすべてのページで、クエリ文字列で渡された一意の ID を使用してセッション テーブルをクエリします。

例：

あなたの Web サイトには、Login.asp、welcome.asp、taskList.asp、newtask.asp の 4 つのページがあると考えてください。

ユーザーがlogin.aspページを使用してログインすると、ユーザーを検証した後、セッションテーブルにレコードを作成し、必要なセッション固有の値を保存します(この例ではユーザーのログイン日時としましょう)。新しいセッション レコードの一意の ID を取得します (一意の ID がabcdであるとします)。

以下のように、Web サイトのすべてのリンクに一意の ID を追加します。

  • Welcome.asp?sessionId=abcd
  • tasklist.asp?sessionId=abcd
  • newtask.asp?sessionId=abcd

上記の Web ページのいずれかでユーザーのログイン日時を表示したい場合は、sessionID パラメーター (この場合はabcd ) を使用してセッション テーブルをクエリし、ユーザーに表示するだけです。

セッションを識別する一意の値は URL の一部であるため、ユーザーにサービスを提供する Web サーバーはいずれも正しいログイン日時の値を表示できます。

お役に立てれば。

于 2008-11-11T14:47:38.730 に答える
0

ウィルが言ったように、ほとんどの負荷分散アプローチは、同じクライアントからの今後のリクエストを分散する方法である種の粘着性を使用します。つまり、実際のサーバーがダウンしない限り、一意のクライアントが同じサーバーにヒットします。

これにより、セッション データの配布の必要性が最小限に抑えられます。つまり、サーバーに最終的な障害が発生した場合にのみ、クライアントはセッションを失うことになります。アプリによっては、これは多かれ少なかれ重要です。ほとんどの場合、これは大きな問題ではありません。

ほとんどのブラウザは実際のルックアップをキャッシュし、最初に受信したレコードである AFAIK にアクセスし続けるため、負荷分散の最も単純な方法 (DNS ルックアップのラウンド ルービン) でさえ、ある種のスティッキーを行います。

通常、セッションデータを担当するのはランタイムです。たとえば、PHP では、データをデータベースに保持できる独自のセッション ハンドラを定義できます。デフォルトでは、PHP はセッションデータをファイルに保存します。セッション データを共有するために、これらのファイルを SAN または同等のもので共有できる場合があります。これは私が持っていた単なる理論でしたが、セッションを失うことは重要ではなく、その単一障害点を望んでいないと判断したため、テストすることはありませんでした.

于 2008-11-11T13:01:21.627 に答える
0

ASP.NET では、クラスター内のすべての Web サーバーに共通の SQL Server データベースにセッション データを永続化できます。

(サイトの web.config で) 構成すると、フレームワークがすべての永続化を処理し、通常どおりセッション データにアクセスできます。

于 2008-10-22T00:02:02.653 に答える