Amqp protocol (Classic)

Reprinted: http://kb.cnblogs.com/page/73759/

 

At present, a large number of applications use Asynchronous Message models, and many message-oriented middleware Products and protocols are generated. The inconsistent standards lead to coupling between applications and middleware to limit product selection and increase maintenance costs. Amqp is an application-layer standard protocol that provides unified messaging services. The client and message-oriented middleware based on this protocol can transmit messages and are not subject to different client/middleware Products and different development languages.

Of course, this mechanism of reducing coupling is based on protocols unrelated to upper-layer products and languages. The amqp protocol is a binary protocol that provides asynchronous, secure, and efficient interaction between client applications and message-oriented middleware. Overall, the amqp protocol can be divided into three layers:

This layered architecture is similar to the OSI network protocol and can be implemented at different layers without affecting interaction with other layers. Amqp defines an appropriate server-side domain model for regulating server behavior (amqp server can be called broker ). Here, the model layer determines the behaviors produced by these basic domain models. This behavior is represented by "Command" in amqp and will be analyzed again later. The Session Layer defines the communication between the client and the broker (both sides of the communication are a peer, which can be called a partner) to ensure reliable transmission of command. The Transport Layer focuses on data transmission and maintains interaction with sessions. It accepts data from the upper layer, assembles the data into a binary stream, transmits the data to the receiver, parses the data, and delivers the data to the Session Layer. The Session Layer needs the transport layer to report network exceptions and send commands in sequence.

The above is a general description of the amqp protocol. The following describes the domain model provided by amqp based on our requirements for MnS. The main functions of message-oriented middleware are the routing and caching of messages ). Two Domain Models with similar functions are provided in amqp: Exchange and message queue.

Exchange sends messages sent by message producers to Message Queue Based on different routing algorithms. Message Queue caches the messages when the messages cannot be normally consumed. The specific cache policy is determined by the implementer. When the connection between message queue and message consumer (Message consumer) is smooth, message Queue is responsible for forwarding messages to consumer.
Message is the basic unit in the current model. It is generated by the producer and consumed by the consumer by the broker. Its basic structure has two parts: header and body. The header is a set of various attributes added by the producer. These attributes control the message cache, the received queue, and the priority. The body is the binary data stream that is invisible to the broker and should not be affected during transmission.
There will be multiple message queue in a broker. How does exchange know the message queue to which the message will be sent? This is the role of the binding shown in. The creation of the message queue is controlled by the client application. After creating the message queue, you must determine which exchange route results it will receive and save. Binding is a domain model used to associate exchange with message queue. The client application controls the association of exchange with a specific message queue and binds the condition of the message accepted by this queue to exchange. This condition is also called binding key or criteria.
After association with multiple message queue, a route table exists in exchange, which stores the restrictions on the messages required by each message queue. Exchange checks the header and body information of each message it receives to determine which queue the message is routed. The header of the message should have a property called the routing key, which is generated by the message sender and provided to the exchange to route the message. Exchange has different exchange types based on different routing algorithms. For example, if direct is similar, the binding key must be equal to the routing key; there must also be a mode relationship between the binding key and the routing key; it can also be determined based on certain attributes contained in the message. Some basic routing algorithms are provided by amqp, and client applications can also customize their own extended routing algorithms. The processing process of a message is similar to this:

Here is a new term to be introduced: Virtual Host. A virtual host can hold some exchange and message queue. It is a virtual concept. A virtual host can be a server or a cluster composed of multiple servers. Under the synchronization extension, the deployment of exchange and Message Queue can also be one or more servers.
The consumer and consumer of the message may be the same application. The entire amqp defines the interaction between the client application and the broker. After a rough introduction to the amqp domain model, you can focus on how the client establishes a connection with the broker.
In amqp, the client application needs to establish a connection with the broker to communicate with the broker. This connection is actually associated with the virtual host, that is, connection is established between the client and virtual host. You can run multiple channels concurrently on a connection, and each channel can communicate with the broker. The session we provided earlier is attached to the channel.
The session can be defined in multiple ways. It can represent the command distribution mechanism provided by amqp, or it can be said that it is an interface between the macro difference and the domain model. The normal understanding is what we call the interactive context. The main function is to reliably transmit every command on the network. In amqp design, various TCP designs should be used for ensuring such reliability.
At the session layer, a unique identifier (which can be a uuid) is assigned to each command that needs to be interacted at the upper layer to perform checksum and retransmission of the command during transmission. The command Sender also needs to record each sent command to the replay buffer to obtain feedback from the receiver, so that the command is explicitly received or executed by the receiver. The sender re-transmits the command that does not receive feedback upon timeout. If the recipient has explicitly returned information to inform the command sender, but this information is lost halfway or the sender has not received the information due to other problems, the sender's continuous retransmission will have an impact on the recipient. To reduce this impact, the command receiver sets an idempotency barrier filter to intercept received commands. For details about this retransmission and validation mechanism, refer to the relevant TCP design.
The above section roughly introduces the amqp domain model and the validation and retransmission model in the connection mechanism, excluding the detailed binary specification of amqp.