面试记录 2026-10-10
题目：分布式系统，用户登录信息保存在服务器 A 上，服务器 B 如何获取到共享 Session
难度：medium（题目 frontmatter 为 medium，本面试按 low 提问）
标签：practice/distributed, distributed/session, difficulty/medium
评分：⭐⭐⭐☆☆（3/5）
我的回答
分布式系统下，共享 Session 一般是当下共享 Session 一般是通过共享缓存，也就是 Redis 一类的公共缓存来进行共享信息的。
另外的主流方案就类似于 JWT,在令牌中存储一定信息，然后通过令牌中的部分信息，比如说用户 ID，再去 Redis 中查取用户的信息。通过无状态的方式来进行信息共享，共享的信息还是在公共缓存中。
比较早的一些方案就是会把所有的信息在几台服务器中进行同步，但是会导致数据的冗余。然后资源的浪费，后期就改成使用公共缓存 Redis 之类的工具去公共的缓存这些信息，大家共用。再之后就是当下比较常见的无状态的方式;
点评
优点：
- 覆盖了主流的两大方案：Redis 集中式存储 + JWT 令牌
- 简单点出了早期"服务器间同步"方案的痛点（冗余、浪费）
- 有演进视角：同步 → 集中缓存 → 无状态
不足：
- JWT 描述有误：JWT 的核心是自包含无状态，token 里的 payload 已带用户信息，服务端不必再去 Redis 查；用户表述"通过 token 中的用户 ID 再回 Redis 查"这是Session Token + Redis 验证模式，不是纯 JWT
- 方案遗漏：完全没提 Sticky Session（Nginx ip_hash/一致性哈希），这是网关层最早最简单的方案之一
- 方案遗漏：没提 Spring Session 集群复制（ReplicatedSession/PassivatedSession） 这类"会话同步"的实现方式
- 落地细节缺失：没讲各方案的取舍（性能、扩展性、单点风险、登出/踢人能力）
补充：
- 完整方案对比：Sticky Session / Redis 集中存储 / Session 同步 / JWT / Session + JWT 混合
- JWT 的短板：不支持服务端主动失效（登出/踢人），payload 不能太大，密钥管理
- 常见工程做法：JWT 作为网关鉴权 + Redis 存 refresh token 或黑名单，兼顾无状态和主动控制
完整讲解
第一部分：知识重点剖析
核心考点定位：考察分布式场景下 Session 一致性的方案选型能力，涵盖"有状态共享"与"无状态化"两条路线。
知识点拆解：
- Sticky Session（网关粘性）：Nginx 用
ip_hash 或一致性哈希把同一用户固定路由到同一台服务器，Session 仍存本地。问题：服务器宕机用户被踢；扩容时 hash 变化会导致大量 Session 失效
- Session 同步（复制）：应用层把 Session 变更广播到其他节点，如 Spring
ReplicatedHttpSession。问题：N² 网络开销，节点扩展性差
- Redis 集中存储（主流方案）：Session 存 Redis，所有节点共享。Spring Session Data Redis 开箱即用。优点：解耦应用和存储、支持主动失效（登出）；缺点：Redis 成为单点，需要 Redis Cluster/Sentinel 保障高可用
- JWT 无状态：登录时签发 JWT，用户存本地 Cookie/Header，每次请求带 JWT，服务端用密钥验证签名 + 检查过期时间即可。优点：完全无状态，横向扩容零成本；缺点：不支持服务端主动失效（登出后 token 依然有效直到过期），payload 有限（几百字节），私钥泄露风险
- 混合模式（工业界主流）：网关用 JWT 做初步鉴权（快速路径），业务系统用 Redis 存 refresh token / 黑名单 / 权限快照。登出时把 JWT 的 jti 加入黑名单
- 对比维度：网络开销、扩展性、单点风险、登出/踢人能力、payload 大小
递进：网关层方案 → 存储层方案 → 无状态方案 → 混合方案 → 取舍
第二部分：考察方向与延伸递进
考察方向：
- 深度：能否区分"真无状态 JWT"和"Session+Redis 验证"这两种看似 JWT 的混合实现
- 广度：能否延伸到 OAuth2、SSO、Cookie vs Header 等相邻知识
- 应用：给定具体业务场景（如金融 vs 电商），能否选择合适的方案
延伸递进面试题：
- JWT 如何支持登出/踢人？
- 服务端维护 token 黑名单（jti）；或缩短 access token 有效期，配合 refresh token 存 Redis
- 权限变更时通过版本号/时间戳字段让旧 token 快速失效
- Redis 作为 Session 存储，如果 Redis 挂了怎么办？
- Redis Cluster 主从切换；读写分离
- Session 本地缓存 + Redis 兜底（Caffeine + Redis）
- 极端场景降级到只允许已登录用户，新登录排队
- Cookie 和 Header 里放 JWT 各有什么优缺点？
- Cookie：自动携带、跨域受同源限制、需考虑 CSRF
- Header：跨域方便、需前端手动管理、易受 XSS
- SSO（单点登录）是怎么做的？
- 中央 SSO 服务签发全局 token，业务系统用 ticket 换取本地 token
- OAuth2 授权码模式：授权服务器 + 资源服务器分离
第三部分：面试者参考回答（300-600 字口语化）
面试官您好，分布式 Session 的方案演进大致经历了几个阶段。
最早的方案是网关层 Sticky Session，比如 Nginx 用 ip_hash 把同一用户固定路由到同一台服务器，Session 保留在本地。这是最简单的方案，但扩展性差，机器宕机用户会被踢，扩容后 hash 变化会导致大量 Session 失效。
第二个阶段是Session 同步，应用层把 Session 变更广播到其他节点，Spring 里的 ReplicatedHttpSession 就是这个思路。问题是节点间 N² 网络开销，节点越多越慢。
现在业界主流是Redis 集中存储，用 Spring Session Data Redis 之类的组件把 Session 统一存到 Redis，所有服务器共享。这种方案解耦了应用和存储，支持服务端主动失效（比如登出时直接删 key），也是当下最主流的落地方案。缺点是 Redis 成了单点，需要用 Redis Cluster 或 Sentinel 保障高可用。
第三个方向是无状态 JWT：登录时服务端签发一个 JWT，用户存到 Cookie 或 Header 里，之后每次请求带 JWT，服务端只用公钥/共享密钥验签 + 检查过期时间即可，完全不需要查 Redis。它的优点是横向扩容零成本，缺点是不支持服务端主动失效——用户登出后 JWT 依然有效直到过期，这是个明显短板。
工业界现在比较常见的做法是混合模式：网关用 JWT 做初步鉴权（快速路径，无需查库），业务系统用 Redis 存 refresh token 或维护一个 jti 黑名单，登出时把 JWT 的 jti 加入黑名单，权限变更时通过版本号让旧 token 快速失效。这样既保留了无状态的性能优势，又补上了主动失效的短板。
总的来说选型看业务：金融场景强一致性优先选 Redis 集中存储；C 端互联网场景优先 JWT 混合模式；简单内部系统可以直接用 Redis 集中存储最省事。