webspheresessionWord格式.docx
《webspheresessionWord格式.docx》由会员分享，可在线阅读，更多相关《webspheresessionWord格式.docx（22页珍藏版）》请在冰豆网上搜索。
在IBMWebsphereApplicationServer中提供了两种不同的session持久化管理方案，如图1所示，分别是
1.使用数据库做session持久化管理——所有的session信息被集中存放于数据库中，
2.内存到内存的复制——所有session的信息会存放在各个应用服务器的内存中。
图1.session持久化管理方案
使用数据库存储session数据时需要对存储的信息作序列化操作，在某种程度上影响了响应的时间和效率，适用于session数据量大，并且对持久化要求比较高的应用场景。
在内存到内存的复制方案里，session管理者可以把最近经常使用的session保存在内存里面，极大地降低了获取session数据的时间开销，从而满足了对效率和响应时间要求高的应用需求。
从内存到内存的session复制，一般适用于session数据量不大的应用场景。
本文将详细介绍内存到内存复制的持久化管理方案。
2#
九星级会员
一路向北发表于2011-7-514:
29
|
只看该作者
内存到内存复制
内存到内存的session复制指的是将sessions复制到另一个WebSphereApplicationServer上。
在这个模式下，sessions可以被复制到一个或者多个应用服务器上，从而防止HTTPSession单点失败（singlepointoffailure）的发生。
Session复制的目的，是将session的信息进行备份保存，以便在服务器发生故障的情况下，session状态不会丢失，实现session的高可用性，从而保证即使有故障发生，也不会影响到客户正在进行的业务，避免造成损失，进而提高客户满意度。
目前WebSphereApplicationServer提供了三种复制方式（如图2所示）：
∙仅服务器模式：
所谓仅服务器，指的是该应用服务器只会存储其他应用服务器的session备份，而不会把自己创建的session分发并复制到其他应用服务器上。
∙仅客户机模式：
所谓仅客户机，指的是该应用服务器只会把自身的session分发并复制到其他应用服务器上，但不会存储其他应用服务器的session备份。
∙客户机和服务器模式：
所谓客户机和服务器，指的是该应用服务器既能作为服务器存储其他应用服务器的session备份，也能作为客户机把自身的session分发并复制到其他应用服务器上。
图2.session复制模式
WebSphereApplicationServer默认的是客户机和服务器模式。
用户也可以根据需要选择合适的复制模式。
目前WebSphereApplicationServer支持两种session复制拓扑结构，分别为：
∙客户机/服务器（Client/Server）
∙点对点（Peer-to-Peer）
针对这两种拓扑结构，我们将在余下的章节中作详细的介绍。
3#
复制域
首先，内存到内存复制功能是通过应用服务器上的数据复制服务实例来实现的，我们要确保这些数据复制服务实例是属于同一个复制域的，否则这些实例相互间就不能进行复制，从而影响内存到内存复制功能的实现。
如图3所示,复制域Domain1包含三个成员Server1，Server2和Server3，因此这三个server之间能相互进行复制。
但是由于Server4并不属于复制域Domain1里面的成员，因此Server4上的session不能复制到复制域Domain1的成员上，同时也不能备份Domain1上成员的session信息。
图3.session复制域
其次，属于同一个复制域的所有会话复制都必须具有相同的拓扑结构。
如果同一个复制域中的一个会话管理实例使用的是客户机/服务器拓扑结构，则其余所有的会话管理实例只能是“仅服务器”模式或者“仅客户机”模式。
相反，如果有一个会话管理实例使用的是点对点的拓扑结构，则其余所有的会话管理实例只能被配置成“客户机和服务器”模式。
“仅服务器”模式或者“仅客户机”模式不能与“客户机和服务器”模式共存于同一个复制域里面。
在集群环境中，默认采用的是点对点的单备份复制，但是我们也可以在复制域里面修改复制的数量。
如图4所示，如果副本数选择单个副本，那么session只会被备份到一个复制域成员上，如果选择整个域，则session就会备份到所有其他复制域成员。
当然，我们也可以根据实际需要来指定复制的副本数目。
图4.复制域配置
4#
32
内存到内存复制拓扑结构：
点对点
图5是一个点对点复制的拓扑结构图。
在这个结构图中，每一个复制域成员都把session的信息保存在自己的内存中。
同时它也会把session的备份信息发送并保存到其他复制域成员上，同时，它也从其他的复制域成员上获取session的信息。
在这种情况下，每个复制域成员既可以作为一个客户端，从其他的复制域成员上获取session的信息；
也可以作为服务端，把自身session的信息存储到其他复制域成员上。
也就是说，每个复制域成员的复制模式都是“客户机和服务器”。
图5.点对点复制的拓扑结构图
在这种配置方式下，不同的服务端之间的关系是平等的，而且需要最少的服务器进程，因此它代表了最牢固的拓扑结构。
尤其当各个节点具有相同的性能（CPU，内存等等）和处理相同数量的工作时，该拓扑结构可以达到最稳定的实施。
点对点复制的拓扑结构的优势是不需要额外的进程和产品来避免单点失败，从而减少了配置和维持额外进程或产品的时间和费用的成本。
但这个拓扑结构的局限性就是它需要占用一定的内存空间，因为每个服务端都需要备份这个复制域里所有session的信息。
假如一个session需要10KB的空间来存储信息，那么当100万个用户同时登陆到这个系统中时，每个应用服务器就需要花费10GB的内存空间来保存所有session的信息。
它的另一个局限性是每一个session信息的修改都会被复制到其他所有的应用服务器上，这极大地影响了整个系统的性能。
在WebsphereApplicationServerV7开始支持session热故障恢复（sessionhotfailover）功能。
这个功能只适用于点到点复制模式。
在集群环境中，sessionaffinity会把客户的所有后续请求分发到同一台应用服务器上。
启用这一特性之后，如果运行某个实例的服务端突然宕掉，那么WebsphereApplicationServerplug-in就会把其后续请求转发到集群环境中其他合适的服务端上。
对于设置成点到点复制模式的集群来说，这个新特性可以触发插件程序，从而让保存这些session备份的复制域成员来直接接管宕掉的复制域成员的工作，这样可以减少从另一个复制域成员那里再次获取session备份的开销。
5#
42
客户机/服务器
“客户机/服务器”拓扑就是把集群中的复制域成员分别设置成“仅服务器”模式或者“仅客户机”模式。
这种拓扑可以把备份数据和本地数据分离开来，所有“仅客户机”成员共享“仅服务器”成员上session备份，减少了单个复制域成员的复制开销。
拿“仅客户机”成员来说，它就不用再负责为别的成员进行session备份，可以有更多的资源来运行业务；
而对于“仅服务器”成员来说，它只负责备份session，不需要处理业务，其上不需要部署任何应用程序。
图6描述的就是“客户机/服务器”拓扑结构。
图6.客户机/服务器复制的拓扑结构图
这种拓扑结构的优势是它明确区分了客户机和服务器的角色。
“仅服务器”成员将所有的session信息保存在内存中，而“仅客户机”成员专门处理业务。
这样可以减少每个客户机的内存开销和性能影响。
所有“仅客户机”成员可以共享“仅服务器”成员，当有“仅服务器”成员且数据有多余两个以上的备份时，就可以实现故障恢复的目的。
在实际操作中，我们推荐使用多个备份服务器从而减少单点错误的发生。
6#
47
两种复制拓扑的比较
在前面两个章节中，我们分别介绍了点到点和客户机/服务器两种复制拓扑结构的原理及其优势和局限性，在本章节中，我们将进一步比较这两种复制拓扑。
对比条目
定义
通常来说，使用这种方式，是为了在session副职的情况下更好地保持sessionaffinity。
在这种拓扑结构中，
∙一部分复制域成员叫做客户机，其上运行的是产生HTTPsession的web应用，当session创建或者更新时，被复制出去。
∙另一部分复制域成员叫做服务器，上面没有部署web应用，但是它的session管理器接收从客户机来的session信息，并对其进行备份。
缺省设置。
每个复制域成员可以：
∙部署使用HTTPsession的web应用
∙分发session信息给其他成员
∙接收其他复制域成员发来的session备份
设置方法
每个复制域成员的复制方式，要么是“仅服务器”，要么是“仅客户机”。
所有复制域成员的复制方式是“客户机和服务器”
复制域中各节点复制功能
每一个复制域成员，要么仅作为服务器，只为别的成员存储session备份，要么仅作为客户机，把自己的session发到服务器段进行备份。
每一个复制域成员既把自己的session发给其他所有成员进行备份，同时又为其他所有成员备份sessi
升级会员 