集群环境下Session怎么共享，是服务器运维托管中经常碰到的问题。单机时代Session存在本地内存里，没有任何问题。一旦做成集群，用户第一次请求打到A节点登录了，第二次请求被负载均衡分到B节点，B节点没有这个用户的Session，登录状态丢了，用户得重新登录。这个问题的解决方案有好几种，各有优劣，下面逐一分析。
Tomcat内置Session复制
Tomcat自带的DeltaManager和BackupManager可以实现Session复制。DeltaManager采用全量复制模式，每个节点的Session变更会广播到所有其他节点，每台机器都保存完整的Session副本。配置起来简单，Tomcat的server.xml里加几个标签就行。但缺点也很明显：节点越多，复制开销越大，网络带宽和内存消耗都会线性增长。这种方案适合节点数量少（3到5台）且Session量不大的场景。
BackupManager采用主备模式，Session只在一个主节点和一个备份节点上保存，不是全量复制。网络开销比DeltaManager小，但容错能力也弱一些，如果主节点和备份节点同时挂了Session就丢了。两种Manager都有个共同的问题：只适用于Tomcat容器，如果是混合技术栈就无能为力了。
黏性会话方案
黏性会话的思路是不共享Session，而是让同一个用户的请求始终打到同一台机器上。前面提到的IP哈希就是实现黏性会话的一种方式。另一种更可靠的方式是负载均衡器在响应中插入Cookie，标记该用户应该打到哪台后端，后续请求根据这个Cookie做路由。
黏性会话的好处是不需要Session复制，后端之间没有同步开销。坏处是节点故障时该节点上的Session全部丢失，用户需要重新登录。而且节点扩容缩容时Session分布不均匀，新加的机器接不到请求，退掉的机器上的Session丢失。对于有状态服务来说，黏性会话只是一个权宜之计，不是根本解决方案。
Redis集中存储方案
把Session从应用服务器的本地内存挪到Redis里集中存储，是当前最主流的方案。应用服务器通过Spring Session或自研中间件，把Session的读写操作指向Redis。任何节点都能读到同一个Session，节点故障不影响Session数据，扩容缩容也不会丢失用户状态。
Redis方案的性能取决于网络延迟。Session读取从内存操作变成了网络IO，每次请求多一次Redis访问。同机房内网延迟一般在1毫秒以内，对于大部分业务可以接受。如果对延迟敏感，可以在Redis前面加一层本地缓存，热点Session先查本地缓存，查不到再查Redis，减少网络访问次数。Redis的持久化策略也要配好，AOF加RDB双保险，防止Redis重启导致大规模Session丢失。
JWT无状态化方案
最彻底的方案是干脆不用Session。JWT（JSON Web Token）把用户状态编码在Token里，服务端不需要存储任何会话数据，每次请求带上Token，服务端解析Token就能拿到用户信息。这种方式天然支持集群，任何节点都能处理任何请求，不需要Session同步也不需要外部存储。
JWT的代价是Token一旦签发就无法撤销（除非维护一个黑名单），退出登录、修改密码等场景处理起来比较麻烦。Token大小也比普通Session ID大，每次请求都要携带，增加了网络传输量。安全性方面要注意Token不要放敏感信息，因为Token本身是可以解码的，签名只是防篡改不是加密。综合来看，对于安全性要求不是很高的API服务，JWT是很好的选择；对于管理后台、支付系统等对会话控制要求严格的场景，还是Redis Session更稳妥。