2.2.4.2 大型网站技术和java中间件-大型网站及其架构演进过程:应用服务器警告高，如何让应用从服务器走向集群:解决Session的问题

本文链接：https://blog.csdn.net/one_chao/article/details/101981663

本文探讨了大型网站集群环境下解决Session问题的四种方案：SessionSticky、SessionReplication、Session集中存储和CookieBased，分析了各方案的优缺点及适用场景。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

2.2.4.2 大型网站技术和java中间件-大型网站及其架构演进过程:应用服务器警告高，如何让应用从服务器走向集群:解决Session的问题

影响解决：解决应用服务器变为集群后的Session问题（使用负载均衡）

问题：如下图，如果不做操作，

-> Browser的请求第一次落到了左边的服务器创建了Session，第二次就可能落到第二个服务器

方案一：Session Sticky（Session 粘贴）

1.这个方案非常简单，对应Web服务器而言，该方案和单机是一样的

2.主要操作的地方在负载均衡器上。可以让同样的Session发送到同一个应用服务器上

需要注意的问题：

1.如果一台Web服务器宕机或者重启，这台应用服务器上的数据会丢失，用户需要重新登录

2.会话表示在应用层信息，需要解析应用层数据，开销比底层负载均衡大

3.负载均衡变成了有状态的节点，要把会话保存到具体服务器的映射;和无状态节点相比，内存消耗会更大，内存消耗会更大，容灾比较麻烦

方案二: Session Replication(Session 复制)

1.在Session Replication中，不在要求负载均衡器保持同一个会话到同一个应用服务器

2.应用服务器之间增加了Session同步 -> 保证了多个应用服务器之间的Session数据一致

3.一般的应用容器都支持Session Replication方式

需要注意的问题：

1.同步Session数据造成了网络带宽消耗：只要Session数据有变化，就需要把数据同步到所有的其他机器上，机器越多，同步带来的网络带宽开销就越多

2.每台Web服务器都所有的Session数据，如果整个集群Session很多，每台应用服务器上的Session占用会很严重

总结

不合适集群机器多的场景，如果只有几台机器，这个方案可以

方案三：Session集中存储

1.把Session数据集中存储起来，然后不同的Web服务器从同样的地方获取Session

2.负载均衡器步不再需要转发到固定的应用服务器上

3.Session不需要在应用服务器之间复制，Session存储在同一个地方

3.1 无论在哪台应用服务上修改Session，最终修改是保持一致

4.可以使用数据库，也可以使用其他分布式存储方式

需要注意的问题：

1.读写Session数据引入了网络操作，可能存在延时和不稳定 -> 使用内网问题不大

2.如果集中存储Session的机器或者集群有问题，就会影响我们的应用

总结:

相对于Session Replication，当Session比价大的时候，这个存储方案优势非常明显

方案四：Cookie Based

1.Cookie Based方案也是不限定具体应用处理机器的

2.Cookie Based方案是同Cookie来传递Session数据的（Session是存放在Cookie中的）

3.Cookie Based方案不依赖外部获取，不依赖外部存储，写入Session的网络延时

需要注意的问题：

1.Session长度限制：Cookie长度的限制，这个会限制Session的长度

2.安全性问题：Session本来就是应用服务器上数据，Cookie Based方案让服务器端数据到了外网及客户端，存在安全性问题（虽然可以加密，但是物理上不可接触才是安全的）

3.带宽消耗：影响了数据中心整体带宽

4.性能影响：每次HTTP请求和响应都带有Session数据，很大的影响性能

总结：