多台web服务器的session 问题

1)session sticky

   负载均衡器能够根据每次请求的会话标识来进行请求转发。缺点：如果有一台Web服务器宕机或者重启，那么这台机器上的会话数据会丢失。如果会话中有登录状态数据，那么用户就要重新登陆了

    会话标识是应用层的信息，那么负载均衡器要将同一个会话的请求都保存到同一个web服务器上的话，就需要进行应用层(第7层)的解析，这个开销比第4层的交换要大

    负载均衡器变为了一个有状态的节点，要将会话保存到具体web服务器的映射。和无状态的节点相比，内存消耗会更大，容灾方面会更麻烦

 

2)session replication

        不再要求负载均衡器来保证同一个会话的多次请求必须到同一个web服务器上了。而我们的web服务器之间则增加了会话数据的同步。通过同步就保证了不同web服务器之间的session数据的一致。

   一般的应用容器都支持 session replication的方式。与session sticky方案相比，session replication 方式对负载均衡器没有那么多的要求，不过这个方案本身也有问题

   同步session 数据造成了网络带宽的开销。 只要session 数据有变化，就需要将数据同步到所有其他机器上，机器数越多，同步带来的网络带宽开销就越大

   每台web服务器都要保存所有的session数据，如果整个集群的session数据很多的话，每台机器用于保存session数据的内容占用会很严重

 

           机器数量少时是可以的

 

3)Session 数据集中存储

         不同的web服务器从同样的地方来获取session,保证了不同的Web服务器上读到的session数据都是一样的。而存储session数据的具体方式，可以使用数据库，也可以使用其他分布式存储系统。 这个方案解决了session replication 方案中内存的问题，而对于网络带宽，这个方案也比session Replication要好。 该方案存在的问题是什么呢

        读写session数据引入了网络操作，这相对于本机的数据读取来说，问题就在于存在时延和不稳定性，不过我们的通信基本都发生在内网，问题不大。

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

 

   相对于session replication ,当web服务器数量比较大，session数比较多的时候，这个集中存储方案的优势是非常明显的

4) cookie based

 

       将session数据放在Cookie里，然后在web服务器上从Cookie中生成对应的session数据。

这个方案不依赖外部的一个存储系统，也就不存在从外部系统获取，写入session数据的网络时延,不稳定性了

      不足

      Cookie的长度的限制

      安全性。 Session数据本来都是服务器数据，而这个方案是让这些服务端数据到了外部网络及客户端，因此存在安全性上的问题。我们可以对写入cookie的session数据做加密，不过对于安全来说，物理上不能接触才是安全的

      带宽消耗。 不是内部web服务器之间的带宽消耗，而是我们数据中心的整体外部带宽的消耗。

      性能影响，每次http请求和响应都带有session数据，对web服务器来说，在同样的处理请求下，响应的结果输出越少，支持的并发请求就会越多