First, the consumer cluster queue (Queue Consumer Clusters)
ActiveMQ message Consumer support load balancing consumption with high reliability, if a Consumer dead, the message will be forwarded to other Consumer spending Queue. If a Consumer get the message faster than other Consumer, it will get more information. It is recommended to use ActiveMQ of Broker and Client failover: // transport way to configure links.
Two, Broker clusters (Broker clusters)
in most cases is to use a series of Broker and Client linked together. If a Broker dead, Client can automatically link to other Broker. To achieve the above behavior need to use failover protocol as a Client.
If a plurality of start Broker, Client can readily Dynamic discovery or static discovery from another broker to a broker a direct link.
So that when there is no Consumer on a broker, then it will not be news consumption, but by the broker will store and forward the strategy to send the message to the other broker.
Note:
ActiveMQ default of two broker, after static links are unidirectional, broker-A consumer can access the message broker-B, if you want to support two-way communication, you need time netWorkConnector configuration settings duplex = true on it.
Three, Master Slave
in the 5.9 version of which, the abolition of the Pure Master Slave way, currently supports:
1: Shared File System Master Slave: Based on the shared storage Master-Slave, multiple broker instances use a stored file, who is the master lock to get the file, to be started in the other state, if the master hung up, grab a file lock the slave becomes Master
2: JDBC Master Slave: JDBC-based Master-Slave, use the same database, get a write lock lOCK tables broker to become Master
3: replicated LevelDB Stroe: LevelDB based ZooKeeper copy stored Master-Slave mechanism, this is a plus of 5.9 new
details: http://activemq.apache.org/masterslave.html
- JDBC Master Slave manner
using a database as a data source, using the Master / Slave mode, wherein when the first obtaining exclusive Master boot lock, waiting for the other Slaves Broker acquire exclusive locks are
recommended to connect the client to use Failover Brokers.
as the picture shows:
- Master failure
If Master fails, it releases the exclusive lock, the other Slaver get exclusive lock, other Slaver immediate access to exclusive Master Lock this time it will become, and start all transport connections. Meanwhile, the Master and Client stops Broker will be connected to the polling other available connection before use, i.e., the new Master. As shown in FIG. - Master restart
at any time to start the new Broker, i.e. Slaver to join as a new cluster, as shown on the right - JDBC Master Slaver configuration
using <jdbcPersistenceAdapter /> to the configuration message persistence, will automatically use the JDBC Master Slave manner.