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

转自 http://book.51cto.com/art/201405/439557.htm

先来看一下什么是Session。

用户使用网站的服务，基本上须要浏览器与Web 服务器的屡次交互。HTTP 协议自己是无状态的，须要基于HTTP 协议支持会话状态（Session State）的机制。而这样的机制应该可使Web 服务器从屡次单独的HTTP 请求中看到“会话”，也就是知道哪些请求是来自哪一个会话的。具体实现方式为：在会话开始时，分配一个惟一的会话标识（SessionId），经过Cookie 把这个标识告诉浏览器，之后每次请求的时候，浏览器都会带上这个会话标识来告诉Web 服务器请求是属于哪一个会话的。在Web 服务器上，各个会话有独立的存储，保存不一样会话的信息。若是遇到禁用Cookie 的状况，通常的作法就是把这个会话标识放到URL 的参数中。咱们能够经过图2-8 来看一下上述过程。

 

 

当咱们的应用服务器从一台变到两台后，如同图2-7 中的结构，咱们就会遇到Session的问题了。具体是指什么问题呢？

咱们来看图2-9，当一个带有会话标识的HTTP 请求到了Web 服务器后，须要在HTTP请求的处理过程当中找到对应的会话数据（Session）。而问题就在于，会话数据是须要保存在单机上的。

在图2-9 所示的网站中，若是我第一次访问网站时请求落到了左边的服务器，那么个人Session 就建立在左边的服务器上了，若是咱们不作处理，就不能保证接下来的请求每次都落在同一边的服务器上了，这就是Session 问题。

 

 

咱们看看这个问题的几种解决方案。

1．Session Sticky

在单机的状况下，会话保存在单机上，请求也都是由这个机器处理，因此不会有问题。Web 服务器变成多台之后，若是保证同一个会话的请求都在同一个Web 服务器上处理，那么对这个会话的个体来讲，与以前单机的状况是同样的。

若是要作到这样，就须要负载均衡器可以根据每次请求的会话标识来进行请求转发，如图2-10 所示，称为Session Sticky 方式。

 

 

这个方案自己很是简单，对于Web 服务器来讲，该方案和单机的状况是同样的，只是咱们在负载均衡器上作了“手脚”。这个方案可让一样Session 的请求每次都发送到同一个服务器端处理，很是利于针对Session 进行服务器端本地的缓存。不过也带来了以下几个问题：

若是有一台Web 服务器宕机或者重启，那么这台机器上的会话数据会丢失。如若是会话中有登陆状态数据，那么用户就要从新登陆了。

会话标识是应用层的信息，那么负载均衡器要将同一个会话的请求都保存到同一个Web服务器上的话，就须要进行应用层（第7 层）的解析，这个开销比第4 层的交换要大。负载均衡器变为了一个有状态的节点，要将会话保存到具体Web 服务器的映射。和无状态的节点相比，内存消耗会更大，容灾方面会更麻烦。

这种方式咱们称为Session Sticky。打个比方来讲，若是说Web 服务器是咱们每次吃饭的饭店，会话数据就是咱们吃饭用的碗筷。要保证每次吃饭都用本身的碗筷的话，我就把餐具存在某一家，而且每次都去这家店吃，是个不错的主意。

2．Session Replication

若是咱们继续以去饭店吃饭类比，那么除了前面的方式以外，若是我在每一个店里都存放一套本身的餐具，不就能够更加自由地选择饭店了吗？Session Replication 就是这样的一种方式，这一点从字面上也很容易看出来。

先看一下图2-11，以下。

 

 

能够看到，在Session Replication 方式中，再也不要求负载均衡器来保证同一个会话的屡次请求必须到同一个Web 服务器上了。而咱们的Web 服务器之间则增长了会话数据的同步。经过同步就保证了不一样Web 服务器之间的Session 数据的一致。就如同每家饭店都有个人碗筷，我就能随便选择去哪家吃饭了。

