2009-07-29 56 views
16

是否有可扩展http会话管理的最佳做法?可扩展http会话管理(java,linux)

问题空间:

  • 购物车种使用情况。用户在网站周围购物,最终退出;会话必须保留。在每个数据中心
  • 的Java
  • 多个数据中心
  • 多个Web服务器,Linux的

我知道有这样做吨的途径,我可以随时拿出自己的具体解决方案,但我想知道人群计算器的智慧是否可以帮助我专注于最佳实践

一般来说,似乎有几个方法:

  • 不要保留会话;永远运行无状态,宗教[不适合我...]
  • 使用j2ee,ejb和该团伙的其余部分
  • 使用数据库来存储会话。我想有些工具可以使这更容易,所以我不需要自己制作所有的东西
  • 使用memcached存储会话(或其他类型的中间存储器,半永久存储器)
  • 使用键值数据库。比memcached更“持久”
  • 使用“客户端会话”,这意味着所有会话信息都存在于隐藏的表单字段中,并且在客户端之间向前和向后传递。什么都不存储在服务器上。

有什么建议? 谢谢

回答

5

我会用一些标准的分布式缓存解决方案去。 可能是您提供的应用程序服务器,可能是memcached,可能是terracotta 只要您使用的是足够流行的东西(因此您知道大多数错误已被捕获),选择哪一个可能无关紧要, 。

至于你的其他想法:

  • 不要让会议 - 像你说的不可能
  • 客户端会话 - 太不安全 - 假如有人黑客cookie来把折扣价格在购物车
  • 使用数据库 - 数据库通常是解决最困难的瓶颈,不要在那里放置超过你绝对必须的数据库。

这些都是我的2美分:)

关于多个数据中心 - 你会希望有会议,它开始对数据中心的一些亲和力。我不认为可以在不同数据中心之间使用分布式缓存解决方案。

5

你似乎错过了香草复制http会话从您的清单。任何值得使用的servlet容器都支持跨集群的会话复制。只要您放入会话的项目不是很大,并且是可序列化的,那么使其工作起来非常容易。

http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html

编辑:看来,然而,Tomcat的会话复制不能很好地扩展到大型集群。为此,我建议使用JBoss + Tomcat的,这给了“好友复制”的想法:

http://www.jboss.org/community/wiki/BuddyReplicationandSessionData

+0

Tomcat 6.0,对吧? – Ran 2009-07-29 08:56:26

+0

就像现在的版本一样,是的。 JBoss附带了Tomcat的嵌入式版本。 – skaffman 2009-07-29 09:14:00

1

我个人还没有管理过这样的集群,但是当我在大学参加一个J2EE课程时,讲师说会将会话存储在数据库中,而不是试图缓存它。 (无论如何,你不能有意义地缓存动态页面。)根据定义,Http会话是客户端,因为session-id是一个cookie。如果客户拒绝存储cookie(例如他对跟踪有偏见),那么他不能进行会话。 你可以致电HttpSession.getId()得到这个ID。

当然数据库是一个瓶颈,所以你最终会得到两个集群:一个应用服务器集群和一个数据库集群。

据我所知,有状态的消息豆类和常规的servlet HTTP会话只存在于内存没有内置的负载均衡。

顺便说一句。我不会将电子邮件地址或用户名存储在隐藏字段中,但购物车的内容可能不是敏感数据。

1

我宁愿退出在HTTP会话中存储用户应用程序状态,但这需要以不同的方式思考应用程序如何工作并使用RESTful无状态体系结构。这通常涉及到在客户端不支持MVWW体系结构的早期版本浏览器的支持。

购物车是不是一个用户应用程序状态它是一个应用状态这意味着它将被存储在数据库中,因此管理的。假设可以共享购物车,可以有一个关联表将用户链接到一个或多个购物车。

您最大的障碍可能是如何验证用户的每一个请求,如果它是无状态的。 BASIC auth是不涉及会话的最简单方法,FORM-auth无论如何都需要会话。 JASPIC实现(如HTTP Headers或OAuth)将能够缓解您其他地方的身份验证问题,在这种情况下,Cookie可用于管理您的身份验证令牌(如FORM-auth)或HTTP标头(如SiteMinder或客户端证书)以及Apache 。

更昂贵的数据库(如DB2)具有跨多个数据中心工作的高可用性和灾难恢复功能。请注意,它并不意味着对数据库进行负载平衡,因为这会对网络流量造成很大的影响。