ACTIVEMQ Cluster Application

ACTIVEMQ Cluster

ACTIVEMQ has a powerful and flexible cluster function, but in the process of use will find a lot of shortcomings, ACTIVEMQ cluster way mainly by two kinds: Master-slave and broker Cluster.

1, Master-slave

In Master-slave mode, only master provides services, slave is the real-time backup of Master's data to ensure the reliability of the message. When master fails, slave automatically upgrades to master, and the client automatically connects to slave to work. The Master-slave pattern is divided into three categories: Pure Master Slave, Shared File System master Slave, and JDBC Master Slave.

(1) Pure Master Slave

Requires two brokers, one as master, and the other as slave, while the runtime slave copy data from master over the network, and if slave and master lose connectivity, Slave automatically upgrades to master. Continue to provide the message service to the client:

In practice, we use two ACTIVEMQ servers, one as Master,master does not need to do a special configuration, and the other as slave, configure ${activemq_home}/conf/activemq.xml files in <broker The > node adds a URI that connects to master and sets the master to fail after the slave is not closed, as follows:

XML code

1. <broker xmlns= "Http://activemq.apache.org/schema/core" brokername= "Pure_slave" masterconnectoruri= "tcp:// 0.0.0.0:61616 "shutdownonmasterfailure=" false "datadirectory=" ${activemq.base} ">

Modify the slave service port at the same time, such as:

XML code

1. <transportConnectors>
2. <transportconnector name= "Openwire" uri= "tcp://0.0.0.0:61617"/>
3. </transportConnectors>

To see the effect of practice, both master and slave's message persistence media are MySQL-based, and master and slave connect to different databases respectively.

Add the following red content in the spring configuration file for message producer apps and message consumer apps:

XML code

1. <property name= "Brokerurl" value= "Failover: (tcp://localhost:61616,tcp://localhost:61617)? Initialreconnectdelay=100 "/>

After the configuration is complete, we can test it with the following steps:

A, start master and slave, start the message producer app, and send some queue messages and topic messages separately, if the consumer who subscribes to topic messages at this time sets up ClientID, We can see the messages that have not been consumed in the master database and the slave database, including queue and topic;

B, start the consumer application, you can receive the message;

C, close the consumer, the producer continues to send some messages A;

D, stop master;

E, producers continue to send message B;

F, start the consumer application, consumers can receive messages A and message B, stating that slave took over master's work and copied the master message.

This way can only two machines to do the cluster, can play a good dual-machine hot standby function, but only one failure, only downtime to restore the master-slave structure.

(2) Shared File System Master Slave

The shared file system Master Slave is the ACTIVEMQ cluster using the share filesystem, which is based on the ACTIVEMQ default database kahadb, and the KAHADB is the file system. This way of the cluster, the number of slave is not limited, which ACTIVEMQ instance gets the lock of the shared file first, the instance is master, the other ACTIVEMQ instance is slave, when the current master fails, the other slave will compete to share the file lock, Who competes for who is master. The benefit of this model is that when master fails, it does not have to be configured manually, as long as there are enough slave. Shared File System Master slave mode:

This example is to run three ACTIVEMQ instances on a single machine, you need to do some simple configuration of the ACTIVEMQ configuration file, is to change the persistent adapter storage directory to a fixed directory of local disk, three instances share this directory, as follows:

XML code

1. <span style= "color: #ff0000;" ><persistenceAdapter>
2. <KAHADB directory= "e:/xxx/xxx/xxx/cluster/shared_file/data/kahadb"/>
3. </persistenceAdapter></span>

Then modify the service port of the ACTIVEMQ instance and the service port of jetty to prevent port occupancy exceptions. Start the three ACTIVEMQ instances and you are ready to test.

The above configuration can only be performed on one machine, and if each ACTIVEMQ instance needs to be running on a different machine, a distributed file system is needed.

(3) JDBC Master Slave

