ActiveMQ集群随记

Problem: cluster on JMS queue or EHCache to solve the pending activity tracking problem.

There are several cluster modes for ActiveMQ JMS.

Cluster Mode
1.Queue consumer clusters
If a consumer dies, any unacknowledged messages are redelivered to other consumers on the queue.
If one consumer is faster than the others it gets more messages etc. If any consumer slows down, other consumers pick up the slack.
So you can have a reliable load balanced cluster of consumers on a queue processing messages.
Solve problems:
It provides a good grid style processing model for consuming messages.
It doesn't help us to solve our problem.

2.Broker clusters
The most common mental model of clustering in a JMS context is that there is a collection of JMS brokers and a JMS client will connect to one of them,
then if the JMS broker goes down, it will auto-reconnect to another broker.
Solve problems:
It provides load-balance and fail-over mechanism.
But each broker has its own queue instance, so the queue is not really cluster.
It doesn't help us to solve our problem.

3.Master Slave
The idea behind MasterSlave is that messaages are replicated to a slave broker so that even if you have catastrophic hardware failure of the master's machine,
file system or data centre, you get immediate failover to the slave with no message loss.
There has 3 types of master-slave mode:
-------------------------------------
Mode: Pure Master Slave
Pros: No central point of failure.
Cons: Requires manual restart to bring back a failed master and can only support 1 slave.
-------------------------------------
Mode: Shared File System Master Slave
Pros: Run as many slaves as required. Automatic recovery of old masters.
Cons: Requires shared file system.
-------------------------------------
Mode: JDBC Master Slave
Pros: Run as many slaves as required. Automatic recovery of old masters.
Cons: Requires a shared database. Also relatively slow as it cannot use the high performance journal.
-------------------------------------
Solve problems:
If we want to have a fail-over solution, it is the solution.
And it only supports fail-over instead of load-balance.
But we still have the "non-shared cache" in the master and slave JMS webapp instances.

4.Replicated Message Stores
An alternative to MasterSlave is to have some way to replicate the message store.
It doesn't help us to solve the problem.

Conclusion
If we want to have a fail-over solution,
then 2 production applications will share the same JMS webapp instance using the "Master-Slave" mode.
It supports the fail-over mechanism instead of load-balance.

But if we don't care about the fail-over mechanism, we can just run 2 JMS webapp instances in production.
Since JMS doesn't support the really queue based cluster as we described before,
so we have to do the cluster based on the EHCache.

Reference
http://activemq.apache.org/clustering.html
http://activemq.apache.org/masterslave.html