Redis分散セッションの開始

1セッション

セッションセッションは、クライアントとサーバー間の相互作用プロセスを表します。このプロセスは、継続的または断続的です。過去のサーブレット時代(jsp)では、ユーザーがサーバーと対話すると、サーバーユーザーがセッションを作成し、フロントエンドにはjsessionidがあり、これは各対話で実行されます。このようにして、サーバーはユーザーリクエストを受信する限り、jsessionidを取得し、このIDに従ってメモリ内で対応するセッションを見つけることができます。セッションを取得した後、セッションを操作できます。

セッションの存続期間中、ユーザーはWebサイトを使用していると見なすことができます。セッションが終了すると、ユーザーはWebサイトを離れ、対話を停止したと見なすことができます。また、セッションを通じてユーザーの身元情報を判断し、さまざまなユーザーの情報を保存することができます。
セッションの使用は前の単一の部分で示され、コードは次のとおりです。

    @GetMapping("/setSession")
    public Object setSession(HttpServletRequest request) {
    
    
        HttpSession session = request.getSession();
        session.setAttribute("userInfo","new User");
        session.setMaxInactiveInterval(3600);
        session.getAttribute("userInfo");
//        session.removeAttribute("userInfo");
        return "ok";
    }

2ステートレスセッション

HTTPリクエストはステートレスです。ユーザーはサーバーに対して複数のリクエストを開始します。サーバーは、これらの複数のリクエストが同じユーザーからのものであることを認識していません。これはステートレスです。Cookieの出現は、ユーザーを堂々と記録することです。

一般的なフロントエンドとバックエンドの相互作用は分離され、アプレットはサーバーと相互作用し、Androidはサーバーと相互作用します。これらはすべてhttpリクエストを介してインターフェースを呼び出します。サーバーは、毎回クライアントのステータスを取得するわけではありません。すべてのリクエストはuserIdまたはトークンを伝送するため、バックエンドはユーザーIDまたはトークンに基づいてレスポンスリクエストを取得できるため、各ユーザーの次のリクエストはサーバーによって同じユーザーから識別できます。

3ステートフルセッション

Tomcatのセッションはステートフルです。ユーザーがサーバーと対話すると、セッションが発生します。セッションはユーザーの情報を保存するため、ユーザーは「ステートフル」になります。サーバーと各クライアントはこの状態を維持します。1つのレベルの関係、これはコンテナ(つまり、tomcat)によって管理され、このセッションはメモリスペースに格納されるため、さまざまなユーザーがサーバーにアクセスしたときに、対応する訪問者情報をセッションを通じて見つけることができます。

Tomcatセッションの出現は、httpリクエストをステートフルにすることでもあります。ユーザーがサーバーと対話しなくなると、セッションタイムアウトがなくなり、ライフサイクルが終了します。このようにして、各ユーザーは実際に維持されるセッションを持ちます。これはステートフルセッションです。
シナリオ:従来のプロジェクトまたはjspプロジェクトで最も使用されるセッションはすべてステートフルであり、セッションの存在はhttpのステートレス性を補うことです。

  • Tomcatセッションは、複数のシステム間の状態同期を実現できますが、一定の時間がかかります。同期が発生すると、ユーザーの要求は待機します。この方法はお勧めしません。

4単一のTomcatセッション

最初に単一のTomcatセッションを見てみましょう。これはステートフルです。ユーザーがサーバーに初めてアクセスすると、セッションが生成され、jsessionidがCookieに設定されます。後続の各リクエストはjsessionidを伝送して、ユーザーの状態を維持します。 。

ここに画像の説明を挿入

5アクティブな会話と静的な会話の分離

ユーザーがサーバーをリクエストします。ダイナミクスとスタティックが分離されているため、フロントエンドはステータスなしでhttpリクエストを開始します。ユーザーが初めてリクエストするときに、ユーザーセッションとして使用されるトークンを手動で設定します。 redisで使用されるため、redis-sessionとして使用されます。このトークンは設定され、フロントエンドCookieに配置されます(アプリまたはアップルトはローカルキャッシュに配置できます)。そのため、後続の対話プロセスでは、フロントエンドのみが使用されます。トークンをバックエンドに渡す必要があり、バックエンドは統合分析を通じて特定のユーザー要求を分析できます。

ここに画像の説明を挿入

6クラスター分散セッション

クラスターまたは分散システムは、基本的に複数のシステムです。2つのサーバーノード、つまりABシステムがあるとします。これらは、クラスターまたは分散システムの場合があります。最初に、ユーザーはAシステムと対話し、次にユーザーがこの時点で対話します。 Aシステムのセッション情報としてredisに保存できます。次に、ユーザーの要求がBシステムに入り、Bシステムのセッションもredisに関連付けられるため、ABシステムのセッションが統合されます。もちろん、Cookieはユーザーの訪問とともに運ばれるため、これは実際には分散セッションであり、ユーザー情報はredisを介して保存されます。

ここに画像の説明を挿入

7同様の関係:ローカル変数とグローバル変数

Tomcatセッションは、クラス内のメソッドのローカル変数と同等であり、現在のメソッドでのみ使用できます。

クラスのパブリックグローバル変数に相当する分散セッションは、クラス内でさまざまな方法で使用できます。

次のコード:

public class DistributedClusterTest {
    
    
  
  public String distributedSession = "global-1001";
  
  public void ASystem() {
    
    
    String aSession = "a-2001";
    System.out.println(distributedSession);
    System.out.printlnaSession();
  }
 
   public void BSystem() {
    
    
    String bSession = "a-3001";
    System.out.println(distributedSession);
    System.out.printlnaSession();
  }
 
}

distributedSessionこのクラスは、一方に他の方法で使用することができるグローバル変数でありaSession、そしてbSessionそれはローカル変数の方法で、ローカル変数は、本方法は、他の方法で使用することができるグローバル変数のみを使用することができます。同じことが分散セッションと単一のTomcatセッションにも当てはまります。

8関連情報

  • ブログ投稿は簡単ではありません、注意と賞賛に一生懸命働いたすべての人、ありがとう

おすすめ

転載: blog.csdn.net/qq_15769939/article/details/113969476