集群 Java EE Web 应用程序 - 选项？
我有一个 Web 应用程序部署到三台运行 Apache、Tomcat 的服务器以及它们前面的负载均衡器。现在我正在考虑将它们聚类。
以下是我所知道的常用选项和限制：
基于序列化的会话集群： 就我而言，应用程序在会话中使用了很多对象。所以我不想采用这个解决方案。此外，在不久的将来，服务器数量可能会增加到五个以上。
兵马俑： 听起来很有趣，但购买企业许可证并不是一个选择。
使应用程序无状态： 听起来很诱人，尽管这是一项工作。我很想听听一些设计指南和经验。
还有其他建议吗？
我的主要目标是故障转移。
I have a web app deployed to three servers running Apache, Tomcat and a load balancer in front of them. Now I am thinking of clustering them.
Here are the options usual options and my constraints that I am aware of:
Serialization based Session clustering:
In my case, the application uses a lot of objects in session. So I would prefer not to go with this solution. Also the no of servers is likely increase to more then five in the near future.Terracotta:
Sounds interesting but buying an enterprise license is not an option.Make the application stateless:
Sounds tempting although it is a bit of a work. I would love to hear some design guidelines and experiences on it.
Any other advices?
My primary goal is Failover.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的理解是，您当前正在 3 台服务器上平衡负载，因此，对我来说，您已经在进行集群（可扩展性部分），并且我不确定您所说的“集群”到底是什么意思。您的意思是超越透明的故障转移吗？
仅当您不希望用户在一个实例失败时失去会话时，这才有用。如果你真的想要这个，你需要“持久会话”（但要注意这会带来性能成本），Tomcat提供几种方法来实现这一点：
这需要一些真正的工作台，但就我个人而言，内存复制是我的首选解决方案（最佳性能）。不惜一切代价避免序列化到数据库（根据我的经验，性能不佳）。
我猜你指的是他们的 JVM 级集群解决方案。恕我直言，当应用程序无法轻松集群时，在应用程序下集群 JVM（相对于集群应用程序本身）是一个解决方案吗？但是为什么要使用提供此类功能的应用程序服务器来执行此操作呢？
您的意思是不使用
HTTPSession吗？如果是，为什么？您在使用HTTPSession时面临什么问题？你为什么要这样做？老实说，我不清楚你想要实现什么目标。您已经拥有一个可扩展的解决方案（垂直和水平），没有单点故障（负载均衡器除外，但是......），并且很少有应用程序（例如生命攸关的应用程序，金融应用程序）真正需要透明的容错能力（在换句话说，许多人可以没有）。此外，透明的容错在性能和/或硬件方面具有不可忽视的实际成本。因此，真正的问题是：当用户失去会话时，您的企业会损失那么多钱吗？有那么重要/频繁吗？这是否证明花钱实施透明的容错是合理的？
My understanding is that you are currently load balancing your load on 3 servers, so, to me, you are already doing clustering (the scalability part) and I'm not sure what you exactly mean by "clustering them". Do you mean going beyond with transparent fail over?
This is only useful if you if you don't want your users to loose their session if one instance falls. If you really want this, you'll need "persistent session" (but be aware that this has a performance cost), Tomcat offers several way to implement this:
This would require some real bench but, personally, in-memory replication is my preferred solution (best performances). Avoid serializing to database at any cost (bad performances from my experience).
I guess you are referring to their JVM-level clustering solution here. Clustering the JVM underneath the application (vs clustering the application itself) is IMHO a solution when the application can't be easily clustered? But why would you do this with an application server that is offering such a feature?
Do you mean not using the
HTTPSession? If yes, why? what problem are you facing withHTTPSession? Why would you do this?To be honest, what you are trying to achieve is not clear to me. You already have a scalable solution (vertically and horizontally), no single point of failure (except the load balancer but well...), and very few applications (e.g. life critical applications, financial applications) really need transparent fault-tolerance (in other words, many can live without). Moreover, transparent fault-tolerance has a real cost in terms of performance and/or hardware that shouldn't be neglected. So, the real questions are: does your enterprise loose that much money when a user looses his session? Is it that critical/frequent? Does this justify spending money to implement transparent fault-tolerance?
Terracotta 是开源的，因此您有义务购买许可证。它提供了一种非序列化的 Web 会话复制方法，这正是您所要求的。
要开始使用，请转到此处：http://www.terracotta.org/web /display/orgsite/Web+Sessions
Terracotta is open source, so you're note obligated to buy a license. It provides a non-serialization approach to web session replication, which is what you are asking for.
To get started, go here: http://www.terracotta.org/web/display/orgsite/Web+Sessions
传统上，它是一种罕见的真正无状态的 Web 应用程序，尽管我猜想在 Ajax 时代，在浏览器中保留状态更为常见。
如果您的目的是使用集群，以便各个用户会话在服务器丢失的情况下继续存在，那么您将需要支付某种传输成本。您可以：
无论哪种情况，您的目标都是“会话亲和力”：用户的请求默认发送到同一集群成员，实际上他们的“主”实例充当直写式缓存。
我不知道您的环境中提供了哪些现成的东西，理想情况下您的服务器提供商应该内置会话管理设施 - 您自己编写这些东西并不是完全微不足道的。
Traditionally, it's a rare web-app that is truly stateless, though I guess in these Ajax days keeping the state in the Browser is more common.
If your intent is to use clustering so that the individual users sessions survive the loss of a server then you are going to need to pay some kind of transfer cost. You might:
In either case you aim for "session affinity": the user's requests default to going to the same cluster member, effectivly their "home" instance acts as a write-though cache.
I don't know what's provided off-the-shelf in your environment, ideally your server provider should have session management facilities built in - writing this stuff your self is not completely trivial.