Webx学习笔记(八)Request Context之Session

标签：

1 Session概述

      HTTP协议是无状态的，但通过session机制，就能把无状态的变成有状态的。Session的功能就是保存HTTP请求之间的状态数据。有了session的支持，就很容易实现诸如用户登录、购物车等网站功能。在Servlet API中，有一个HttpSession的接口。

     在Java代码中访问session

//在一个请求中，保存session的状态

// 取得session对象
HttpSession session = request.getSession();

// 在session中保存用户状态
session.setAttribute("loginId", "myName");



//在另一个请求中，取出session的状态：

// 得到"myName"
String myName = (String) session.getAttribute("loginId");  

Session数据存储

1）保存在应用服务器的内存中

     一般的做法，是将session对象保存在内存里。同一时间，会有很多session被保存在服务器的内存里。由于内存是有限的，较好的服务器会把session对象的数据交换到文件中，以确保内存中的session数目保持在一个合理的范围内。

      为了提高系统扩展性和可用性，我们会使用集群技术 —— 就是一组独立的机器共同运行同一个应用。对用户来讲，集群相当于一台“大型服务器”。而实际上，同一用户的两次请求可能被分配到两台不同的服务器上来处理。这样一来，怎样保证两次请求中存取的session值一致呢？

      一种方法是使用session复制：当session的值被改变时，将它复制到其它机器上。以广播的方式随时保持着服务器同步，网络负担重，不具备高度可扩展性。

      另一种方法是TCP-Ring的方式，也就是把集群中所有的服务器看成一个环，A→B→C→D→A，首尾相接。缺点：一是配置复杂；二是每增添/减少一台机器时，ring都需要重新调整，这将成为性能瓶颈；三是要求前端的Load Balancer具有相当强的智能，才能将用户请求分发到正确的机器上。

2）保存在单一数据源中

      将session保存在单一的数据源中，这个数据源可被集群中所有的机器所共享。这样一来，就不存在复制的问题了。问题一：然而单一数据源的性能成了问题。每个用户请求，都需要访问后端的数据源（很可能是数据库）来存取用户的数据。二： 很少有应用服务器直接支持这种方案。更不用说数据源有很多种（MySQL、Oracle、Hsqldb等各种数据库、专用的session server等）了。三：数据源成了系统的瓶颈，一但这个数据源崩溃，所有的应用都不可能正常运行了。

3）保存在客户端

      把session保存在客户端。这样一来，由于不需要在服务器上保存数据，每台服务器就变得独立，能够做到线性可扩展和极高的可用性。

     具体怎么做呢？目前可用的方法，恐怕就是保存在cookie中了。但需要提醒的是，cookie具有有以下限制，因此不可无节制使用该方案：

     虽然有上述缺点，但是对于其优点（极高的扩展性和可用性）来说，就显得微不足道。可以用下面的方法来回避上述的缺点：

4）将客户端、服务器端组合的方案

     任何一种session方案都有其优缺点。最好的方法是把它们结合起来。这样就可以弥补各自的缺点。

     将大部分session数据保存在cookie中，将小部分关键和涉及安全的数据保存在服务器上。由于我们只把少量关键的信息保存在服务端，因而服务器的压力不会非常大。在服务器上，单一的数据源比复制session的方案，更简单可靠。我们可以使用数据库来保存这部分session，也可以使用更廉价、更简单的存储，例如Berkeley DB就是一种不错的服务器存储方案。将session数据保存在cookie和Berkeley DB（或其它类似存储技术）中，就可以解决我们的绝大部分问题。

通用的session框架

     多数应用服务器并没有留出足够的余地，来让你自定义session的存储方案。纵使某个应用服务器提供了对外扩展的接口，可以自定义session的方案，但是我们希望保留选择应用服务器软件的自由。因此，最好的方案，不是在应用服务器上增加什么新功能，而是在WEB应用框架中实现灵活的session框架，那么我们的应用可以跑在任何标准的JavaEE应用服务器上。

     除此之外，一个好的session框架还应该做到对应用程序透明。具体表现在：

    Webx实现了这种session框架，把它建立在Request Contexts的基础上。

<services:request-contexts xmlns="http://www.alibaba.com/schema/services/request-contexts">
    <buffered />
    <lazy-commit />
    ...
    <session>
        <stores>
            <session-stores:simple-memory-store id="simple" /> 
        </stores>
        <store-mappings>
            <match name="*" store="simple" /> 
        </store-mappings>
    </session>
</services:request-contexts>