通常的应用容器都支持（包括了商业的和开源的）Session Replication 方式，与Session Sticky 方案相比，Session Replication 方式对负载均衡器没有那么多的要求。不过这个方案自己也有问题，并且在一些场景下，问题很是严重。咱们来看一下这些问题。

同步Session 数据形成了网络带宽的开销。只要Session 数据有变化，就须要将数据同步到全部其余机器上，机器数越多，同步带来的网络带宽开销就越大。

每台Web 服务器都要保存全部的Session 数据，若是整个集群的Session 数不少（不少人在同时访问网站）的话，每台机器用于保存Session 数据的内容占用会很严重。这就是Session Replication 方案。这个方案是靠应用容器来完成Session 的复制从而使得应用解决Session 问题的，应用自己并不用关心这个事情。不过，这个方案不适合集群机器数多的场景。若是只有几台机器，用这个方案是能够的。

3．Session 数据集中存储

一样是但愿同一个会话的请求能够发到不一样的Web 服务器上，刚才的Session Replication是一种方案，还有另外一种方案就是把Session 数据集中存储起来，而后不一样Web 服务器从一样的地方来获取Session。大概的结构如图2-12 所示。

 

 

能够看到，与Session Replication 方案同样的部分是，会话请求通过负载均衡器后，不会被固定在一样的Web 服务器上。不一样的地方是，Web 服务器之间没有了Session 数据复制，而且Session 数据也不是保存在本机了，而是放在了另外一个集中存储的地方。这样，不管是哪台Web 服务器，也不论修改的是哪一个Session 数据，最终的修改都发生在这个集中存储的地方，而Web 服务器使用Session 数据时，也是从这个集中存储Session 数据的地方来读取。这样的方式保证了不一样Web 服务器上读到的Session 数据都是同样的。而存储Session 数据的具体方式，可使用数据库，也可使用其余分布式存储系统。这个方案解决了SessionReplication 方案中内存的问题，而对于网络带宽，这个方案也比Session Replication 要好。该方案存在的问题是什么呢？

读写Session 数据引入了网络操做，这相对于本机的数据读取来讲，问题就在于存在时延和不稳定性，不过咱们的通讯基本都是发生在内网，问题不大。

若是集中存储Session 的机器或者集群有问题，就会影响咱们的应用。

相对于Session Replication，当Web 服务器数量比较大、Session 数比较多的时候，这个集中存储方案的优点是很是明显的。

4．Cookie Based

Cookie Based 方案是要介绍的最后一个解决Session 问题的方案。这个方案对于同一个会话的不一样请求也是不限制具体处理机器的。和Session Replication 以及Session 数据集中管理的方案不一样，这个方案是经过Cookie 来传递Session 数据的。仍是先看看下面的图2-13吧。

从图2-13 能够看到，咱们的Session 数据放在Cookie 中，而后在Web 服务器上从Cookie中生成对应的Session 数据。这就比如我每次都把本身的碗筷带在身上，这样我去哪家饭店吃饭就能够随意选择了。相对于前面的集中存储，这个方案不会依赖外部的一个存储系统，也就不存在从外部系统获取、写入Session 数据的网络时延、不稳定性了。不过，这个方案依然存在不足：

 

 

Cookie 长度的限制。咱们知道Cookie 是有长度限制的，而这也会限制Session 数据的长度。

安全性。Session 数据原本都是服务端数据，而这个方案是让这些服务端数据到了外部网络及客户端，所以存在安全性上的问题。咱们能够对写入Cookie 的Session 数据作加密，不过对于安全来讲，物理上不能接触才是安全的。

带宽消耗。这里指的不是内部Web 服务器之间的带宽消耗，而是咱们数据中心的总体外部带宽的消耗。

性能影响。每次HTTP 请求和响应都带有Session 数据，对Web 服务器来讲，在一样的处理状况下，响应的结果输出越少，支持的并发请求就会越多。