面试问你为什么登录用了redis+session的方案，然后就挂了

恒_际:
其实就是jwt嘛。这玩意服务器压力更小，也不需要redis了。但是问题就是他基于加解密。所以登出只能通过前端删token，而不能真正使得这个token失效。那么在登出和修改密码需要重置等方面就没法解决（或者继续引入redis）整半天还不如直接上redis呢，还简单。

【回复】回复 @爱玩小鱼哥的基金_ : 我意思是你用jwt不还是要解决登出和改密等问题。解决方案结果还是用redis，省那点redis性能有啥意义吗。至于负载问题，有几个项目能到redis扛不住的地步？真那么牛，redis用一致性哈希做分布式一样能解决啊，当然大厂具体用啥方案我不知道。就瞎说
【回复】回复 @小松菜奈何取之尽淄 : 看你业务需求。理论上用户登出就意味着这个token应该失效。但是实际操作大部分场景只要前端删除token即可。但是部分场景就没那么简单了，比如用户修改密码登操作后是肯定希望有重置操作使得之前的jwt失效（尤其是涉及账号安全的时候）。那么你是不是要引入redis来存储这部分jwt或者用户信息？那么问题来了，反正验签这步要用redis，为什么不全程用redis？jwt结合redis的操作当然从性能上更优一些，可以容纳更高的并发，但是纯redis+token的形式不仅更简单甚至更安全，关键是对百分99以上的项目来说根本遇不到这个性能瓶颈。
【回复】微服务在网关搞，单体架构不需要redis，分布式redis+JWT
86185996147_bili:
session 跟前后端分离没有关系吧，再说了前后端还能不分离，一个在 agent 一个在 server 怎么都是分离的吧。 无论何种 agent 、server ，涉及登陆，都要缓存会话信息，个人认为不应该简单狭义的认为 session 就是服务端的。 由于跨端，各端需要一种基于票据的身份认证机制，用于确认操作人是谁。我们所说的 sessionid 、token 都是票据，一种基本抗伪造（没错无法抗抵赖，偷到了你就是操作人）的票据。 服务端怎么从票据换用户信息，属于服务端技术路线的范畴，可以从缓存，可以从票据本身。 agent 怎么携带票据属于agent端技术路线的范畴，基于 http 的浏览器，一般将票据存放在 http 协议的 header 或查询字符串。更特别的如果基于 header 的 cookie 字段，浏览器对其有便易性支持，会在请求时自动携带。 现在有些面试官喜欢把概念名词搅起一坨问，也不知想问个啥。

【回复】我认同你说的，session我觉得应该是广义的会话意思，无论是sessionid还是token，本身都只是作为key用来服务端取对应的value的一种凭证罢了。jwt把数据存在里边，不需要服务端存储数据，好处是简单，坏处是服务端对凭证的不可控(无法主动让它失效)。redis+token其实就是和以前sessionid那套的优化版，把数据存到一个更中心化的地方罢了，解决分布式下不同机器的数据共享问题。
【回复】回复 @校招VIP :session我觉得应该是广义的会话意思，无论是sessionid还是token，本身都只是作为key用来服务端取对应的value的一种凭证罢了。jwt把数据存在里边，不需要服务端存储数据，好处是简单，坏处是服务端对凭证的不可控(无法主动让它失效)。redis+token其实就是和以前sessionid那套的优化版，解决分布式下不同机器的数据共享问题。
【回复】回复 @校招VIP :不懂你一直在强调session的狭义概念干什么
CppCmake:
这个问题太难了，难就难在问问题的人根本就没有描述清楚问题。问问题能说清楚的这个问题；你就不该有任何对面知识储备的假设。你应该知道session是什么吧？我怀疑问问题都说不清楚/token方案，session方案，这个有什么标准答案吗？你的理解是别人的理解吗？你假设了你的理解别人的理解一样，不一样就是对面菜。这就是面试的乱象的原因。

【回复】计算机网络里的session是做什么？我上边回答了，服务器上通过客户端的一个值找到的数据，都可以叫做session。通过一个socket认识你，当然可以叫session。osi7层架构里的session那叫做抽象层，从来都没有具体实现，也不是什么重要的知识。还学计算机的人都该知道的东西？那只是你这种背八股的人在意的东西。每当你问，“你连这都不懂，你怎么能做好？”这句话时，反问下自己，不懂这个真的耽误什么吗？不一定100%是错的，起码说这样的句形时，99%是错的，八股流的自欺欺人，自己会，别人不会，满足自己的虚荣心。 我学会一个知识，我会反思自己，我比不会这个知识的高什么？当然绝大数人不会认为高很多，起码可以高一点吧。我认为的是一点点都不高。
【回复】确实是个自以为是的up，每个人的理解都不一样他自己也没搞懂别人说的东西就觉得别人说的不对笑死。
正在学习前端中:
感觉是学习Java的人被误导了。 最初使用传统jsp页面的web应用， 各种教程中都说用session维持登录状态， 这完全是一种错误，只说了服务器端，没强调客户端(浏览器)cookie的作用。 与之相反的是asp.net 的教程都是说cookie维持状态，通过cookie来作为键，在session字典中找到对应项。感觉就是教程害死人。[doge]

