评论专栏

Erik Burckart:您想要了解的关于 HTTP 会话持久性的信息

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 评论专栏

敬请期待该系列的后续内容。

此内容是该系列的一部分:评论专栏

敬请期待该系列的后续内容。

常见问题解答

通常,我都会遇到各种各样的客户询问我大量关于 HTTP 会话持久性的问题。随着 Web 2.0 技术的推广,越来越多的 Web 应用程序被重新设计,在更改的过程中,这些问题出现的频率甚至会更高。如果您参与了针对 Web 2.0 的任何 Web 应用程序重新设计,这里将给出您可能很快就会提出的一些问题的答案。

  1. 如果我不需要会话持久性,是否将其关闭?

    是的,可以将会话管理配置为使用内存内会话(后者实际上是缺省设置)。还可以在此模式中使用 HttpSession,但如果出现错误,存储在 HttpSession 中的数据将丢失。

  2. WebSphere® Application Server Network Deployment 提供的会话持久性选项有哪些,各自的优缺点是什么?

    HttpSession 的两个主要选项是数据库持久性内存到内存复制。SipSession 复制只能使用内存到内存复制。在 IBM® WebSphere Application Server Network Deployment 中,内存到内存复制使用数据复制服务(Data Replication Service,DRS)。此外,IBM WebSphere eXtreme Scale 的 ObjectGrid (OG) 功能还提供用于 HttpSession 的内存到内存复制。

    • 数据持久性是使用最广泛的选项。在不考虑数据库运行所需的额外硬件的情况下,数据库持久性的性能也好于内存到内存复制。此解决方案的另一个优势是能够处理应用服务器的级联故障,而这在内存到内存配置中只有使用多个副本才有可能实现。数据库持久性的缺点在于数据库的成本,特别是存储在数据库中的会话数据本身应该具有高可用性的情况下更是如此。

    • DRS 内存到内存解决方案是适用于很多部署的解决方案。DRS 是“尽力服务”型内存到内存复制,根据数据规模和会话数量的不同,其性能比数据库持久性略微差一些。DRS 的主要优势在于可以避免数据库成本。DRS 的缺点是,比其他选项的可靠性差一些。尽管我们说 DRS 是“尽力服务”型,在出现故障时会话可能会丢失,但在经过适当优化的系统中,会话丢失的几率非常小。

    • 第三个选项是 OG 内存到内存解决方案。此解决方案的优势在于,它提供从非尽力服务的异步服务到有保证的同步事务复制的所有选择。相对于大多数数据库解决方案而言,其成本相对较低。其主要缺点在于,会在 WebSphere Application Server Network Deployment 之上增加额外的成本(虽然这个成本比大部分数据库许可证成本都低)。

  3. 如果我需要万能的通用体系结构,应该选择哪一个?

    在我看来,我会首先选择数据库持久性解决方案,并在 OG 内存到内存解决方案方面投资来减少数据库成本。数据库持久性方案是使用最广泛的体系结构,其性能也是最好的。

  4. 在什么情况下数据会丢失?

    会话丢失的最常见情况是将写频率设置为基于时间的写操作之类的配置。从上次写操作到出现服务器故障之间对会话的任何更改都可能丢失。对于任何会话复制选项都是如此。

    正如我上面指出的,由于采用尽力服务方式,DRS 丢失数据的几率很低。我们之所以说 DRS 采用的是尽力服务方式,是因为其中并没有利用任何确认机制来确保备份系统收到数据,在出现拥塞问题的系统中,可能根本就没有复制会话。当 WebSphere Application Server 中的高可用性管理系统非常繁忙时,可能会出现发送会话失败的情况。虽然 DRS 将尝试重新发送会话,但如果在每次重试时仍然存在拥塞,可能最终会失败。重试的次数和间隔是可配置的。最后,如果由于存在较重的工作负载而导致初始尝试和重试都出现拥塞故障,而且使用该会话的服务器也失败,则可能会丢失会话。在这种情况下,会话将丢失,应用程序将需要对此进行处理。

    关于 DRS,需要了解的重点是,在没有失败情况下,会话将始终存在。的确出现故障时,在故障出现前未写出的数据可能会丢失,并不会因为服务器使用数据库还是 DRS 持久性解决方案而有所差别。如果特定的应用程序将此视为问题,则可以考虑使用 ObjectGrid 缓存来替代用于存储这些对象的会话。ObjectGrid 提供关于对象的事务语义,用于确保在出现失败时知道更改已何时提交,以便在更改提交前出现错误的情况下进行回滚。

  5. 会话丢失是否会影响任何其他 WebSphere Application Server 组件?

    应用服务器本身的某些部分依赖于会话来存储 JavaServer™ Faces (JSF) 小部件之类的状态。不过,在会话丢失时,这些部分能够恢复,但会表现出一些明显的问题。例如,如果某个树 JSF 部件展开到特定的部分而出现故障,该树的下一个刷新视图可能不再能展开。

  6. 关于使用将需要持久处理的会话,还有其他哪些建议?
    • 让会话状态保持较小的尺寸,最好总数据量小于 4K。
    • 可能的情况下,使用临时变量,特别是在会话中缓存项目时。临时变量允许应用程序在本地内存中保留副本,但可以在使用备份副本的情况下重新构建对象。
    • 考虑使用 WebSphere eXtreme Scale 之类的对象缓存,而不是使用会话进行缓存。虽然会话可能比较方便,但其 API 并未针对作为缓存使用而设计,不能满足很多可通过对象缓存加以满足的需求。
  7. 对于数据库持久性,是应该使用单行模式,还是多行模式?

    单行模式提供较少的总体数据库查询操作量,能在每次更新时向数据库推送更多的数据。不过,对于存在大量会话属性的情况,或对属性更改非常少的情况,多行模式可能更为高效——甚至有必要采用此方法。因为每个属性存储在数据库内属于自己的行中,因此可以使用这些多行模式来存储大量的数据。不过,多行模式的性能可能相对较差,因为从会话收集属性可能会导致进行多次查询。

  8. WebSphere Application Server Network Deployment 中有哪些针对 HttpSession 的优化参数可用?

    WebSphere Application Server 信息中心列出了主要的会话优化选项。对于 HttpSession,最好从写频率开始进行优化。基本上来说,在其中可以配置会话管理器写到数据库或对等服务器的内存的频率。最佳的性能选项将通过基于时间的选项以相对较低的频率执行写操作。最糟糕的性能选项是在 Servlet 服务方法结束时写入(当 Servlet 从其调用的方法返回时),或手动更新(Servlet 本身对 IBMSession 调用方法来进行写操作)。如果属性更新不频繁,手动更新就可能成为最高效的会话持久性方法。不过,在应用程序未能在存在已更新的属性后对 IBMSession 调用 sync 方法,这样的做法会带来潜在的问题。

    要调整的另一个主要方面是“写内容”,或会话管理器将写出哪些信息的选项。这些选项涉及是将所有会话属性写入到持久机制,还是仅仅写入有更新的属性。绝不要采取每次写入所有属性的做法。除了其性能不如仅仅写入含更新属性的做法外,还会影响平台的可移植性。有些服务器并不支持基础需求(即在调用 setAttribute 时保存属性)之外的其他需求。

总结

通过这些答案,您应该能够确定最适合业务和应用程序两方面的需求的会话持久策略了。一个通常不错的做法是,在测试环境中模拟负载下的故障转移,通过这样可以发现,不仅是应用服务器,应用程序本身也会对会话从一个服务器转移到另一个服务器作出反应。这是说明基本问题(如忘记在可序列化的会话中存储某个属性)的最好方法,在未得到处理的情况下,此类问题可能在生产环境中导致较大的问题。

致谢

作者要特别感谢 Bobby Goff 和 Rohit Kelapure 在审阅本文时提供的建议和参考信息。


相关主题

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=355931
ArticleTitle=评论专栏: Erik Burckart:您想要了解的关于 HTTP 会话持久性的信息
publish-date=12082008