session 失效（session失效跳转到登录页面）

这个话题遇到无数次了，鉴权是session+cookie、token+redis、jwt、jwt+redis哪种好？我想这个话题能讨论一个世纪，争议最多的还是token过期、跨端、设备登出、单点登录等场景的问题，其实，都可以满足，可能有些方案感觉有点奇怪而已，技术论剑，一些朋友犯不着急眼。

我觉得大家核算一下，哪个容易搞，哪个成本可控，按划算的来呗，工具而已，毕竟我们的甲方是有预算的，可不能怠慢了“上帝”，更何况我们大多项目几乎不是做淘宝平台吧！

所以，大家采用哪种方案居多？[奸笑]

#职场直言##程序员那些事##职场达人上头条##程序员#

几年前，我去一家公司面试java，面试官问我关于redis持久化的两种方式的区别。

我说让我深入的去聊的话，我聊不出来，因为在我看来，redis做持久化是完全没有意义的事情，所以我也没有必要去深入的去了解。

首先我们要知道redis持久化的意义是什么，就是为了保证在redis宕机的时候，数据不会丢失，但是我们存储到redis的数据，真的因为宕机而丢失了，会对我们带来哪些影响呢？下面我们就从我们存储到redis的不同种类的数据进行分析，看看是否有影响。

1.分布式session，这种数据丢失了，是没有影响的，最多用户在重新登陆一次就好了。

2.验证码，这种数据丢失了，也没啥影响，用户在重新获取一次就好了。

3.分布式锁，分布式锁的过期时间都比较短，最多不会超过5秒钟，你从redis宕机到恢复的过程中，会远远的超过这个时间，等你恢复好了，key早就过期了，所以这种数据也没有啥恢复的必要。

4.幂等性的防重检验，但是在redis层的检验，只是第一层检验，即使redis没有检验住，后面还有数据库的唯一约束的机制做兜底呢，所以影响也不大，当然了，有人可能会说，你这样把所有请求都打到数据库了，会造成缓存雪崩，但是我们在用redis的时候，通常都会做集群，集群的一个节点宕机，也只是一小部分数据丢失了，不会造成雪崩。当然了，你如果说所有节点都宕机了，那就等所有几点都恢复后，做一次缓存预热，问题也不大。

5.数据缓存，这种数据即使在缓存里丢失了，但是在数据库里还是存在了，也没问题，缓存雪崩的问题也不会出现，原因还是如第四点所说。

综上所述来看，redis里的数据丢失，是完全不会有影响的，所以做持久化，其实是没有任何必要的。

面试官听完我的回答后，露出了让人感觉不太满意的表情，可能对我的回答不太满意，这次面试也没有了结果。但是我还是坚持我的看法。

大家怎么看这个问题呢，欢迎评论区留言讨论[握手]