0

新しくリリースされた Spring Session コンポーネントで PoC を行っています。これは、セッションとセッションに保存されたオブジェクト/データの両方が保持される Redis リポジトリによってバックアップされます。

  1. アプリケーションでセッションが作成されました
  2. Redis CLI で「Keys *」コマンドを実行し、新しいエントリを確認しました (「spring:session:sessions:6b55103a-baf5-4a05-a127-3a9cfa15c164」など)。
  3. アプリケーションから、カスタム Bean をセッションに追加しました
  4. Redis CLI で "Keys *" コマンドを実行し、この Bean の新しいエントリをもう 1 つ確認しました ("\xac\xed\x00\x05t\x00\tcustomer1" のように、Bean には値が 'customer1' の文字列があったため)
  5. 30 秒の自動有効期限を設定し、その間アプリケーションを使用せずに残しました
  6. sessionDestroyEvent がトリガーされ、ApplicationListener を実装するリスナーでキャプチャされました
  7. Redis CLI で「Keys *」コマンドを実行すると、セッションの最初に作成されたエントリがなくなりましたが、カスタム Bean オブジェクト (customer1) はまだ Redis に残っていました

質問:

Redis Store をクリーンアップするのはユーザーの責任ですか? セッションに多くのデータ要素が保存されている場合、セッションの破棄 (ログアウトおよびタイムアウト イベント) 中に redis ストアから手動でそれらをクリーンアップする必要があります。

更新：

この質問を投稿して (おそらく 3/4 分後) Redis-CLI に戻ってキーを一覧表示しましたが、Customer1 オブジェクトが見つかりません。つまり、ガベージ コレクションのように、Redis によって一定の間隔でクリーンアップが実行されるということですか?

4

1 に答える 1

2

Session Expiration セクションのSpring Session リファレンスでは、セッションがどのようにクリーンアップされるかについて詳しく説明しています。

ドキュメントから：

このアプローチの問題点の 1 つは、キーがアクセスされていない場合、期限切れのイベントがいつ発生するかを Redis が保証しないことです。具体的には、期限切れのキーをクリーンアップするために Redis が使用するバックグラウンド タスクは優先度の低いタスクであり、キーの有効期限がトリガーされない場合があります。詳細について は、Redis ドキュメントの「期限切れイベントのタイミング」セクションを参照してください。

...

このため、各セッションの有効期限も最も近い分まで追跡されます。これにより、バックグラウンド タスクが期限切れの可能性のあるセッションにアクセスして、Redis の期限切れイベントがより決定論的な方法で確実に発生するようになります。

于 2015-03-11T16:49:36.657 に答える