会话开始时，会分配一个唯一的会话标识（sessionId），保存到浏览器的cookie中，浏览器每次请求时都会携带这个cookie，告诉web服务器请求是来自哪个会话的，在web服务器中，各个会话都有独立的存储，保存不同的会话信息，如果我们禁用cookie，一般的方法是将sessionId放到url的参数中
集群后如果我们不做处理，由于session都是保存在本地服务器上的，就会有如下问题
如何解决？
（1）session sticky
单机情况下，会话保存在单机上，请求也由这台机器处理，所以不会有问题；web服务器集群后，如果保证同一个会话请求都在同一个web服务器上处理，对这个会话的个体来说，跟单机情况是一样的，要做到这样，就需要负载均衡能够根据每次请求的标识来进行请求转发到同一台服务器上，称为Session Sticky方式
问题：1.如果一台web服务器出现问题，该服务器上的用户会话信息就会丢失，用户就需要重新登陆
2.负载均衡服务器开销大
（2）Session Replication
每台web服务器上都保存一份session信息，各服务器之间保持session复制同步；一般的应用容器都支持这种方式，与Session Sticky相比，对负载均衡没有那么多的要求，这个方案是靠应用容器来完成session复制，应用本身不需要关心
问题：1.session同步增加带宽开销
2.服务器很多时，每台都保存session信息，如果并发访问多的话，每台保存session数据占用严重
（3）session数据集中存储
session数据存储方式：数据库，或者其他分布式存储系统
问题：1.读写session数据引入了网络操作，存在延时和不稳定性，不过通信基本发生在内网，问题不大
2.如果集中存储session的机器或者集群有问题，就会影响我们的应用
（4）Cookie Based
通过cookie来传递session数据
问题：1.受cookie长度的限制
2.安全性：session数据都是服务器上的数据，可以对session数据加密
3.带宽消耗
4.性能影响：每次http请求和响应都带有session数据，对web服务器来说，在同样的处理情况下，响应的结果输出越少，支持的并发请求就越多。
总结：
对于大型网站来说，Session Sticky和Session集中存储是比较好的方案，但各有优劣，需要在具体场景中做出选择和权衡。