服务器集群后的session解决方案及优缺点

1.定义：

Session:在计算机中，尤其是在网络应用中，称为“会话控制”。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web 页时，如果该用户还没有会话，则 Web 服务器将自动创建一个 Session 对象。当会话过期或被放弃后，服务器将终止该会话。
当一个带有会话标识的HTTP请求到了Web服务器后,需要在HTTP请求的处理过程中找到对应的会话数据(Session)。而问题就在于,会话数据是需要保存在单机上的。

在图所示的网站中,如果我第一次访问网站时请求落到了左边的服务器,那么我的 Session就创建在左边的服务器上了,如果我们不做处理,就不能保证接下来的请求每次都落在同一边的服务器上了,这就是 Session问题。

---

2.解决方案一：session sticky

使用负载均衡按规则负责判断分发请求，确保相同session请求的应用服务器始终为一个。
缺点：
1.如果有其中一台应用服务器宕机或者重启，其中有登入状态的用户必须重新登录。
2.相比于无状态的负载均衡，如果加上应用逻辑，性能消耗相比更大，容灾方面更难处理。

---

3.解决方案二：session replication

不使用负载均衡进行判断转发，应用间进行session同步
缺点：
1.所有应用服务器之间session同步，加大额外的带宽开销。
2.每台台服务器分别保存所有服务器的session信息，内容占有量大。

---

4.解决方案三：session集中处理

session集中存储在一个服务器上，可选择数据库存储或者其他分布式存储方案。
缺点：
1.加入了网络操作，如果是内网问题不大，如果不是会有延时及网络不稳定的问题。
2.如果存储session的单机或者集群发生故障，影响整个系统。

---

5.解决方案四：cookie传递session

相对于前面的集中存储,这个方案不会依赖外部的一个存储系统,也就不存在从外部系统获取、写入 Session数据的网络时延、不稳定性，单同样存在缺点：
1.Cookie是有长度限制的,而这也会限制 Session数据的长度。
2.安全性。. Session数据本来都是服务端数据,而这个方案是让这些服务端数据到了外部网络及客户端,因此存在安全性上的问题。我们可以对写入 Cookie的Session数据做加密,不过对于安全来说物理上不能接触才是安全的。
3.带宽消耗。这里指的不是内部Web服务器之间的带宽消耗,而是我们数据中心的整体外部带宽的消耗。
4.性能影响。每次HTTP请求和响应都带有数据,对web服务器来说,在同样的处理情况下,响应的结果输出越少支持的并发请求就会越多。