HTTP 协议本身是“连接 - 请求 - 应答 - 关闭连接”的模式,是一种无状态协议;然而随着 web 动态化的需求,我们往往需要把两次连续的请求关联起来,从而使得客户端和服务端的会话变得有状态。Session 就是满足这种需求的一种实现方式。
它的基本原理是服务器端为每一个 session 管理一份会话信息数据。而客户端和服务器端依靠一个全局唯一标示符 —— sessionID 来访问会话信息数据。当用户访问 web 应用时,服务器端会先检查客户端的请求里是否包含 sessionID,如果没有或者检索不到,服务器端会自动创建一个新的 sessionID,同时开辟数据存储空间, 并且在本次响应中将 sessionID 返回给客户端保存。
当服务器端需要开辟数据存储空间时, 一般会在内存中创建相应的数据结构,但在访问量非常大的系统中,session 会占用大量的内存空间,而且系统一旦宕掉或者掉电,所有的会话数据就会丢失,这种事故在电子商务网站中会造成严重的后果。当然也可以将 session 内容存储在数据库中,从而在某种程度上实现持久化,但是这样会增加 I/O 开销,影响系统的性能。
在 IBM Websphere Application Server 中提供了两种不同的 session 持久化管理方案,如图 1 所示,分别是
1.使用数据库做 session 持久化管理 所有的 session 信息被集中存放于数据库中.
2.内存到内存的复制 所有 session 的信息会存放在各个应用服务器的内存中.
使用数据库存储 session 数据时需要对存储的信息作序列化操作,在某种程度上影响了响应的时间和效率,适用于 session 数据量大,并且对持久化要求比较高的应用场景。在内存到内存的复制方案里,session 管理者可以把最近经常使用的 session 保存在内存里面,极大地降低了获取 session 数据的时间开销,从而满足了对效率和响应时间要求高的应用需求。从内存到内存的 session 复制,一般适用于 session 数据量不大的应用场景。本文将详细介绍内存到内存复制的持久化管理方案。
内存到内存复制
内存到内存的 session 复制指的是将 sessions 复制到另一个 WebSphere Application Server 上。在这个模式下,sessions 可以被复制到一个或者多个应用服务器上,从而防止 HTTP Session 单点失败(single point of failure)的发生。
Session 复制的目的,是将 session 的信息进行备份保存,以便在服务器发生故障的情况下,session 状态不会丢失,实现 session 的高可用性,从而保证即使有故障发生,也不会影响到客户正在进行的业务,避免造成损失,进而提高客户满意度。
目前 WebSphere Application Server 提供了三种复制方式(如图 2 所示):
- 仅服务器模式: 所谓仅服务器,指的是该应用服务器只会存储其他应用服务器的 session 备份,而不会把自己创建的 session 分发并复制到其他应用服务器上。
- 仅客户机模式: 所谓仅客户机,指的是该应用服务器只会把自身的 session 分发并复制到其他应用服务器上,但不会存储其他应用服务器的 session 备份。
- 客户机和服务器模式: 所谓客户机和服务器,指的是该应用服务器既能作为服务器存储其他应用服务器的 session 备份,也能作为客户机把自身的 session 分发并复制到其他应用服务器上。
WebSphere Application Server 默认的是客户机和服务器模式。用户也可以根据需要选择合适的复制模式。目前 WebSphere Application Server 支持两种 session 复制拓扑结构,分别为:
- 客户机 / 服务器 (Client/Server)
- 点对点 (Peer-to-Peer)
针对这两种拓扑结构,我们将在余下的章节中作详细的介绍。
复制域
首先,内存到内存复制功能是通过应用服务器上的数据复制服务实例来实现的,我们要确保这些数据复制服务实例是属于同一个复制域的,否则这些实例相互间就不能进行复制,从而影响内存到内存复制功能的实现。
如图 3 所示 , 复制域 Domain1 包含三个成员 Server1,Server2 和 Server3,因此这三个 server 之间能相互进行复制。但是由于 Server4 并不属于复制域 Domain1 里面的成员,因此 Server4 上的 session 不能复制到复制域 Domain1 的成员上,同时也不能备份 Domain1 上成员的 session 信息。