高速アプリケーションの場合、セッションを保存するための connect-mongodb および connect-redis ミドルウェアがあることを確認しましたが、なぜそれが必要なのかわかりません。デフォルトのメモリ内セッション ストレージの何が問題なのですか? 複数のマシン間でセッションを同期する必要がある大規模なアプリケーション向けですか?
また、誰でも最速のセッション ストアのベンチマーク/ヒントを提供できますか? 私の推測では、Redis の方がキー/バリュー ストアが単純なためです。
1 に答える
12
セッション データをデータベース (MongoDB、Redis など) に保存する唯一の理由は、Node プロセス全体で使用でき、障害が発生しても耐久性があるためです。スケールアウト アーキテクチャでは、特定のユーザーが接続するサーバーに関係なくすべてが機能し、状態を失うことなくサーバーを起動および停止できるように、ステートレス サーバーを使用することが強く望まれます。
つまり、受信リクエストを処理するロード バランサーの背後に 10 台のサーバーがあるとします。ユーザー 1 は、サーバー A が処理してログインする要求を行います。ユーザーがログインしたという事実を保存する必要があるため、これをセッションに保存します。サーバー A は別の要求でビジーであるため、次の要求はサーバー C にルーティングされます。サーバー C がユーザーが既にログインしていることを知るには、セッション データが必要です。では、サーバー A によって保存されたセッション データにアクセスするにはどうすればよいでしょうか。
1 つの方法は、各リクエストで送信されるクライアント側の Cookie にデータを保存することですが、これはあまり安全ではありません。もう 1 つの方法は、ノード サーバー間で状態を同期しようとすることです。これは実行できますが、コストがかかり、エラーが発生しやすい傾向があります。最も簡単な方法は、セッション ID を Cookie に保存してから、実際のセッション データをデータベースに保存することです。各ノード サーバーは同じデータベースにアクセスできるため、セッション データを検索できます。このようにして、Node サーバーを簡単にスケールインおよびスケールアウトし、サーバーに障害が発生したときにデータを失うことなく負荷を分散できます。
パフォーマンスに関しては、メモリ内ストアが最も高速になります (ただし、上記の欠点があります)。Redis が次に速く、MongoDB が最も遅くなります (通常、Redis の約 4 倍遅くなります)。どちらも、大多数の Web サイトにとって十分に高速であることを覚えておいてください。
于 2012-05-06T02:05:59.240 に答える