3. Session管理演进
在多租户SaaS架构中，Session管理是鉴权拦截链路的核心环节。Session的存储与共享方式直接决定了系统的可扩展性、高可用性以及用户体验。本章将深入剖析Session机制的本质，并梳理从单机Session到分布式Session的演进路径，重点解决Session粘性问题。
3.1 Cookie与Session机制
HTTP协议本身是无状态的，服务器无法区分两次请求是否来自同一个客户端。Cookie与Session机制共同构建了Web应用的状态管理基础。
| 维度 | Cookie | Session |
|---|---|---|
| 存储位置 | 客户端（浏览器） | 服务器端（内存/Redis/数据库） |
| 数据容量 | 4KB左右（受浏览器限制） | 理论上无限制（受服务器资源限制） |
| 安全性 | 较低，可被篡改或窃取（需设置HttpOnly/Secure） | 较高，数据不暴露给客户端 |
| 生命周期 | 可设置过期时间（Expires/Max-Age） | 由服务器控制（通常基于超时时间） |
| 典型用途 | 存储Session ID、用户偏好、追踪标识 | 存储用户登录态、权限数据、购物车 |
核心机制：服务器创建Session后，会生成一个唯一的Session ID，并通过Set-Cookie响应头将该ID写入浏览器的Cookie中。后续请求携带该Cookie，服务器根据Session ID查找对应的Session数据，从而识别用户身份。
下图展示了Cookie与Session的交互流程：
3.2 单机Session的局限性
在单体应用或单服务器部署场景下，Session数据直接存储在应用服务器的本地内存中。这种模式简单直接，但在多租户SaaS场景下存在严重缺陷：
- 无法水平扩展：当流量增长需要增加服务器节点时，新节点没有旧节点的Session数据，导致用户需要重新登录。
- 单点故障：服务器宕机后，所有在线用户的Session数据丢失，造成大规模强制下线。
- 资源竞争：Session数据占用JVM堆内存，随着用户量增长，频繁的GC会影响应用性能。
- 多租户隔离困难：所有租户的Session混在一起，缺乏有效的租户隔离机制。
典型故障场景：某SaaS平台在促销活动期间，由于流量激增临时扩容了2台服务器。结果大量用户反馈“登录状态反复丢失”，需要频繁重新登录。经排查，新扩容的服务器上没有旧服务器的Session数据，负载均衡将请求分发到新服务器时，用户身份无法识别。
3.3 分布式Session的解决方案
为了解决单机Session的局限性，业界提出了多种分布式Session方案。下表对比了主流的实现方式：
| 方案 | 实现原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| Session复制 | 各节点之间广播同步Session数据 | 实现简单，无需额外中间件 | 网络开销大，数据冗余，节点数受限 | 小型集群（≤5节点） |
| Session粘性（Sticky Session） | 负载均衡将同一用户的请求始终转发到同一节点 | 无需改造应用，性能高 | 节点故障导致Session丢失，扩容/缩容困难 | 对可用性要求不高的场景 |
| 集中式Session存储 | 将Session数据统一存储在Redis/MySQL等外部存储 | 无状态化，弹性伸缩，高可用 | 引入网络延迟，需保证存储高可用 | 多租户SaaS首选 |
| 客户端Session（JWT） | 将Session数据加密后存储在客户端Token中 | 完全无状态，无需服务端存储 | Token体积大，无法主动失效，安全风险较高 | 移动端/API鉴权 |
最佳实践：在多租户SaaS架构中，集中式Session存储（Redis）是最推荐的方案。它实现了应用服务器的完全无状态化，任何节点都可以处理任何请求，天然支持弹性伸缩和高可用。同时，Redis的丰富数据结构（Hash、Set、Sorted Set）可以方便地实现租户级别的Session隔离和批量管理。
3.4 Session粘性问题深度剖析
Session粘性（Sticky Session）是分布式Session演进过程中的一个过渡方案，也是很多SaaS平台在早期容易踩的坑。其核心原理是：负载均衡器根据用户请求中的Cookie或IP信息，将同一用户的请求始终转发到同一台后端服务器。
Session粘性带来的核心问题包括：
- 节点故障导致Session丢失：如果用户绑定的服务器宕机，该用户的所有Session数据随之丢失，必须重新登录。
- 扩容/缩容困难：新增服务器节点时，需要等待用户重新绑定；缩容时，被移除节点上的用户Session全部失效。
- 负载不均衡：某些“重量级”用户（如管理员）可能产生大量请求，导致其绑定的服务器负载过高，而其他服务器空闲。
- 运维复杂度增加：需要负载均衡器维护粘性表，增加了配置和排障的难度。
迁移建议：如果你的SaaS平台目前仍在使用Session粘性方案，建议逐步迁移到基于Redis的集中式Session存储。迁移过程可以采用“双写”策略：在应用层同时向本地内存和Redis写入Session数据，先灰度验证Redis读取的稳定性，待确认无误后再关闭本地Session存储。
3.5 基于Redis的集中式Session架构
集中式Session存储是解决Session粘性问题的最佳实践。所有应用服务器不再存储Session数据，而是统一从Redis中读取。下图展示了基于Redis的Session管理架构：
关键设计要点：
- Session Key设计：建议使用
session:{tenantId}:{sessionId}的格式，便于按租户进行批量管理和清理。 - 过期时间：利用Redis的TTL机制，设置合理的Session超时时间（如30分钟），避免僵尸Session占用内存。
- 序列化方式：推荐使用JSON或Protobuf进行序列化，确保跨语言兼容性和可读性。
- 安全加固：Redis需要设置密码认证，并配置防火墙规则，禁止公网直接访问。