ImageVerifierCode 换一换
格式:DOCX , 页数:22 ,大小:233.72KB ,
资源ID:2818024      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/2818024.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(webspheresession.docx)为本站会员(b****6)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

webspheresession.docx

1、webspheresessionHTTP Session 内存到内存复制的拓扑结构引言HTTP 协议本身是“连接 - 请求 - 应答 - 关闭连接”的模式,是一种无状态协议;然而随着 web 动态化的需求,我们往往需要把两次连续的请求关联起来,从而使得客户端和服务端的会话变得有状态。Session 就是满足这种需求的一种实现方式。它的基本原理是服务器端为每一个 session 管理一份会话信息数据。而客户端和服务器端依靠一个全局唯一标示符 sessionID 来访问会话信息数据。当用户访问 web 应用时,服务器端会先检查客户端的请求里是否包含 sessionID,如果没有或者检索不到,服务器

2、端会自动创建一个新的 sessionID,同时开辟数据存储空间, 并且在本次响应中将 sessionID 返回给客户端保存。当服务器端需要开辟数据存储空间时, 一般会在内存中创建相应的数据结构,但在访问量非常大的系统中,session 会占用大量的内存空间,而且系统一旦宕掉或者掉电,所有的会话数据就会丢失,这种事故在电子商务网站中会造成严重的后果。当然也可以将 session 内容存储在数据库中,从而在某种程度上实现持久化,但是这样会增加 I/O 开销,影响系统的性能。在 IBM Websphere Application Server 中提供了两种不同的 session 持久化管理方案,如图

3、 1 所示,分别是1. 使用数据库做 session 持久化管理所有的 session 信息被集中存放于数据库中,2. 内存到内存的复制 所有 session 的信息会存放在各个应用服务器的内存中。图 1. session 持久化管理方案使用数据库存储 session 数据时需要对存储的信息作序列化操作,在某种程度上影响了响应的时间和效率,适用于 session 数据量大,并且对持久化要求比较高的应用场景。在内存到内存的复制方案里,session 管理者可以把最近经常使用的 session 保存在内存里面,极大地降低了获取 session 数据的时间开销,从而满足了对效率和响应时间要求高的应用

4、需求。从内存到内存的 session 复制,一般适用于 session 数据量不大的应用场景。本文将详细介绍内存到内存复制的持久化管理方案。2#九星级会员一路向北发表于 2011-7-5 14:29|只看该作者内存到内存复制内存到内存的 session 复制指的是将 sessions 复制到另一个 WebSphere Application Server 上。在这个模式下,sessions 可以被复制到一个或者多个应用服务器上,从而防止 HTTP Session 单点失败(single point of failure)的发生。Session 复制的目的,是将 session 的信息进行备份保

5、存,以便在服务器发生故障的情况下,session 状态不会丢失,实现 session 的高可用性,从而保证即使有故障发生,也不会影响到客户正在进行的业务,避免造成损失,进而提高客户满意度。目前 WebSphere Application Server 提供了三种复制方式(如图 2 所示): 仅服务器模式:所谓仅服务器,指的是该应用服务器只会存储其他应用服务器的 session 备份,而不会把自己创建的 session 分发并复制到其他应用服务器上。 仅客户机模式:所谓仅客户机,指的是该应用服务器只会把自身的 session 分发并复制到其他应用服务器上,但不会存储其他应用服务器的 sessio

6、n 备份。 客户机和服务器模式:所谓客户机和服务器,指的是该应用服务器既能作为服务器存储其他应用服务器的 session 备份,也能作为客户机把自身的 session 分发并复制到其他应用服务器上。图 2. session 复制模式WebSphere Application Server 默认的是客户机和服务器模式。用户也可以根据需要选择合适的复制模式。目前 WebSphere Application Server 支持两种 session 复制拓扑结构,分别为: 客户机 / 服务器 (Client/Server) 点对点 (Peer-to-Peer)针对这两种拓扑结构,我们将在余下的章节中作

7、详细的介绍。3#九星级会员一路向北发表于 2011-7-5 14:29|只看该作者复制域首先,内存到内存复制功能是通过应用服务器上的数据复制服务实例来实现的,我们要确保这些数据复制服务实例是属于同一个复制域的,否则这些实例相互间就不能进行复制,从而影响内存到内存复制功能的实现。如图 3 所示 , 复制域 Domain1 包含三个成员 Server1,Server2 和 Server3,因此这三个 server 之间能相互进行复制。但是由于 Server4 并不属于复制域 Domain1 里面的成员,因此 Server4 上的 session 不能复制到复制域 Domain1 的成员上,同时也不

8、能备份 Domain1 上成员的 session 信息。图 3. session 复制域其次,属于同一个复制域的所有会话复制都必须具有相同的拓扑结构。如果同一个复制域中的一个会话管理实例使用的是客户机 / 服务器拓扑结构,则其余所有的会话管理实例只能是“仅服务器”模式或者“仅客户机”模式。相反,如果有一个会话管理实例使用的是点对点的拓扑结构,则其余所有的会话管理实例只能被配置成“客户机和服务器”模式。“仅服务器”模式或者“仅客户机”模式不能与“客户机和服务器”模式共存于同一个复制域里面。在集群环境中,默认采用的是点对点的单备份复制,但是我们也可以在复制域里面修改复制的数量。如图 4 所示,如果

