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

      什么是Session？

      用户使用网站的服务，比本上需要浏览器与web服务器的多次交互。HTTP协议本省就是无状态的，需要基于HTTP协议支持会话状态（Session State）的机制。而这样的机制应该可以使web服务器从多次单独的HTTP请求中看到“会话”，也就是知道那些请求来自哪个会话的。具体实现方式为：在会话开始时，分配一个唯一的会话标识（SessionId），通过Cookie把这个标识告诉浏览器，以后每次请求的时候，浏览器都会带上这个会话标识来告诉Web服务器请求是属于哪个会话的。在Web服务器上，哥哥会话有独立的存储，保存不同会话的信息。如果遇到禁用Cookie的情况，一般的做法就是把这个会话标识放到URL的参数中。我们可以通过下图，看一下上述过程。

  

      当我们的应用服务器从一台编程两台后，按照上图中的结构，我们就遇到Session的问题了，具体是什么问题呢？

      如下图所以，当一个带有会话标识的HTTP请求到了Web服务器后，需要在HTTP请求的处理过程中找到对应的会话数据（Session）。而问题在于，会话数据是需要保存到单机上的。

     

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

      看看问题的几种解决方法。

      1.Session Sticky

      在单机情况下，会话保存在单机上，请求也都是 由这个机器处理，所以不会有问题。Web服务器贬称多台以后，如果保证同一个会话的请求都在同一个Web服务器上处理，那么对这个会话的个体来说，与之前单机的情况是一样的。

      如果做到这样，就需要负载均衡器能够根据每次请求的会话标识来进行请求转发，如下图所示，称为Session Sticky方式。

      

      这个方案本身非常简单，对于Web服务器来说，该方案和单机的情况是一样的，知识我们在负载均衡器上做了“手脚”。这个方案可以让同样Session的请求每次都发送到同意个服务器端处理，非常利于针对Session进行服务器端本地的缓存。不多也带来如下几个问题：

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

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

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

      这种方式我们成为Session Sticky。打个比方来说，如果说Web服务器使我们每次吃饭的饭店，会话数据就是我们吃饭用的碗筷。要保证每次吃饭都用自己的碗筷的话，我们就把餐具放到某一个餐厅，并且每次吃饭，都去这一个餐厅，是个不错的主意。

      2.Session Replication

      如果我们继续以去饭店吃饭类比，那么出了前面的方式之外，如果我在每个餐厅都存放一套自己的餐具，不就可以更加自由地选择餐厅了吗？ Session Replication就是这样的一种方式，这一点从字面上也很容易看出来。如下图所示。

      

      可以看到，在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。结构如下图。

      

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

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

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

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

      4.Cookie Based

      Cookie Based方案要最后一个解决Session问题的方案。这个方案对于同一个会话的不同请求也是不限制具体处理机器的。和Session Replication以及Session数据集中管理的方案不同，这个方案是通过Cookie来传递Session数据的。结构如下图。

       

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

        Cookie长度的限制。我们都知道Cookie是有长度限制的，而这回限制Session数据的长度。

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

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

        性能影响。每次HTTP请求和相应都应有Session数据，对Web服务器来说，同样的处理情况下，相应的结果输出越少，支持的冰法请求就会越多。

  

      小结

      上面介绍了Web服务器从单机到多机情况下Session问题的解决方案。这4个方案都是可用的方案，不过对于大型网站来说，SessionSticky和Session数据集中存储是比较好的方案，而这两个方案又各有优势，需要在具体场景中做出选择和权衡。

      不管采用上述何种方案，我们都可以在一定程度山刚通过增加Web服务器的方式来提升应用的处理能力。