无标题文档
来源：无标题文档
（开头 30 秒：抓眼球 + 点题）“兄弟们！做分布式项目的有没有遇到过这种坑？—— 用户登录完没多久就被踢下线，投诉都快爆了！或者面试被问‘JWT 和 Session 该怎么选’，支支吾吾说不出重点？今天这个视频，5 分钟帮你把分布式会话选型扒得明明白白，从问题到方案，再到面试标准答案，一次性搞定，结尾还送 PPT 和源码！”
先问个扎心的：面试官问这个问题，真不是让你背概念！他们想看啥？三个点 —— 你懂不懂基本原理？会不会根据场景选方案？能不能落地到项目里？这才是加分项，记好咯。
（转场丝滑：切入 Session 痛点，40 秒）“咱们先从最常见的问题说起：为啥分布式部署后，用户总被踢下线？你想啊，单体项目的时候，Session 存在 Tomcat 内存里，没问题；但一搞集群，Tomcat1、Tomcat2、Tomcat3 各玩各的 —— 你在 Tomcat1 登录，负载均衡下次把你分到 Tomcat2，它根本没有你的 Session，可不就直接让你重新登录嘛！这就是 Session 的核心痛点：单机存储，跨节点不能共享！”
（转场：Session 解决方案，35 秒）“那这问题咋解决？答案很简单：把 Session 从 Tomcat 里‘挪’出来！用 Spring Session+Redis，把所有用户的 Session 都存到 Redis 里，不管你被分到哪个 Tomcat，都去 Redis 读 Session——Tomcat1、Tomcat2 共享一份数据，自然就不会踢用户下线了！而且不用改业务代码，无缝迁移，这波操作是不是很丝滑？”
（转场：引出 JWT，40 秒）“解决了 Session 的问题，咱们再看另一个热门方案 ——JWT！有人说‘JWT 无状态，比 Session 香多了’，这话没毛病！JWT 是把用户信息加密成 Token，存在客户端，服务端不用存任何东西，验证的时候解密就行，高并发、跨域场景下性能贼好，做 APP、API 网关的都爱用！但 —— 重点来了，大厂为啥很少纯用 JWT？”
（转场：JWT 的坑，60 秒）“因为 JWT 有 4 个致命坑！第一，Token 一旦生成，你想让它失效都难 —— 用户登出了、账号冻结了，只要没过期，还能访问，这不坑吗？第二，里面的用户数据只是 Base64 编码，不是加密，别人一解码就能看到，可不能存密码、手机号！第三，密钥要是泄露了，攻击者能伪造任意 Token；密钥一改，所有旧 Token 全失效！第四，过期时间固定死，想改只能让用户重新登录，体验太差！”
（转场：核心选型逻辑，60 秒）“知道了两者的优缺点，那到底该怎么选？记住 3 个场景就行，面试直接套用！第一，做支付、后台管理系统，安全性优先，需要主动让用户下线的 —— 选 Spring Session+Redis，稳！第二，做 APP、API 网关，高并发、跨域，不需要主动失效的 —— 选 JWT，快！第三，又想要无状态，又得能主动失效的混合场景 —— 用 JWT+Redis 黑名单，登出的时候把 Token 放进黑名单，验证的时候先查黑名单，完美解决！”
（转场：面试加分项，30 秒）“面试的时候再补一句加分话术：分布式会话选型，本质是一致性、安全性、扩展性的平衡 —— 不是选最好的，而是选最适合场景的！这话说出来，面试官直接觉得你懂行！”
（结尾引导，20 秒）“好了，5 分钟把 Session 和 JWT 的选型逻辑讲透了！想要 PPT 完整版、伪代码源码和面试应答模板的，评论区扣‘会话选型’，我直接打包发你！关注我，下次带你拆解更多面试必问的技术难点，咱们下期见！”
（开头镜头对着PPT封面，手指标题）
兄弟们，面试被问分布式会话怎么选？JWT和Session到底哪个更靠谱？今天5分钟给你拆透——从踩坑经历到选型逻辑，最后还有全套资料领取方式，千万别划走！
（点击下一页，镜头切到第2页）
先问个扎心的：面试官问这个问题，真不是让你背概念！他们想看啥？三个点——你懂不懂基本原理？会不会根据场景选方案？能不能落地到项目里？这才是加分项，记好咯。
（点击下一页，第3页动画演示Session问题）
咱们先看个糟心场景：系统从单机改成分布式，用户登录好好的，刷着刷着突然被踢下线，还得重新登录——这锅谁背？Session！为啥？因为Session默认存在单个服务器内存里，用户下次请求被分到别的服务器，那边根本没这Session，可不就登录失效了嘛。
（点击下一页，第4页展示解决方案）
那这坑怎么填？简单！把Session挪到大家都能访问的地方就行。Spring Session+Redis一套组合拳：所有服务器都去Redis读Session，不管请求到哪台机器，数据都一致。配置也简单，引个依赖，加个注解，Cookie共享一设置，搞定！
（点击下一页，第5页JWT流程图）
这时候有人说了：“用JWT啊！无状态多爽，服务器不用存数据。” 确实，JWT就像个加密的身份证——登录时服务器生成一个带签名的Token，客户端存着，每次请求带上，服务器解密验个签名就认人，不用存东西。听着挺香是吧？
（点击下一页，第6页坑点卡片）
但大厂为啥很少纯用JWT？四个致命坑得记牢：第一，发出去的Token收不回，用户登出了，没过期的Token还能用；第二，里面的数据只是Base64编码，不是加密，存敏感信息等于裸奔；第三，密钥一旦泄露，谁都能伪造Token；第四，过期时间写死了，想改？除非用户重新登录。
（点击下一页，第7页选型决策树）
那到底怎么选？记好这个决策树：如果是支付系统、后台管理，安全性第一，还得能随时让用户下线——选Session+Redis；如果是高并发的APP、API网关，跨域跨服务频繁——选JWT；要是又想要无状态，又得能主动失效——那就JWT+Redis黑名单，登出时把Token扔进黑名单，验证时查一下就行。
（点击下一页，第8页代码和话术）
最后送上面试加分话术：“选型核心是平衡——一致性、安全性、扩展性。安全优先用Session+Redis，高并发跨域用JWT，混合场景就加个黑名单。” 这么说，面试官绝对觉得你有实战经验。
（镜头切回自己，手持资料示意）
想要这份PPT完整版和选型决策树的，评论区扣“分布式”，我直接发你！关注我，下期拆解分布式锁的坑，咱们不见不散～