分散セッションにはいくつかのソリューションがあります。どちらがお好みですか？

[[398002]]

ショッピングモールを見つけたので、ログインする前にショッピングカートに商品を追加することができました。いくつかの商品を追加した後、支払いの準備ができましたが、最初にログインしてから支払う必要がありました。

現在、多くのショッピングモールでは、ユーザーが最初にログインし、ログイン後にショッピングカートに商品を追加することが求められています。このように、ユーザー、ショッピングカート、商品の間には結びつきがあります。

冒頭で述べた状況については、実際にはセッションに基づいています。クライアントが最初のアイテムをショッピング カートに追加すると、リクエストが送信されます。リクエストを受信すると、サーバーはセッションを作成し、現在のセッションに対応する JessionId を返します。ブラウザはそれをクッキーに保存します。クライアントが 2 番目のアイテムをショッピング カートに追加すると、JessionId が付与されます。リクエストを受信すると、サーバーはセッションを更新します。ブラウザを閉じると、Cookie は無効になり、JessionId は失われます。商品を再度ショッピングカートに追加する必要があります。デフォルトでは、セッションは 30 分間有効です。

分散環境では、サーバーが 2 つのサーバー A と B に展開されている場合、セッションの問題が発生します。初めてショッピング カートにアイテムを追加すると、リクエストはサーバー A に送信され、サーバー A はセッションを作成して JessionId を返します。 2 回目にショッピング カートにアイテムを追加する場合、リクエストはサーバー B に送られ、リクエストに含まれる JessionId はサーバー B 上の対応するセッションを見つけることができません。この時点で、サーバー B は新しいセッションを作成し、対応する JessionId を返します。クライアントは、最初に追加された製品が失われたことに気付くでしょう。 。 。

次に、分散環境でセッションの一貫性がどのように実現されるかを学びましょう。

1. クライアントストレージ

分散環境では、クライアントからの複数のリクエストが複数のサーバーに送信される可能性があるため、戦略を変更してセッション情報をクライアントに直接保存することはできますか?はい、サーバーはセッション情報を Cookie に直接保存し、セッションの一貫性を確保します。ただし、一部の情報を Cookie に保存することは、その情報をクライアントに公開することと同じであり、重大なセキュリティ リスクが生じるため、これを行うことはお勧めしません。

欠点:

セキュリティ問題

クッキーにはデータの種類とデータサイズに制限がある

2. セッションレプリケーション

サーバー A のセッションをサーバー B にコピーし、サーバー B のセッションもサーバー A にコピーして、2 つのサーバーのセッションの一貫性を保ちます。 Tomcat などの Web コンテナーはセッションのレプリケーションをサポートします。同じ LAN 内で、1 つのサーバーのセッションが他のサーバーにブロードキャストされます。

欠点:

同じネットワーク セグメント内にサーバーが多すぎると、各サーバーがセッションをコピーするため、サーバーのメモリが無駄になります。

3. セッションの持続性

Nginx サーバーのリバース プロキシを使用してサーバー A とサーバー B をプロキシし、ip_hash ロード戦略を使用してクライアントとサーバーをバインドします。つまり、クライアント A が初めてサーバー B にアクセスする場合、2 回目のアクセスもサーバー B にアクセスする必要があるため、セッションの不整合の問題は発生しません。

欠点:

サーバー A がダウンすると、クライアント A とクライアント B のセッションが失われます。

4. 集中セッション管理

この方法は、すべてのサーバーのセッションを統一的に管理します。セッションを集中管理するには、redis などの高性能サーバーを使用することができ、Spring が公式に提供する spring-session は、この方法でセッション一貫性の問題に対処します。これは、現在エンタープライズ開発で頻繁に使用されている分散セッション ソリューションでもあります。

5. 春期練習

Spring は、分散セッションを処理するためのソリューションである Spring Session を提供します。 Spring Session は、ユーザー セッションを管理するための API と実装を提供します。

