0

我正在使用新发布的 Spring Session 组件进行 PoC。这是由 Redis 存储库备份的，其中 Session 和存储在 session 中的对象/数据都被持久化到其中。

  1. 会话在应用程序中创建
  2. 在 Redis CLI 中运行“Keys *”命令并看到一个新条目（如“spring:session:sessions:6b55103a-baf5-4a05-a127-3a9cfa15c164”）
  3. 从应用程序中，向会话添加了一个自定义 bean
  4. 在 Redis CLI 中运行“Keys *”命令并看到该 bean 的另一个新条目（例如“\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 参考详细描述了如何清理会话。

从文档中：

这种方法的一个问题是，Redis 不保证如果它们的键没有被访问，什么时候会触发过期事件。具体来说，Redis 用来清理过期密钥的后台任务是低优先级任务，可能不会触发密钥过期。有关更多详细信息，请参阅Redis 文档中的过期事件的计时 部分。

...

出于这个原因，每个会话到期也被跟踪到最近的分钟。这允许后台任务访问可能过期的会话，以确保以更具确定性的方式触发 Redis 过期事件。

于 2015-03-11T16:49:36.657 回答