57

高いスケーラビリティへのアプローチの 1 つは、ネットワーク負荷分散を使用して処理負荷を複数のサーバーに分割することです。

このアプローチが提示する課題の 1 つは、サーバーが状態を認識している場所、つまりユーザー状態を「セッション」に保存することです。

この問題に対する 1 つの解決策は、各ユーザーが 1 つのサーバーに割り当てられ、ユーザーの状態データがセッションの間、そのサーバーに排他的に含まれる「スティッキー セッション」(別名「セッション アフィニティ」) です。

「スティッキー セッション」アプローチの長所と短所は何ですか? あなたはそれを使っていますか？使っているなら満足していますか？

4

1 に答える 1

79

長所：

  • 簡単です。アプリの変更は必要ありません。
  • ローカル RAM キャッシュをより有効に活用します (たとえば、ユーザー プロファイルを一度検索してキャッシュし、同じユーザーからの次のアクセスで再利用できます)。

短所：

  • サーバーがダウンすると、セッションが失われます。(これは、セッション情報を Web サーバーにローカルに保存することの短所であることに注意してください。スティッキー セッション自体の短所ではありません)。セッションの内容がユーザー (下書きメールなど) またはサイト (ショッピング カートなど) にとって本当に重要な場合、サーバーの 1 つを失うことは非常に苦痛です。
  • ロードバランサーの「スティッキー」実装によっては、一部のサーバーと他のサーバーに不均等な負荷がかかる可能性があります
  • 新しいサーバーをオンラインで呼び出しても、すぐに新しいサーバーに多くの負荷がかかるわけではありません。スパイクに対処する動的負荷分散システムを使用している場合、持続性により、スパイクに迅速に対応する能力が低下する可能性があります。とはいえ、これはやや特殊なケースであり、実際には非常に大規模で洗練されたサイトにのみ適用されます.
  • ユーザー数が比較的少ないが、1 人のユーザーのトラフィックが 1 つのサーバーを圧倒する可能性がある場合 (例: SSL、AJAX、動的に生成された画像、動的圧縮などを使用した複雑なページ)、スティッキンはエンドユーザーの応答時間を損なう可能性があります。 1 人のユーザーの負荷をサーバー間で均等に分散します。多くの同時ユーザーがいる場合、すべてのサーバーが混雑するため、これは問題ではありません!

ただし、サーバー ローカル セッション状態を使用する必要がある場合は、スティッキー セッションを使用することをお勧めします。また、サーバー ローカル セッション状態を使用しない場合でも、キャッシュの使用に関してスティッキーには利点があります (上記を参照)。IP アドレスは 1 回のセッション中に変更される可能性があるため (有線ネットワークと無線ネットワークの間でラップトップをドッキングするなど)、ロード バランサーは (IP アドレスだけでなく) HTTP Cookie を参照してスティッキ性を判断できる必要があります。

さらに良いことに、Web サーバーでセッション状態をまったく使用しないでください。セッション状態を失うのが非常に苦痛な場合 (ショッピング カートなど)、それを中央データベースに保存し、古いセッションを定期的に消去します。セッション状態が重要でない場合 (ユーザー名/アバター URL など) は、Cookie に貼り付けてください。ただし、Cookie に大量のデータを押し込んでいないことを確認してください。

Rails の最近のバージョンでは、デフォルトで、上記の理由からセッション変数を Cookie に保存します。他の Web フレームワークには、「cookie に保存」および/または「DB に保存」オプションがある場合があります。

于 2009-10-15T06:51:13.130 に答える