Go] Introduction to large-scale distributed message middleware

At present, various RPC middleware technologies have been widely used in various fields. Among them, the function of message communication between servers is widely used in these middleware, so the message-oriented middleware (messages oriented middleware, MOM) is abstracted to form the common message middleware and become the mainstream of the industry. Current messaging middleware standards include: JMS and AMQP. The realization is the blossom of flowers.

The message middleware needs to address the following issues functionally:

1. Synchronous or asynchronous message transmission, especially asynchronous message transmission

The synchronous send message is the message is sent, blocking waits for the message to send a successful feedback, if the setting has a time-out, then out of blocking state after time-out.

Sending a message asynchronously does not block the immediate execution of other operations after the message is sent. If you care whether the message was sent successfully, you can handle the message successfully through the callback function (Listener in Java).

2. message Security, message middleware support for persistence

In the distributed system, the message from the Send to receive, the link is very many, no one link is safe, and any part of the problem, will lead to lost messages. When there is a need, we must ensure that the transmission of message security is done in many links that are not completely secure. Among these, the persistence of the message in the middle is very important.

3. The re-postback of messages

If the system you are using guarantees idempotent, there is no requirement for this. Otherwise, some scenarios require that messages not be re-sent. It is very difficult to keep the message safe and to ensure that the message is not re-sent. No one in the industry has been able to solve this problem yet.

At present, in the case of the message re-send, the system used is to ensure the power of the system to the message with the state machine.

4. The order of messages

If you are using a system that has requirements, you may want to guarantee the order of the messages. In the case of large-scale distributed environment, it is very difficult to solve this problem in order to ensure the message transmission efficiency and message security.

If it is a small-scale system, the performance requirements are not high, can be based on server time, using queued queue can be resolved.

If the sending end time is the same, and the sequence of messages is sent by this sender, the message sequence number can be used to resolve it.

In addition, some systems only need to meet the local message order, in the case of a small number of sorting messages, you can use multiple sorting messages to send one-time resolution.

5. Message transfer model: Point-to-point transmission message (PTP ), subscription/ release model (pub/sub )

PTP, where you set the unique identifier of the message receiver on the message side, then the message sender and the message receiver establish a one by one corresponding relationship. All messages sent by the message sender are received by the message receiver.

Pub/sub is that the message sender and the message receiver both determine their own label for sending and receiving the message (or you can understand it as a group GroupID), and all messages with this tag will be received by the receiving party subscribing to the label.

JMS (Java Messaging Service, Java Message Services) is a message-oriented middleware specification dedicated to the EE. It mainly does the specification on the interface, the message transmission model and the message type specifications, and does not give the implementation. Similarly, it does not give the server-side architecture at all, and you can even transfer messages between clients without using the server (although it may end up being just a toy). Http://java.sun.com/products/jms/docs.html. JMS also does not specify the order of messages, security, re-hair and other features.

AMQP (Advanced Message Queuing Protocol (Queuing Protocol) is a language-independent, emerging messaging middleware used in the financial industry, and is now the focus of the message middleware circle. Unlike the JMS specification API, it is an application-layer protocol specification used by asynchronous messaging. The original purpose of AMQP is simply to provide the financial community with a message protocol that can collaborate with one another, and now the goal is to provide common building tools for the common Message Queuing architecture. http://www.amqp.org/

 

Go] Introduction to large-scale distributed message middleware