一个分布式session的很好的面试题

请听题:

  • 如果让你实现一个分布式session的话,你会怎么设计?
  • 如果你基于redis做的话,如何保证过期的session数据及时被删除?
  • 如果session过期的时候我想获取到session的内容那怎么做呢?

当然了分布式session这个东西并不是一个新东西,已经在业界很多年了,无论是基于tomcat还是基于redis啥的都可以做,有很多种做法。这块就不细说,仅仅说一下基于redis的实现相关的事情。

为什么突然会说这个事情了,主要是因为昨天在回家的路上看了一篇文章从Spring Session源码看Session机制的实现细节,这篇文章写的很不错,可谓是有理有据让人信服,同时不光光是一篇原理解析,也有作者自己的思考在里面,建议大家都读读。

这篇文章其实不长,为了避免部分读者[太长不看],所以简单的总结一下spring-session-redis是怎么弄的呢?

spring-session-redis弄了3个key,通过这3个key解决了下面的几个问题:

  • redis的key删除不及时
  • session提前过期的问题(这个问题其实是因为spring-session-redis的实现引入的问题)
  • session过期以后又想知道过期的session的数据(解决了session过期和session存储的解耦)

当然了,实际的使用过程中,可能这3个都不是问题,业务上其实很多的时候是可以忍受的,但是spring session毕竟是作为一个基础框架来提供的,它的设计和实现必须很严谨,所以他把上面提到的3个问题都解决了。这也就提醒我们做中间件、做框架的时候不能对业务的场景做假设,而是应该非常
严谨的实现。

本文版权归作者所有,禁止一切形式的转载,复制等操作
赞赏

微信赞赏支付宝赞赏

发表评论

电子邮件地址不会被公开。 必填项已用*标注