Some communication problems between MQ Message Queuing and Message Queuing

Message Queuing	Development language	Protocol support	Design Patterns	Persistent support	Transaction support	Load Balancing Support	Functional characteristics	Disadvantages
RabbitMQ	Erlang	Amqp,xmpp,smtp,stomp	Agent (Broker) mode (messages are queued in the central queue before they are sent to the client)	Support Persistence to File	Not supported	Support	The performance is good, the management interface is rich, the Internet company has a large scale application; The core of the design is to ensure that the message is submitted correctly (the consumer is always in the active state to consume the message), so the design is heavy and needs to record many states.	Although the product is open source, Erlang language application is not common; clustering does not support dynamic scaling
ZeroMQ	C++	ZEROMQ is a parallel framework for the socket Library (a Transport Layer API library), not a real Message Queuing/messaging middleware	Point-to-point mode, by referencing the ZEROMQ library and sending messages between apps, any application node can be used as an MQ	Not supported	Not supported	Not supported	Low latency, high performance, up to 430,000 messages per second	Non-persistent queue, data will be lost after downtime
ActiveMQ	Java	Openwire,stomp Rest,ws NOTIFICATION,XMPP,AMQP,JMS	Support for proxy mode and point-to-point mode	Support persistence to a file or database	Support	Support	Mature products are used in many companies, there are more documents, various protocols support better, mature clients with multiple languages, fully support JMS1.1 and the Java EE 1.4 specification (persistence, XA messages, transactions), support spring, can easily be embedded into the system using spring	According to other user feedback, there will be a problem with the lost message, the focus has been placed on the next generation of products Apollo, the community is not active enough to maintain less 5.x

Regarding the communication problem between message queues, can be implemented by using the ACTIVEMQ broker Cluster cluster approach, ACTIVEMQ cluster mode mainly consists of two kinds: Master slave and broker Cluster.

1, master slave cluster mode: master provides services, slave real-time backup master data to ensure the reliability of the message. When master fails, slave automatically upgrades to master, and the client automatically connects to slave;

2. Broker Cluster cluster mode: Route messages between multiple ACTIVEMQ instances. For example, a producer application connects a ACTIVEMQ instance, called a MQ1, and all messages are provided by that instance. Two consumer applications connected to another two activemq instances, respectively, MQ2 and MQ3, two message consumers need to consume MQ1 messages, but they are not connected MQ1, you can use the cluster mode to route messages on the MQ1 to MQ2 and MQ3.

Broker cluster clusters are divided into static discovery and dynamic discovery two kinds.

(1) Static Discovery mode: Use the URI address of all known ACTIVEMQ instance nodes in a hard-coded manner. In order to ensure that consumers do not fail to consume messages due to the failure of a node, the URI of all nodes needs to be configured in the consumer application. This static route may exist because of the way the static processing makes routing faster.

(2) Dynamic Discover mode: When you configure a ACTIVEMQ instance, you do not need to know the URI address of all other instances, just set it up in the configuration file for all instances to enable the message to route between all ACTIVEMQ instances.

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 share of the message, and the Broker cluster mode supports load balancing, which can improve the consumption ability of the message, but it can't guarantee the reliability of the message.

Therefore, in order to support load balancing while guaranteeing the reliability of the message, the Msater slave and broker cluster can be used.

For performance comparison of different MQ, please refer to this article below:

http://blog.x-aeon.com/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/