Appバックエンドセッション共有

は、nignxリクエストにより転送する、異なるアプリケーションモジュールにおいて、

を介してユーザがログイン検証を通過したか否かを判断する必要がある.

appの移動端にはクッキーがなく、sessionメカニズム

session外付け方式で解決し、redisでsessionを統一的に管理し、redisでsession

をシミュレートする

モバイル側のセッションはいずれも無状態であり、セッションを作成しない.我々はユーザー登録時にtoken(セッション)を生成する.tokenはredis設定タイムアウトがあり、ユーザーは要求するたびにtokenをサービス側に持って検査を行い、tokenは唯一のユーザー

を代表する.

Webバックエンドセッション

Webサイトに負荷分散を使用した後、直面しなければならない重要な問題はSession処理であり、サーバを使用してSessionを保存することは負荷分散を行う際にSession

を考慮する必要がある.

ユーザが負荷分散エージェントによってバックエンドサーバAに初めてアクセスしてログインすると、サーバAにはユーザのログイン情報が保持される.ユーザが再び要求を送信すると、負荷分散ポリシーに従ってバックエンドの異なるサーバ、例えばサーバBにエージェントされる可能性があり、このサーバBにはユーザのログイン情報がないため、ユーザが再ログインする必要がある.これはユーザにとって耐えられない

である.

一般的にセッション保持/sessionレプリケーション/session共有

セッションの保持

セッション保持、負荷等化によるリクエスト配信時に各クライアントがバックエンドの同一のアプリケーションサーバ

に固定的にアクセスすることを保証する.

セッション保持スキームは、すべての負荷等化に対応する実装を有する.そしてこれは負荷等化の層でSession問題

を解決できる

の利点:単純な

を実現

欠点:セッションを使用して負荷の絶対的な均衡を保証できないことを維持する.

Nginx負荷等化によるセッション保持

nginxのupstreamは現在5つの方式の分配方式をサポートしており、そのうち2つの比較的汎用的なSession解決方法があり、ip_hashとurl_hash(公式モジュールではなく、追加のインストールが必要です)

ip_hash:各要求はipにアクセスするhash結果によって割り当てられ、このように各訪問者は固定的にバックエンドサーバにアクセスし、Session保持の方法に達した.バックエンドにサーバダウンタイムがある場合、このサーバのセッションが失われ、このサービス要求に割り当てられたユーザは

  upstream bakend {
     ip_hash;
     server192.168.0.11:80;
     server192.168.0.12:80;
   }

に再ログインする必要がある.

Haproxyは負荷均衡のSession保持をする

セッションコピー

各アプリケーションサーバのセッション情報を他のサーバノードにコピーする

セッションコピーはTomcat上でサポートされており、これはIPマルチキャスト(multicast)に基づいてセッションのコピーを完了する

である.

セッションの共有

セッションをRedisなどの高性能キャッシュ・データベースで保存