1. 什么是会话保持？

会话保持是负载均衡最常见的问题之一，也是一个相对比较复杂的问题。会话保持有时候又叫做粘滞会话(Sticky Sessions)。会话保持是指在负载均衡器上的一种机制，可以识别客户端与服务器之间交互过程的关连性，在作负载均衡的同时还保证一系列相关连的访问请求会分配到一台服务器上｡

2. 什么是Session

在WEB开发中，服务器可以为每个用户浏览器创建一个会话对象（session对象），注意：一个浏览器独占一个session对象(默认情况下)。因此，在需要保存用户数据时，服务器程序可以把用户数据写到用户浏览器独占的session中，当用户使用浏览器访问其它程序时，其它程序可以从用户的session中取出该用户的数据，为用户服务。

2.1 Connection与Session的区别

在讨论这个问题前，我们必须先花点时间弄清楚一些概念：什么是连接（Connection）、什么是会话（Session），以及这二者之间的区别。需要特别强调的是，如果我们仅仅是谈论负载均衡，会话和连接往往具有相同的含义。

从简单的角度来看，如果用户需要登录，那么就可以简单的理解为会话；如果不需要登录，那么就是连接。

2.2 Cookie与Session的区别

  • Cookie是把用户的数据写给用户的浏览器。
  • Session保存在服务端。

2.3 Session的原理

2.3.1 基于Cookie实现

服务器创建session出来后，会把session的id号，以cookie的形式回写给客户机，这样，只要客户机的浏览器不关，再去访问服务器时，都会带着session的id号去，服务器发现客户机浏览器带session id过来了，就会使用内存中与之对应的session为之服务。可以用如下的代码证明：

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

public class SessionDemo1 extends HttpServlet {

    public void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {

        response.setCharacterEncoding("UTF=8");
        response.setContentType("text/html;charset=UTF-8");
        //使用request对象的getSession()获取session，如果session不存在则创建一个
        HttpSession session = request.getSession();
        //将数据存储到session中
        session.setAttribute("data", "孤傲苍狼");
        //获取session的Id
        String sessionId = session.getId();
        //判断session是不是新创建的
        if (session.isNew()) {
            response.getWriter().print("session创建成功，session的id是："+sessionId);
        }else {
            response.getWriter().print("服务器已经存在该session了，session的id是："+sessionId);
        }
    }

    public void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        doGet(request, response);
    }
}

第一次访问时，服务器会创建一个新的sesion，并且把session的Id以cookie的形式发送给客户端浏览器，如下图所示：

Service 会话保持机制Session Affinity_会话保持

点击刷新按钮，再次请求服务器，此时就可以看到浏览器再请求服务器时，会把存储到cookie中的session的Id一起传递到服务器端了，如下图所示：

Service 会话保持机制Session Affinity_Cookie_02

2.3.2 基于URL重写实现

所谓URL重写，顾名思义就是重写URL。试想，在返回用户请求的页面之前，将页面内所有的URL后面全部以get参数的方式加上session标识符（或者加在path info部分等等），这样用户在收到响应之后，无论点击哪个链接或提交表单，都会在再带上session的标识符，从而就实现了会话的保持。读者可能会觉得这种做法比较麻烦，确实是这样，但是，如果客户端禁用了cookie的话，URL重写将会是首选：

  • response.encodeRedirectURL(java.lang.String url) 用于对sendRedirect方法后的url地址进行重写
  • response.encodeURL(java.lang.String url)用于对表单action和超链接的url地址进行重写

先禁用浏览器的cookie功能，再查看返回页面html代码可以看到，每一个超链接后面都带上了session的Id，如下所示：

本网站有如下书：<br/>javaweb开发   <a href='/JavaWeb_Session_Study_20140720/servlet/BuyServlet;jsessionid=96BDFB9D87A08D5AB1EAA2537CDE2DB2?id=1'>购买</a><br/>
spring开发   <a href='/JavaWeb_Session_Study_20140720/servlet/BuyServlet;jsessionid=96BDFB9D87A08D5AB1EAA2537CDE2DB2?id=2'>购买</a><br/>
hibernate开发   <a href='/JavaWeb_Session_Study_20140720/servlet/BuyServlet;jsessionid=96BDFB9D87A08D5AB1EAA2537CDE2DB2?id=3'>购买</a><br/>
struts开发   <a href='/JavaWeb_Session_Study_20140720/servlet/BuyServlet;jsessionid=96BDFB9D87A08D5AB1EAA2537CDE2DB2?id=4'>购买</a><br/>
ajax开发   <a href='/JavaWeb_Session_Study_20140720/servlet/BuyServlet;jsessionid=96BDFB9D87A08D5AB1EAA2537CDE2DB2?id=5'>购买</a><br/>

所以，当浏览器禁用了cookie后，就可以用URL重写这种解决方案解决Session数据共享问题。而且response. encodeRedirectURL(java.lang.String url) 和response. encodeURL(java.lang.String url)是两个非常智能的方法，当检测到浏览器没有禁用cookie时，那么就不进行URL重写了。

