可扩展的http会话管理（java，linux）
是否有可扩展 http 会话管理的最佳实践？
问题空间：
- 购物车类型的用例。 用户在网站上购物并最终结账； 必须保留会话。
- 多个数据中心
- 每个数据中心有多个 Web 服务器
- Java、Linux
我知道有很多方法可以做到这一点，而且我总是可以想出自己的具体解决方案，但我想知道 stackoverflow 的群众智慧是否可以帮助我专注于最好的事情- 实践
一般来说，似乎有以下几种方法：
- 不保留会话； 始终以无状态的方式运行 [对我来说不起作用...]
- 使用 j2ee、ejb 和该团伙的其余部分
- 使用数据库来存储会话。 我想有一些工具可以使这变得更容易，所以我不必自己制作所有内容
- 使用 memcached 来存储会话（或其他类型的中间、半持久存储）
- 使用键值数据库。 比 memcached “更持久”
- 使用“客户端会话”，这意味着所有会话信息都存在于隐藏的表单字段中，并从客户端向前和向后传递到服务器。 服务器上没有存储任何内容。
有什么建议么？ 谢谢
Is there a best-practice for scalable http session management?
Problem space:
- Shopping cart kind of use case. User shops around the site, eventually checking out; session must be preserved.
- Multiple data centers
- Multiple web servers in each data center
- Java, linux
I know there are tons of ways doing that, and I can always come up with my own specific solution, but I was wondering whether stackoverflow's wisdom of crowd can help me focus on best-practices
In general there seem to be a few approaches:
- Don't keep sessions; Always run stateless, religiously [doesn't work for me...]
- Use j2ee, ejb and the rest of that gang
- use a database to store sessions. I suppose there are tools to make that easier so I don't have to craft all by myself
- Use memcached for storing sessions (or other kind of intermediate, semi persistent storage)
- Use key-value DB. "more persistent" than memcached
- Use "client side sessions", meaning all session info lives in hidden form fields, and passed forward and backward from client to server. Nothing is stored on the server.
Any suggestions?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我会选择一些标准的分布式缓存解决方案。
可能是您提供的应用程序服务器，可能是 memcached，可能是 terracotta
你选择哪一个可能并不重要，只要你使用的是足够流行的东西（所以你知道大多数错误已经被追捕）。
至于你的其他想法：
这些是我的 2 美分:)
关于多个数据中心 - 您将希望会话与其启动的数据中心有一定的亲和力。 我认为没有任何可以在不同数据中心之间工作的分布式缓存解决方案。
I would go with some standard distributed cache solution.
Could be your application server provided, could be memcached, could be terracotta
Probably doesn't matter too much which one you choose, as long as you are using something sufficiently popular (so you know most of the bugs are already hunted down).
As for your other ideas:
Those are my 2 cents :)
Regarding multiple data centers - you will want to have some affinity of the session to the data center it started on. I don't think there are any solutions for distributed cache that can work between different data centers.
您似乎从列表中错过了普通复制的 http 会话。 任何有价值的 servlet 容器都支持跨集群的会话复制。 只要您放入会话中的项目不是很大并且是可序列化的，那么就很容易使其工作。
http://tomcat.apache.org/tomcat-6.0-doc/cluster -howto.html
编辑：但是，tomcat 会话复制似乎不能很好地扩展到大型集群。 为此，我建议使用 JBoss+Tomcat，它提供了“伙伴复制”的想法：
http: //www.jboss.org/community/wiki/BuddyReplicationandSessionData
You seem to have missed out vanilla replicated http sessions from your list. Any servlet container worth its salt supports replication of sessions across the cluster. As long as the items you put into the session aren't huge, and are serializable, then it's very easy to make it work.
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
edit: It seems, however, that tomcat session replication doesn't scale well to large clusters. For that, I would suggest using JBoss+Tomcat, which gives the idea of "buddy replication":
http://www.jboss.org/community/wiki/BuddyReplicationandSessionData
我个人没有管理过这样的集群，但是当我在大学学习 J2EE 课程时，讲师说将会话存储在数据库中并且不要尝试缓存它。 （无论如何，您都无法有意义地缓存动态页面。）根据定义，Http 会话是客户端的，因为会话 ID 是一个 cookie。 如果客户端拒绝存储cookie（例如，他对跟踪很偏执），那么他就无法进行会话。
您可以通过调用
HttpSession.getId()来获取此ID。当然，数据库是一个瓶颈，因此您最终会得到两个集群：应用程序服务器集群和数据库集群。
据我所知，有状态消息 bean 和常规 servlet http 会话都仅存在于内存中，没有内置负载平衡。
顺便说一句。 我不会将电子邮件地址或用户名存储在隐藏字段中，但购物车的内容可能不是那么敏感的数据。
I personally haven't managed such clusters, but when I took a J2EE course at the university the lecturer said to store sessions in a database and don't try to cache it. (You can't meaningfully cache dynamic pages anyway.) Http sessions are client-side by the definition, as the session-id is a cookie. If the client refuses to store cookies (e.g. he's paranoid about tracking), then he can't have a session.
You can get this id by calling
HttpSession.getId().Of course database is a bottleneck, so you'll end up with two clusters: an application server cluster and a database cluster.
As far as I know, both stateful message beans and regular servlet http sessions exist only in memory without load balancing built in.
Btw. I wouldn't store e-mail address or usernames in a hidden field, but maybe the content of the cart isn't that sensitive data.
我宁愿放弃在 HTTP 会话中存储用户应用程序状态，但这需要以不同的方式思考应用程序如何工作并使用 RESTful 无状态架构。 这通常涉及放弃对客户端不支持 MVWW 架构的早期版本浏览器的支持。
购物车不是用户应用程序状态，而是应用程序状态，这意味着它将存储在数据库中并按此进行管理。 假设可以共享购物车，则可以有一个关联表将用户链接到一个或多个购物车。
您最大的障碍可能是如何针对每个请求（如果是无状态的）对用户进行身份验证。 BASIC auth 是最简单的方法，不涉及会话，而 FORM-auth 无论如何都需要会话。 JASPIC 实现（如 HTTP 标头或 OAuth）将能够减轻您在其他地方的身份验证问题，在这种情况下，可以使用 cookie 来管理您的身份验证令牌（如 FORM-auth）或 HTTP 标头（如 SiteMinder 或 Apache 的客户端证书） 。
像 DB2 这样更昂贵的数据库具有跨多个数据中心工作的高可用性和灾难恢复功能。 请注意，它并不是为了对数据库进行负载平衡，因为网络流量会产生很大的影响。
I would rather move away from storing user application state in an HTTP session, but that would require a different way of thinking how the application works and use a RESTful stateless architecture. This normally involves dropping support for earlier versions of browsers that do not support MVWW architectures on the client side.
The shopping cart isn't a user application state it is an application state which means it would be stored on a database and managed as such. There can be an association table that would link the user to one or many shopping carts assuming the sharing of carts is possible.
Your biggest hurdle would likely be how to authenticate the user for every request if it is stateless. BASIC auth is the simplest approach that does not involve sessions, FORM-auth will require sessions regardless. A JASPIC implementation (like HTTP Headers or OAuth) will be able to mitigate your authentication concerns elsewhere, in which case a cookie can be used to manage your authentication token (like FORM-auth) or HTTP header like SiteMinder or Client Side Certificates with Apache.
The more expensive databases like DB2 have High Availability and Disaster Recovery features that work across multiple data centers. Note that it is not meant for load balancing the database, since there'd be a large impact due to network traffic.