随着电子商务的发展，J2EE 应用越来越广泛。当用户在页面之间跳转的时候大多数 J2EE 应用都需要保持用户的相关会话信息。HTTP session 是实现这一需求的常用方案。IBM Websphere Application Server V7 集群环境中也实现了对 HTTP session 的支持，除此之外，它还提供了 HTTP session 的持久化机制，以实现 HTTP session 的高可用性和高可靠性――这在一些 J2EE 应用中非常关键。
众所周知，ＨＴＴＰ是一个无状态的协议。客户端向服务器发出一个请求，服务器响应这个请求并返回给客户端，如此而已。无论是客户端还是服务器端都不记录请求 / 响应历史信息。随着电子商务的发展，保持请求之前的状态 / 记录成为一个非常常见的需求。HTTP Session 由此应运而生。
一个 HTTP Session 是指同一用户在同一浏览器上对 服务器 发出的一系列请求。HTTP Session 使得运行在 Web container 上的应用能够跟踪记录每个用户的一系列操作。一个典型的 HTTP session 应用场景是提供给在线购物者的“购物车”: 假设服务器旨在记录每个购物者要从 Web 站点购买的商品，服务器 能够将入网请求与特定购物者关联，这是很重要的。否则 , 服务器可能会错误地将客户１的购物选择添加到客户２的购物车里。
服务器通过用户的唯一 session id（会话标识）来区别用户。当一个客户请求过来的时候，服务器会检查这个请求是否带有 session id，如果已包含一个 session id 则说明以前为此客户端已经创建过 session；反之，则为此客户端创建一个 session 并且生成一个与此 session 相关联的 session id，服务器端会保存 session 的所有相关信息而客户端只保存自己的 session id。
WebSphere Application Server V7 cluster（集群）是多个运行着同样企业应用的 WebSphere Application Server 的集合，这些服务器被逻辑的组合在一起以完成工作负载均衡及高可靠性需求。如图 1 所示 :
图 1. WebSphere Application Server V7 Cluster（集群）
在集群环境中用户的请求会根据你设置的工作负载配置策略动态的分发到不同的应用服务器上。如前文所述，HTTP Session 的信息是存放在服务器端的 , 在集群环境下，某台 WebSphere Application Server 可能只存放了某个 session 的信息，因此如果用户的请求被分发到了没有保存其 session 信息的应用服务器上时，用户的 session 信息就会丢失。对一些如在线交易的系统，session 的信息非常重要，它可能保存了用户前边几页提交的信息，session 信息丢失意味着用户需要重新填写前面几页的信息，这种情况通常对用户是难以接受的。所谓 Session Affinity 是指客户的所有后续请求都会被分发到同一台应用服务器上。通过 Session Affinity，系统的性能会得到提高，因为各个应用服务器不需要重新创建和维护 session 信息，而且这样也避免了前面 session 丢失的情况。Session Affinity 默认在 WebSphere Application Server V7 集群中是启用的。在 WebSphere Application Server V7 集群中，每个 WebSphere Application Server 都有自己的 clone ID，这些 clone ID 被记录在 plugin-cfg.xml 中，如清单 1 所示：
<? xml version="1.0" encoding="ISO-8859-1"?> <Config ASDisableNagle="false" IISDisableNagle="false" IgnoreDNSFailures="false" RefreshInterval="60" ResponseChunkSize="64" AcceptAllContent="false" IISPluginPriority="High" FIPSEnable="false" AppServerPortPreference="HostHeader" VHostMatchingCompat="false" ChunkedResponse="false"> <Log LogLevel="Error" Name="C:IBMHTTPServerPlugins logswebserver01http_plugin.log" /> <Property Name="ESIEnable" Value="true" /> <Property Name="ESIMaxCacheSize" Value="1024" /> <Property Name="ESIInvalidationMonitor" Value="false" /> <VirtualHostGroup Name="default_host"> <VirtualHost Name="*:9080" /> <VirtualHost Name="*:80" /> <VirtualHost Name="*:9443" /> <VirtualHost Name="*:5060" /> <VirtualHost Name="*:5061" /> <VirtualHost Name="*:443" /> <VirtualHost Name="*:9081" /> <VirtualHost Name="*:9444" /> </VirtualHostGroup> <ServerCluster CloneSeparatorChange="false" LoadBalance="Round Robin" PostBufferSize="64" IgnoreAffinityRequests="true" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60"> <Server CloneID="13u6hqmf8" ConnectTimeout="0" ExtendedHandshake="false" ServerIOTimeout="0" LoadBalanceWeight="2" MaxConnections="-1" WaitForContinue="false"> <Transport Hostname="was7host01" Port="9080" Protocol="http" /> <Transport Hostname="was7host01" Port="9443" Protocol="https"> <Property name="keyring" value="C:IBMHTTPServerPluginsetcplugin-key.kdb" /> <Property name="stashfile" value="C:IBMHTTPServerPluginsetcplugin-key.sth" /> </Transport> </Server> 。。。。。。。。。。。。。。。。 |
通过 Plug-in，Web 服务器可以看到所有的 WebSphere Application Server，并且可以通过请求中的 session id 信息找到正确的 WebSphere Application Server，以实现 Session Affinity。
启用了 Session Affinity，Session 信息就永远不可能丢失吗？答案是否定的：试想如果这台应用服务器发生了宕机，在集群环境下，用户的请求同样需要被分发到其他应用服务器上，那么在这种情况下，如何避免 session 信息丢失呢？这就需要下边介绍的 session 持久化管理。
Session 信息默认保存在某个应用服务器的内存中，因此，当这台应用服务器发生问题时 session 的信息就会丢失。为了解决这个问题，在 WebSphere Application ServerV7 集群环境下，用户可以选择把 session 的信息做持久化管理。这里用户有两个选择：使用数据库或者使用应用服务器之间内存到内存的复制。用户需要登录 Deploy Manager( 中央管理节点 ) 的管理控制台对 cluster 中的每个 WebSphere Application Server 逐一做 session 持久化管理配置。如图 2 所示 :
使用数据库做 session 持久化管理意味着所有的 session 信息被集中存放于数据库中：
选择数据库做 session 持久化管理，用户需要提前创建好数据源（Data Source），点击图 4 中的“数据库”链接，填写好数据源的信息：
使用数据库做 session 持久化管理是大多数用户的选择，通常情况下它的性能也要好于内存到内存的复制方案。当然如果你选择了这种方案，意味着你要承担维护数据库的成本：软件、硬件甚至你需要额外的数据库管理员。在这种方案下，数据库的宕机会影响到所有 session 的信息，因此用户还需要承担数据库的高可靠性维护。
内存到内存的复制意味着所有 session 的信息会存放在各个应用服务器的内存中：
如果选择内存到内存的复制做为你的 session 持久化管理方案，你需要提前配置好 Replication Domain（复制域），默认的，在 WebSphere Application Server V7 中当你创建 cluster( 集群 ) 后系统会自动为你生成一个跟 cluster( 集群 ) 同名的复制域。也可以通过点击“环境’－》”复制域“来修改复制域的设置或者创建新的复制域：
定义好了复制域，随后就可以对每个 Cluster（集群）成员进行内存到内存的配置：
图 7 中有三种复制方式可以选择：客户机和服务器，仅客户机，仅服务器。在内存到内存复制方案中，客户机方式意味着本应用服务器仅把自己的 session 信息发送到复制域的其他成员中，但不会接收和保存复制域其他成员的 session 信息。服务器方式意味着不把自己的 session 信息发送给复制域的其他成员，但接收和保存来自复制域其他成员的 session 信息。而客户机和服务器方式意味着在把自己的 session 信息发送给复制域其他成员的同时也接收和保存来自复制域其他成员的 session 信息。
内存到内存的复制对很多应用来说也是不错的选择。这种方案的优势是你不需要额外的数据库的投入，但是如果你的 session 信息很大，而且并发用户很多的话，这种方案会对性能产生一定影响。
选择好了使用哪种方式做 session 持久化方案，随之而来的一个问题就是多长时间做一次持久化 / 同步？把所有的 session 信息都同步还是仅同步更新的部分？图 8 可以选择和调整相应的参数：
图 8 中从上到下分别在高性能和高可靠性之间进行取舍：选择“非常高”会带来性能的极大提高，但是其高可靠性程度会相应降低；而“低”会给客户带来极大的高可靠性，但相应的由于同步频率的增大和同步内容的增加，会给集群中成员的性能带来一定负面影响。因此，用户需要根据自己的应用情况，在高性能和高可靠性之间进行权衡，当然，你也可以通过“定制设置”，定制适合自己的参数。
本文介绍了如何在 WebSphere Application Server V7 集群环境中管理 HTTP session，包括 HTTP session 的简介，Session Affinity，如何做 session 持久化管理，WebSphere Application Server 中支持的两种 session 持久化方案及它们的优缺点。本文最后还简单介绍了如何对 session 持久化管理方案进行调优，以满足用户高性能及高可靠性的需要。