Positioning and Analysis of message-oriented Middleware

Positioning and Analysis of message-oriented Middleware

In the following analysis, the application that generates the message is defined as the producer of the message, and the application that receives the message is defined as the consumer of the message. Even though this definition is not used in MQ, it is called the sender and receiver of a message. According to the definitions of the names of consumers and users of different message-oriented middleware, the difference between message-oriented middleware is actually reflected. Through the analysis below, this difference will be clearer. To unify the concepts, This article uses the producer and consumer of messages.

1. MQSeries

The core idea of MQ design is to store and forward messages and complete various functions of the product around how messages are sent to the destination. Before sending a message in MQ, You need to configure the path of the Message flow. The producer of the message must know where the message is consumed and send the message to the correct destination, and put the message in the correct queue. The consumer of a message receives a message from a fixed local queue. As long as the message enters this local queue, the consumer thinks that all messages belong to him. The typical usage mode is as follows:

 

In this process, MQ is actually driven by the producer of the message. The producer decides which consumer to send the message to, and needs to put the message in the correct queue, regardless of whether the queue has any consumer.

From the perspective of the actual business system, the use of MQ is driven by business rules, the business rules are embodied by the configuration of the Message Transfer Path (here the business rules do not include the actual processing rules for the message ).

2. tonglink/Q

The design concept and positioning of tonglink/q are similar to those of MQ. The typical application mode is as follows:

 

As the most widely used message middleware in China, MQ and tonglink/Q mainly provide reliable data transmission across the Intranet and Internet. The basic application mode is point-to-point data transmission.

This type of message middleware mainly solves the asynchronous and reliable transmission between message producers and consumers.

3. activemq

As an implementation of JMS, activemq provides a medium for message exchange between producers and consumers. It can be seen from the name of activemq (broker, it is positioned as a proxy that provides message exchange for client applications. This is completely different from the positioning of MQSeries. More application scenarios of MQSeries are to solve point-to-point message transmission. Message "transmission" and "Exchange" are two completely different application scenarios.

Typical scenarios of activemq are as follows:

The producer generates messages and puts them in the queue of the proxy server it connects to. Local consumers can directly receive messages from this queue. In this mode, local consumption of messages is realized, that is, the producer and consumer of the message are connected to the same proxy server.

Activemq also supports another consumption mode of messages-remote consumption. By configuring transmission channels between proxy servers, multiple proxy servers can form a server network, consumers can connect to any proxy server on the server to consume messages from other proxy servers remotely. To consume messages remotely, you only need to meet several simple conditions, including the same name of the queue opened by the producer and consumer, and the number of message transfers (the number of proxy servers that can pass through in the transfer) it is convenient to use within the scope of the transmission channel configuration.

From the typical use cases of activemq, we can see that the message producer is only responsible for message production and does not care whether the message is correctly submitted to the server where the consumer is located. This is obviously different from MQSeries. From the consumer's point of view, the consumer only needs to connect to the proxy server to consume its own messages. In this process, the consumer does not care whether there is a message that can be consumed locally, the proxy server automatically finds the messages belonging to this consumer and transfers these messages to the proxy server connected to the consumer. This process is completely transparent to the consumer, consumers do not care whether messages are stored locally or remotely.

From the internal message flow process of remote consumption, we can see that the core idea of activemq is actually driven by the consumer. If there is no consumer, the message will be stored in the queue of the proxy server connected by the producer; only when there is a consumer, a network composed of a proxy server forwards messages to the queue of the proxy server connected to the consumer.

Activemq is more suitable for scenarios where a large number of small messages can be quickly exchanged between different applications. For cross-network transmission of large messages, because activemq is a consumer-driven, messages are transferred from the source server to the target server only when the consumer is connected to the proxy server. The consumer needs to wait for the complete message transmission process, this process may be "long" depending on the actual network, and cannot implement full asynchronous transmission between producers and consumers. In this scenario, MQSeries is more suitable.

4. Rabbit MQ

Rabbitmq mainly implements data exchange between producers and consumers, but emphasizes the rules for consumers to receive messages. Let's take a look at typical use cases of rabbit MQ:

From the basic positioning of the product, like activemq, rabbit MQ exchange messages between different client applications. However, different products have their own starting points in specific implementation.

The rabbitmq producer does not directly put messages into the queue, but first passes through an exchange. By configuring rules in exchange, the producer confirms that the messages are placed in the queue of the consumer.

The rabbitmq producer is only responsible for generating messages. The producer never puts messages directly into the queue, and does not care whether messages can be put into the queue, that is, whether there are qualified consumers. The producer can only send messages to exchange. If no consumer needs this message, the message will not enter any queue.

In this process, rabbit MQ is actually driven by consumers.