Distributed message Middleware (v)--MQ Basic explanation

first, Message Queuing MQ Basics

1. MQ Core composition

Sender (Producer app)--message Queue--receiver (Consumer app)

2. MQ vs SOA

The advent of Message Queuing is intended to complete message communication between systems and to coordinate calls between system invocations. This is similar to SOA. However, unlike SOA service-oriented direct invocation, Message Queuing communication is not a direct call relationship, inter-system communication is mainly sent by message, the receiver receives the message, processes it, and completes the call processing with the sender.

3. Advantages of Message Queuing

(1) System decoupling

There is no direct call relationship between the interaction system, only through the message transmission, so the system intrusion is not strong, the coupling is low.

(2) Improve system response time

For example, the original set of logic, the completion of payment may involve the first modification of the order status, calculation of loyalty points, notification logistics delivery several logic to complete; with MQ architecture design, it is possible to put the urgent critical (need to respond immediately) business into the calling method, in response to the requirements of the use of Message Queuing, put into the MQ queue, for consumer processing.

(3) Providing services for large data processing architectures

Message Queuing also integrates with the real-time processing architecture to provide performance support for data processing, in the context of big data, through messaging as a consolidation.

4. JAVA Messaging Service--JMS

The Java Messaging Service (Java message SERVICE,JMS) application interface is an API for message-oriented middleware (MOM) in the Java platform for sending messages between two applications, or distributed systems, for asynchronous communication.

Peer and Pub/sub message patterns in JMS: Peer-to-peer (point-to-point, queue) and publish-subscribe (PUBLISH/SUBSCRIBE,TOPIC) are initially defined by JMS. The main difference between the two modes is whether the messages sent to the queue can be reused (multiple subscriptions).

(1) Point-to-point

Message producer production messages are sent to the queue, and then the message consumer takes out the queue and consumes the message.

After the message is consumed, the queue is no longer stored, so the message consumer cannot consume the message that has been consumed. Queue support exists for multiple consumers, but for a message, only one consumer can consume it.
(2) Publish/Subscribe

The message producer (release) publishes the message to topic and has multiple message consumers (subscriptions) consuming the message. Unlike point-to-point methods, messages posted to topic are consumed by all subscribers.

(3) Peer vs Pub/sub

The queue implements load balancing, sending messages from producer production to message queues, consumed by multiple consumers. But a message can only be accepted by a consumer, and when no consumer is available, the message will be saved until there is a usable consumer.
Topic implements the publish and subscribe, when you publish a message, all subscriptions to this topic service can get this message, so from 1 to N subscribers can get a copy of the message.

the extension of message pattern in information middleware

Unlike ACTIVEMQ, which follows the JMS point-to-point, publish subscriber message model, Kafka is designed to be personalized on the basis of the JMS specification's pub/sub model.

Similarly Kafka uses the PUB/SUB model, where producers send messages to topic, and messages in topic can be used by n consumers.

The difference is that Kafka the data in each topic, and puts forward the concept of zoning partition, and consumes the individual consumer instances in the consumer group's role, and 1 partitions corresponds to a message instance in 1 consumer groups. Improves the concurrency efficiency of multiple consumers simultaneously processing data in a partition.

In addition, Kafka differs from one of the JMS specifications or other distributed messaging systems, and Kafka supports the persistence of messages. This is detailed in the next article.