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