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数据，很大的影响性能
|
总结：
Session Sticky(粘贴) 和 Session数据集中处理是比较好的方案
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