3. 什么时候需要会话保持？

比如在某些要求登录状态的情境下，要求客户端和服务器之间保持一个会话（session）以记录客户端的各种信息。比如在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中，一个客户与服务器经常经过好几次的交互过程才能完成一笔交易或者是一个请求的完成。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时往往需要了解上一次或上几次的交互过程处理结果，这就要求所有这些相关的交互过程都由一台服务器完成，而不能被负载均衡器分散到不同的服务器上｡否则可能出现异常情景：

  • 客户端输入了正确的用户名和口令，但却反复跳到登录页面；
  • 用户输入了正确的验证码，但是总提示验证码错误；
  • 客户端放入购物车的物品丢失
  • …

因此会话保持机制的意义就在于，确保在合适的情境下，将来自相同客户端的请求转发至后端相同的服务器进行处理。换句话说，就是将客户端与服务器之间建立的多个连接，都发送到相同的服务器进行处理。如果在客户端和服务器之间部署了负载均衡设备，很有可能这多个连接会被转发至不同的服务器进行处理。如果服务器之间没有会话信息的同步机制，会导致其他服务器无法识别用户身份，造成用户在和应用系统发生交互时出现异常。

4. 会话保持的分类

4.1 基于源地址的会话保持

基于源地址的会话保持/基于IP的会话保持 是指负载均衡器在作负载均衡时根据访问请求的源地址作为判断关连会话的依据。对来自同一IP地址的所有访问请求在作负载均时都会被保持到一台服务器上去｡

简单会话保持中一个很重要的参数就是连接超时值，负载均衡器会为每一个处于保持状态中的会话设定一个时间值。若一个会话从上一次完成到下次再来之间的间隔时间小于超时值时，负载均衡器将会将新的连接进行会话保持；但如果这个间隔大于该超时值，负载均衡器会将新来的连接认为是新的会话然后进行负载平衡。

Service 会话保持机制Session Affinity_粘连会话_03

简单会话保持实现简单，只需要根据数据包三､四层的信息就可以实现，效率比较高｡

缺点：

  • 但此种方式存在的问题就在于，当多个客户端通过代理或地址转换的方式访问服务器时，由于来源地址一样，请求都被分配到同一台服务器上，会导致服务器之间的负载严重失衡。
  • 另外一种情况是，同一个客户端产生大量并发，要求分配到多个服务器上处理的同时进行会话保持。这时基于客户端源地址的会话保持方法也会导致负载均衡失效。

以上情况出现时，就必须要考虑使用其他的会话保持方式。

4.2 共享session的会话保持

此种方式通过多个后端服务器共享session的方式，实现与负载均衡同时的会话保持。主要有以下几种形式：

（1）数据库存放

Session信息存储到数据库表以实现不同应用服务器间Session信息的共享。此种方式适合数据库访问量不大的网站。

  • 优点：实现简单
  • 缺点：由于数据库服务器相对于应用服务器更难扩展且资源更为宝贵，在高并发的Web应用中，最大的性能瓶颈通常出现在数据库服务器。因此如果将 Session存储到数据库表，频繁的数据库操作会影响业务。

（2） 文件系统存放

通过文件系统（比如NFS）来实现各台服务器间的Session共享。此种方式适合并发量不大的网站。

  • 优点：各台服务器只需要mount存储Session的磁盘即可，实现较为简单。
  • 缺点：NFS对高并发读写的性能并不高，在硬盘I/O性能和网络带宽上存在较大瓶颈，尤其是对于Session这样的小文件的频繁读写操作。

（3） Memcached/Redis存放

利用Memcached来保存Session数据，直接通过内存的方式读取。

  • 优点：效率高，在读写速度上会比存放在文件系统时快很多，而且多个服务器共用Session也更加方便，将这些服务器都配置成使用同一组memcached服务器就可以，减少了额外的工作量。
  • 缺点：一旦宕机内存中的数据将会丢失，但对Session数据来说并不是严重的问题。如果网站访问量太大、Session太多的时候memcached会将不常用的部分删除，但是如果用户隔离了一段时间之后继续使用，将会发生读取失败的问题。

4.3 基于cookie的会话保持

在基于cookie模式下负载均衡器负责插入cookie，后端服务器无需作出任何修改。当客户端进行第一次请求时，客户端的HTTP request（不带cookie）进入负载均衡器， LB根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器；后端服务器的HTTP response（不带cookie）被发回给负载均衡器。接下来负载均衡器将向Response插入Cookie，并将HTTP response返回到客户端。

当客户请求再次发生时，客户HTTP request（带有上次负载均衡器插入的cookie）进入LB，然后LB读出cookie里的会话保持数值，将HTTP request（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复；由于服务器并不写入cookie，HTTP response将不带cookie，该HTTP response再次经过进入LB时，LB将写入更新后的会话保持cookie。

Service 会话保持机制Session Affinity_会话保持_04