Clustering a Java EE Web app - Options?_问答_开发者

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 ser开发者_JAVA百科vers 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.

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?

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.

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:

using session persistence and saving the session to a shared file system,
using session persistence and saving the session to a shared database,
using in-memory replication.

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).

Terracotta: Sounds interesting but buying an enterprise license is not an option.

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?

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.

Do you mean not using the HTTPSession? If yes, why? what problem are you facing with HTTPSession? 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: Sounds interesting but buying an enterprise license is not an option.

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

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:

Keep everything in a database. Maybe serialised as a blob. You need to housekeep those blobs when sessions timeout. App servers such as WebSphere have that capability.
Use some kind of memory-memory replication. Again there's going to have to be some transgfer/serialisation cost. You can trade off the frequency of that replication against the potential for loss of recent updates to the session.

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.