【回复】javaweb没学过 ？jsessionid 不就是通过cookie找session？这俩个东西能拆？[doge]
【回复】回复 @_yang023 :只是想说当初难道这是拆开学的[喜极而泣][喜极而泣][喜极而泣]
行者阿金:
首先，你要知道session是什么？session是一个会话。 跟前后端分离没任何关系，跟登录也没关系。 session追踪用户识别用户的。可以把一次请求当成一个会话，也可以把几十年的请求当成一次会话。 最核心的如何区分请求，会话唯一标识。 浏览器无论用cookie，storage，数据库，url保存标识目的都一样。前后端分离不过是手工与自动的区别。 生成会话信息--存储会话信息--读取会话信息。 那与分布式也没什么鸟关系。如果这个信息只在客户端使用，有没有服务端都一样。 信息简单，每个url都携带标识，有没有数据库都一样。 服务器存储核心是数据共享，定期清理。 简单方案，单机时临时文件，多机用redis。 手动清理方案就多喽。 选用redis存储只是方便，效率快，可设置失效。

【回复】说了这么大的一段，第一句就是答案，什么叫会话，是从客户端cookie信息里取到对应的sessionID。 你现在sessionID都取不到，谈什么会话，更不要讲session最常用的页面session，也就是用户关闭页面，session是失效。 实际上token方案，跟session没什么关系 ，就是一个随机值而已
子尧解说QAQ:
我认为全世界最懂的人就是此视频的up主

系统杀手:
up主还是经历的太少。 等哪天有各种用户画像需求, 用户设备登录记录统一认证管理需求，已登录设备作为新设备的登录器需求时。就知道上redis的必要性了。

【回复】你这是有需求的前提 没需要为什么要做那么复杂 显摆？
【回复】唉，连题目都没看懂，就出来教育，视频说的是redis的事情吗？
leovsliu:
session 和前后端分离没有什么关系，单系统的情况下 sessionid依然是服务端给客户的浏览器分配并存储到 cookie 的，为什么用redis 加 token 主要是解决分布式服务多 web 服务器被随机分配后 sessionid 无法在被随机负载均衡的后端服务器所匹配session 的数据池，和什么微服务更没有什么关系，微服务只中后台的 rpc 调用，不参与 sessionid 分配的事情

【回复】前后端分离的后端是一个纯接口，服务于大前端，包括页面，也包括小程序和APP。 所以商业的后端设计的通用思路不会是首选一个页面周期的session方案
谢谢隔壁老王:
学生又不是有几年的项目经验，工作一段时间就明白了，何必纠结这个

【回复】因为面试是考试啊，自己简历上写的自己做的东西，问一个问题却回答不上来，那就是考试这道题目得了0分，那考试就失败了
九转大厨:
session意为会话，说到底就是用来存储用户当前的一些信息，之前是servlet容器帮我们在内存中创建的，现在用咱们自己手动将这个所谓的session存到远程redis中从而实现session共享

【回复】回复 @校招VIP :你可以去试一下，在登录的时候将jsessionId 的maxage设一下 你就会发现浏览器就算关闭了 会话仍然有效
【回复】回复 @JacSime :所以说前后端分离，实际上是把一个传统的场景给打破了，就不应该用很复杂的继续去实现所谓的session场景。 或者反过来看这个问题的本质，为什么前端森累的项目必须要用session， 这什么场景下要用到它，而一个随机的token是不满足的。
【回复】回复 @校招VIP :直接通过sessionid有无不就可以判断了吗？
浦东吃西瓜:
为啥前后分离微服务不能出现session ？那么请问spring security 以及authorization server统一认证中心授权码模式里为什么不能禁用session？

【回复】回复 @校招VIP : 阿里内部登录都是走统一认证平台，APP也好Web也好都是要跳转到统一登录平台进行登录和完成身份校验，其就是采用了OAuth架构设计思想，包括spring的OAuth的授权码模式也是要必须用session进行状态交互。跟你说了这么多你反倒来开发否定我的出身了，我虽然不是做阿里内部登录的，但是我也是负责别的系统的，统一登录就是我接的，认证团队告诉我的方案就是必须统一跳转web登录，不管你是APP还是Web，这是安全性的问题好吗，别扯其他的，抛开安全性不谈只谈性能是吧。另外去多看下别人的分析，也发出了警告：不要试图用JWT完全代替Session。
【回复】回复 @校招VIP :我说这么多就是要告诉你，session也是可以用的，你还没理解我强调的观点？我一开始就在反驳你并不是非要用jwt不能用redis session，技术应该服务于具体需求而不是一口咬死，你作为面试官，难道就只会关注这一点？？？我看了别的评论都在反驳你，不知道你是本身思维偏激还是故意这么说[吃瓜]，你哪来的底气否定别人？
【回复】回复 @诶嘿黒皮 : 没啥好说的 他已经给评论的人预设好了 整个视频下面就他是正儿八经在商业公司做开发的，我们都是键盘开发专家。
游学者小宇:
前后端分离和用seesion不冲突吧，后面部署服务应该会有nginx代理吧

【回复】这就是问题，session的概念和使用场景要求 必须有服务器和对应的客户端cookie，而且在实现时是直接从http请求里获取，注意不需要额外的token。 但是前后端分离，特别是这个登录场景，实际上这个session跟服务器一点关系没有，就是为了标记一个用户的变量而已。
i晓楠:
无知还敢瞎bb[笑哭]。。。面试的不会，面试官也是半桶水，笑死[笑哭]，还敢发个视频出来扯淡。。。