9、副本数选择单个副本,那么 session 只会被备份到一个复制域成员上,如果选择整个域,则 session 就会备份到所有其他复制域成员。当然,我们也可以根据实际需要来指定复制的副本数目。图 4. 复制域配置4#九星级会员一路向北发表于 2011-7-5 14:32|只看该作者内存到内存复制拓扑结构:点对点图 5 是一个点对点复制的拓扑结构图。在这个结构图中,每一个复制域成员都把 session 的信息保存在自己的内存中。同时它也会把 session 的备份信息发送并保存到其他复制域成员上,同时,它也从其他的复制域成员上获取 session 的信息。在这种情况下,每个复制域成员既可以作为一个客

10、户端,从其他的复制域成员上获取 session 的信息;也可以作为服务端,把自身 session 的信息存储到其他复制域成员上。也就是说,每个复制域成员的复制模式都是“客户机和服务器”。图 5. 点对点复制的拓扑结构图在这种配置方式下,不同的服务端之间的关系是平等的,而且需要最少的服务器进程,因此它代表了最牢固的拓扑结构。尤其当各个节点具有相同的性能(CPU,内存等等)和处理相同数量的工作时,该拓扑结构可以达到最稳定的实施。点对点复制的拓扑结构的优势是不需要额外的进程和产品来避免单点失败,从而减少了配置和维持额外进程或产品的时间和费用的成本。但这个拓扑结构的局限性就是它需要占用一定的内存空间,

11、因为每个服务端都需要备份这个复制域里所有 session 的信息。假如一个 session 需要 10KB 的空间来存储信息,那么当 100 万个用户同时登陆到这个系统中时,每个应用服务器就需要花费 10GB 的内存空间来保存所有 session 的信息。它的另一个局限性是每一个 session 信息的修改都会被复制到其他所有的应用服务器上,这极大地影响了整个系统的性能。在 Websphere Application Server V7 开始支持 session 热故障恢复 (session hot failover) 功能。这个功能只适用于点到点复制模式。在集群环境中,session aff

12、inity 会把客户的所有后续请求分发到同一台应用服务器上。启用这一特性之后,如果运行某个实例的服务端突然宕掉,那么 Websphere Application Server plug-in 就会把其后续请求转发到集群环境中其他合适的服务端上。对于设置成点到点复制模式的集群来说,这个新特性可以触发插件程序,从而让保存这些 session 备份的复制域成员来直接接管宕掉的复制域成员的工作,这样可以减少从另一个复制域成员那里再次获取 session 备份的开销。5#九星级会员一路向北发表于 2011-7-5 14:42|只看该作者内存到内存复制拓扑结构:客户机 / 服务器“客户机 / 服务器”拓扑

13、就是把集群中的复制域成员分别设置成“仅服务器”模式或者“仅客户机”模式。这种拓扑可以把备份数据和本地数据分离开来,所有“仅客户机”成员共享“仅服务器”成员上 session 备份,减少了单个复制域成员的复制开销。拿“仅客户机”成员来说,它就不用再负责为别的成员进行 session 备份,可以有更多的资源来运行业务;而对于“仅服务器”成员来说,它只负责备份 session,不需要处理业务,其上不需要部署任何应用程序。图 6 描述的就是“客户机 / 服务器”拓扑结构。图 6. 客户机 / 服务器复制的拓扑结构图这种拓扑结构的优势是它明确区分了客户机和服务器的角色。“仅服务器”成员将所有的 sess

14、ion 信息保存在内存中,而“仅客户机”成员专门处理业务。这样可以减少每个客户机的内存开销和性能影响。所有“仅客户机”成员可以共享“仅服务器”成员,当有“仅服务器”成员且数据有多余两个以上的备份时,就可以实现故障恢复的目的。在实际操作中,我们推荐使用多个备份服务器从而减少单点错误的发生。6#九星级会员一路向北发表于 2011-7-5 14:47|只看该作者两种复制拓扑的比较在前面两个章节中,我们分别介绍了点到点和客户机 / 服务器两种复制拓扑结构的原理及其优势和局限性,在本章节中,我们将进一步比较这两种复制拓扑。对比条目客户机 / 服务器点对点定义通常来说,使用这种方式,是为了在 sessio

15、n 副职的情况下更好地保持 session affinity。在这种拓扑结构中, 一部分复制域成员叫做客户机,其上运行的是产生 HTTP session 的 web 应用,当 session 创建或者更新时,被复制出去。 另一部分复制域成员叫做服务器,上面没有部署 web 应用,但是它的 session 管理器接收从客户机来的 session 信息,并对其进行备份。缺省设置。每个复制域成员可以: 部署使用 HTTP session 的 web 应用 分发 session 信息给其他成员 接收其他复制域成员发来的 session 备份设置方法每个复制域成员的复制方式,要么是“仅服务器”,要么是“仅客户机”。所有复制域成员的复制方式是“客户机和服务器”复制域中各节点复制功能每一个复制域成员,要么仅作为服务器,只为别的成员存储 session 备份,要么仅作为客户机,把自己的 session 发到服务器段进行备份。每一个复制域成员既把自己的 session 发给其他所有成员进行备份,同时又为其他所有成员备份 sessi

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1