分布式与微服务架构下的 Session 同步方案
在系统演进过程中，我们常面临两种典型的扩容场景。第一种是水平拓展：面对资源 A 每秒 2 万次的请求压力，我们将流量分发到两台服务器，每台处理 1 万次。第二种是垂直拆分：将资源 A 和资源 B 分别部署在不同服务器上，服务器 1 专攻资源 A，服务器 2 专攻资源 B。
Session 同步的痛点
当浏览器 A 在服务器 A 上登录成功，Session 信息通常保存在服务器内存中。问题随之而来：在后续请求其他功能时，无论是水平拓展还是垂直拆分，负载均衡都可能将请求转发到其他服务器。此时，目标服务器无法识别用户身份，导致 Session 失效。
传统解决方案及其局限
针对这个问题，业界主要有三种处理方式，但各有取舍：
- Session 存入 Cookie：将 Session ID 甚至部分数据加密后存储在浏览器端，每次请求都携带发送。这种方式减轻了服务端存储压力，但受限于 Cookie 大小且存在安全风险。
- Tomcat 会话复制：开启 Tomcat 的集群复制功能，让每个节点都维护一份完整的 Session 副本。虽然实现了状态同步，但在高并发下网络开销巨大，扩展性较差。
- 粘性会话（Sticky Session）：通过负载均衡框架配置，强制保持一个浏览器的所有请求只访问同一台服务器。这只能解决集群场景，一旦涉及垂直拆分或故障转移，灵活性就大打折扣。
微服务时代的最佳实践
随着架构向微服务演进，服务被分割得更细，上述传统方案往往不再适用。最通用的做法是将 Session 统一持久化到 Redis 等外部缓存中。
这样做的好处显而易见：无论请求落到哪台服务器，只要查询 Redis 即可获取用户状态。这不仅解决了多节点间的 Session 同步问题，还提升了系统的可伸缩性和容错能力，是构建现代化分布式系统的标准选择。