解决应用服务器变为集群后的session问题

1.什么是session？

session可以让我们知道哪些请求是来自哪个会话。

具体的实现方式为：在会话开始时，分配一个唯一的会话标示（sessionId），通过cookie把这个标示告诉浏览器，以后每次请求的时候，浏览器都会带上这个会话标示来告诉web服务器请求是属于哪个会话的。

2.解决应用服务器变为集群后的session问题

方案1:session sticky

在负载均衡上做手脚，这个方案可以让同样的session请求每次都发送到同一个服务器端处理，非常利于针对session进行服务器端本地的缓存。

打个比方来说，web服务器是我们每次吃饭的饭店，会话数据就是我们吃饭用的碗筷，要保证每次吃饭都用自己的碗筷的话，我就把餐具存在某一家，并且每次都去这家吃。

不足：

（1）如果有一台web服务器宕机或重启，造成数据丢失，用户操作记录不复存在；

（2）会话标示是应用层的信息，那么负载均衡器要将同一会话请求都保存到同一web服务器上，就需要进行应用层（第七层）的解析，这个开销比第四层的交换要大；

（3）负载均衡器变成了一个有状态的节点，内存消耗会更大，容灾方面会更麻烦。

方案2:session replication

这就好比在每家饭店都放了一套自己的餐具。这时我们的web服务器之间增加了会话数据的同步。

不足：

（1）同步session数据造成网络带宽的开销；

（2）session数很多的话，每台机器用于保存session数据的内容占用会很严重。

方案3:session数据的集中存储

与session replication不同的是web服务器之间没有了session数据的复制，而是把session数据放在了一个集中处理的地方。

不足：

（1）读写session引入了网络操作，存在时延和不稳定性；

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

方案4:cookie based

通过cookie来传递session数据，这就好比我们每次吃饭都把碗筷放在自己身上一样，这样我们去哪家店吃饭就可以随意选择了。

不足：

（1）cookie长度的限制；

（2）安全性；

（3）带宽消耗；

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