2）Session ID

     Session ID唯一标识了一个session对象。把session ID保存在cookie里是最方便的。这样，凡是cookie值相同的所有的请求，就被看作是在同一个session中的请求。在servlet中，还可以把session ID编码到URL中。Session框架既支持把session ID保存在cookie中，也支持把session ID编码到URL中。

     完整的session ID配置如下：

<session>
    <id cookieEnabled="true" urlEncodeEnabled="false">
        <cookie name="JSESSIONID" domain="" maxAge="0" path="/" httpOnly="true" secure="false" />
        <url-encode name="JSESSIONID" />
        <session-idgens:uuid-generator />
    </id>
</session>

　　上面这段配置包含了关于Session ID的所有配置以及默认值。如果不指定上述参数，则系统将使用默认值，其效果等同于上述配置。

response.encodeURL("http://localhost:8080/test.jsp?id=1")

http://localhost:8080/test.jsp;JSESSIONID=xxxyyyzzz?id=1

      为了达到最大的兼容性，我们分两种情况来处理JSESSIONID：

3）Session的生命期

　  session从创建到失效的整个过程。其状态变迁如下图所示：

                                               图 8.1. Session生命期

   总结一下：

      在session框架中，有一个重要的特殊对象，用来保存session生命期的状态。这个对象叫作session model。它被当作一个普通的对象存放在session中，但是通过HttpSession接口不能直接看到它。

      关于session生命期的完整配置如下：

<session maxInactiveInterval="0" keepInTouch="false" forceExpirationPeriod="14400"
         modelKey="SESSION_MODEL">
    ...
</session>

4）Session Store

       Session Store是session框架中最核心的部分。Session框架最强大的部分就在于此。我们可以定义很多个session stores，让不同的session对象分别存放到不同的Session Store中。前面提到有一个特殊的对象“SESSION_MODEL”也必须保存在一个session store中。

                      图 8.2. Session和Stores

      类似于Servlet的配置，Session store的配置也包含两部分内容：session store的定义，和session store的映射（mapping）。

<session>
        <stores>
            <session-stores:store id="store1" /> 
            <session-stores:store id="store2" /> 
            <session-stores:store id="store3" /> 
        </stores>
        <store-mappings>
            <match name="*" store="store1" /> 
            <match name="loginName" store="store2" /> 
            <matchRegex pattern="key.*" store="store3" /> 
        </store-mappings>
    </session>

　　定义session stores：你可以配置任意多个session store，只要ID不重复。此处，store1、store2和store3分别是三个session store的名称。

      映射session stores：match标签用来精确匹配attribute name。一个特别的值是“*”，它代表默认匹配所有的names。本例中， 如果调用session.setAttribute("loginName", user.getId())，那么这个值将被保存到store2里；如果调用session.setAttribute("other", value)将被默认匹配到store1中。

      映射session stores：matchRegexp标签用正则表达式来匹配attribute names。本例中， key_a、key_b等值都将被保存到store3里。

     注意以下几点：

5）Session Model

     Session Model是用来记录当前session的生命期数据的，例如：session的创建时间、最近更新时间等。默认情况下，

{id:"SESSION_ID",ct:创建时间,ac:最近访问时间,mx:最长不活动时间}

     以上转换过程是通过一个SessionModelEncoder接口来实现的。为了提供更好的移植性，Session框架可同时支持多个SessionModelEncoder的实现。配置如下：

<session>
    <session-model-encoders>
        <model-encoders:default-session-model-encoder />
        <model-encoders:model-encoder class="..." />
        <model-encoders:model-encoder class="..." />
    </session-model-encoders>
</session>

　　三个SessionModelEncoder的实现。第一个是默认的实现，第二、第三个是任意实现。

6）Session Interceptor

     Session Interceptor拦截器的作用是拦截特定的事件，甚至干预该事件的执行结果。目前有两种拦截器接口：

     Session框架自身已经提供了两个有用的拦截器：

      可以同时配置多种拦截器，如下所示。

<session>
  <request-contexts:interceptors
        xmlns="http://www.alibaba.com/schema/services/request-contexts/session/interceptors">

    <lifecycle-logger />

    <attribute-whitelist>
      <attribute name="_csrf_token" />
      <attribute name="_lang" />
      <attribute name="loginUser" type="com.alibaba...MyUser" />
      <attribute name="shoppingCart" type="com.alibaba....ShoppingCart" />
    </attribute-whitelist>

    <interceptor class="..." />

  </request-contexts:interceptors>
</session>

Webx学习笔记(八)Request Context之Session

标签：

原文地址：http://www.cnblogs.com/Vae98Scilence/p/4631317.html