The principle of the JDBC master slave mode and the shared file Sysytem Master slave mode is the same, except that the shared filesystem is replaced with a shared database. All we need to do is add a data source in all of the ACTIVEMQ's main configuration files (${activemq_home}/conf/activemq.xml), all of which point to the same database, such as:

XML code

2. <bean id= "Mysql-ds" class= "Org.apache.commons.dbcp.BasicDataSource" destroy-method= "Close" >
4. <property name= "Driverclassname" value= "Com.mysql.jdbc.Driver"/>
6. <property name= "url" value= "Jdbc:mysql://localhost:3306/cluster_jdbc?relaxautocommit=true"/>
8. <property name= "username" value= "root"/>
10. <property name= "Password" value= "root"/>
12. <property name= "maxactive" value= "/>"
14. <property name= "Poolpreparedstatements" value= "true"/>
16. </bean>

Then modify the persistence adapter. The cluster in this way is simpler and easier to deploy distributed than the shared File System Master slave, but if the database fails, all ACTIVEMQ instances will be invalidated.

The above three ways of clustering do not support load balancing, but can solve the problem of single point of failure, to ensure the reliability of the message service.

2. Broker Cluster

Broker cluster is primarily the routing of messages between multiple ACTIVEMQ instances through the network of brokers. Broker's cluster is divided into static discovery and dynamic discovery two kinds.

(1) Static Discovery Cluster

A Static discovery cluster is a hard-coded way to use the URI addresses of all known ACTIVEMQ instance nodes. Such as: The message producer application connects a ACTIVEMQ instance, we are temporarily called MQ1, all messages are provided by this instance; two messages consumer applications connect to another two Activemq instances, respectively MQ2 and MQ3, two message consumers need to consume MQ1 messages, But they are not connected to the MQ1, you can use the static discovery way to route messages on the MQ1 to MQ2 and MQ3, in order to ensure that the consumer does not cause a node to fail to consume the message, in the consumer application needs to configure all the node URI.

Producer ACTIVEMQ instances do not require special configuration, and all consumer activemq instances need to add networkconnectors nodes, connected to producer MQ instances, such as:

XML code

1. <span style= "color: #ff0000;" ><networkConnectors>
2. <networkconnector uri= "static:failover://(tcp://localhost:61616)" duplex= "true"/>
3. </networkConnectors></span>

The above configuration needs to be added to the front of the <persistenceAdapter> node. Then set the value of the Brokerurl in the consumer app such as:

XML code

1. <property name= "Brokerurl" value= "<span style=" color: #ff0000; " >failover: (tcp://localhost:61617) </span>?initialreconnectdelay=100 "/>

Static Discovery Cluster Way some shortcomings, such as failure to solve a single point of failure, if a broker fails, it is possible to cause data loss, dynamic addition of nodes is not intelligent.

For more detailed instructions and configuration, please refer to: http://activemq.apache.org/networks-of-brokers.html

(2) Dynamic Discovery Cluster

Dynamic Discovery Cluster Mode when you configure a ACTIVEMQ instance, you do not need to know the URI address of all other instances, just add the following in the ${activemq_home}/conf/activemq.xml file for all instances:

XML code

1. <span style= "color: #ff0000;" ><networkConnectors>
2. <networkconnector uri= "Multicast://default"/>
3. </networkConnectors></span>

Also add the following red sections to the <transportConnectors> node:

XML code

1. <transportConnectors>
2. <transportconnector name= "Openwire" uri= "tcp://0.0.0.0:61616" <span style= "color: #ff0000;" >discoveryuri= "Multicast://default" </span>/>
3. </transportConnectors>

This enables the message to be routed between all ACTIVEMQ instances. The Dynamic discovery cluster approach has the same drawbacks as static discovery.

From the above analysis, we can see that the Master-slave mode does not support load balancing, but it can guarantee the reliability of the message service through the real-time backup or sharing of the message, the Broker cluster mode supports load balancing, can improve the consumption ability of the message, but it can't guarantee the reliability of the message. So in order to support load balancing and ensure the reliability of the message, we can use the Msater-slave+broker cluster mode.

ACTIVEMQ Cluster Application