Spring Session は、redis、mongodb、mysql などの一般的に使用されるリポジトリのサポートを提供します。Spring Session は HttpSession との透過的な統合を提供するため、開発者は HttpSession 実装を Spring Session でサポートされている実装に切り替えることができます。同じレシピですが、味は違います！

Spring Session は、パッケージ化されたリクエストとレスポンスを変更するための SessionRepositoryFilter フィルターを追加します。パッケージ化されたリクエストは SessionRepositoryRequestWrapper です。 getSession() メソッドを呼び出すと、実際には Spring Session によって実装されたセッションが呼び出されます。

Spring Session は非常に使いやすいです。関連する依存関係を追加した後、HttpSession を直接操作することで効果を得ることができます。

ステップ1: Spring Sessionとredisの依存関係を追加する

<依存関係>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
 </依存関係> 
 
 <依存関係>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
 </依存関係> 
 
 <依存関係>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
 </依存関係>
 <依存関係>
    <グループ ID>org.apache.commons</グループ ID>
    <artifactId>コモンズプール2</artifactId>
 </依存関係>

ステップ2: Redis関連情報を構成する

春：
  レディス:
    # redis ライブラリ
データベース: 0
    # Redis サーバーアドレス
    ホスト: ローカルホスト
    # redis ポート番号
    ポート: 6379
    # redis パスワード
パスワード:
  # セッションはRedisストレージを使用します
  セッション：
    ストアタイプ: redis

ステップ3: プロジェクトでセッションを使用する

パブリック文字列sessionTest(HttpServletRequestリクエスト){ 
 
    HttpSession セッション = request.getSession();
    session.setAttribute( "キー" 、 "値" );
 session.getAttribute( "key" ).toString()を返します。
 }

Redis の各セッションには 3 つの情報が保存されます。

• 最初のものは、Set タイプの Redis データ構造であるセッション ID を格納します。この k の最後の値 1439245080000 はタイムスタンプであり、このセッションの有効期限に基づいて次の分まで計算されます。
• 2 つ目は、セッションの有効期限、最新のアクセス時間、属性など、セッションの詳細情報を保存するために使用されます。この k の有効期限は、セッションの最大有効期限 + 5 分です。デフォルトの最大有効期限が 30 分の場合、この k の有効期限は 35 分になります。
• 3 番目は、Redis のセッションの有効期限を示すために使用されます。この kv には有用なデータは保存されず、セッションの有効期限が切れたことを示すためだけに設定されます。 Redis におけるこの k の有効期限は、セッションの有効期限間隔です。

セッションを処理するときに、1 つのデータではなく 3 つのデータを保存する必要があるのはなぜですか?セッションを実装するには、セッションの作成、有効期限、その他のイベントを監視する必要があります。 Redis はキーの変更を監視でき、キーが変更された場合、対応する処理を迅速に行うことができます。

しかし、Redis で期限切れのキーが発生する方法は 2 つあります。

• アクセスすると期限切れであることが判明
• Redisのバックグラウンドで期限切れのキーを徐々に検索する

アクセス中にキーの有効期限が切れていることが判明した場合、有効期限イベントが生成されますが、キーの有効期限が到来した直後に有効期限イベントが生成される保証はありません。

セッションの有効期限イベントを時間内に生成するために、spring-session は以下を追加します。

 spring:session:セッション:有効期限:726de8fc-c045-481a-986d-f7c4c5851a67spring:セッション:有効期限:1620393360000

spring-session にはタイマー タスクがあり、対応する spring:session:expirations: whole minute タイムスタンプ内の期限切れの SessionId を 1 分ごとに照会し、この SessionId、つまり spring:session:sessions:expires:SessionId に再度アクセスして、Redis が時間内にキー有効期限イベント、つまりセッション有効期限イベントを生成できるようにします。

参照する

https://www.cnblogs.com/sxw123/p/13803478.html

この記事はWeChatの公開アカウント「Java Journey」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合は、Java Journey の公開アカウントにお問い合わせください。