AMQP protocol and rabbit q

AMQP (Advanced Message Queuing Protocol) is an application layer protocol of message middleware, which is used to decouple components to provide a unified message service. The main function is to sort and route messages (including point-to-point and subscription publishing) to ensure the reliability and security of messages.

Clients following AMPQ protocol can communicate with each other through message middleware. In this way, clients can be implemented in different development languages, and there is no strong dependence between them, which reduces the complexity of clients, improves development efficiency and is also conducive to later maintenance.

The model framework of AMQP is as follows:

RabbitMQ is an open source implementation of AMQP protocol. The architecture model can also be represented by the following figure:

As shown above, simple mode, single publisher, single queue and single consumer.

As shown above, the working mode

Multiple consumers * * * * use a queue of messages.

In this mode, rabbitMQ will automatically do load balancing and send a message poll to all consumers, that is, a message can only be obtained by one consumer.

As shown above, publish/subscribe publish subscription mode (broadcast mode).

Compared with the first two modes, there is one more exchange (type fanout). Messages are first sent to the exchange, and then the exchange is sent to all corresponding queues respectively. The consumer subscribes to his own queue and uses messages on the queue he subscribes to.

Example of application scenario, as shown in the following figure:

For example, there are many ways to notify users after online shopping and payment are successful, such as app push, SMS, email and so on.

After the message arrives, it is sent to three queues (app push q, SMS q, email_q) by exchange.

After that, app push service, SMS notification service and email notification service get messages from their subscription queues to inform users of successful payment.

As shown above, the exchange type is set to direct.

At this point, the rountingKey in the message matches the bindingKey in the exchange. If they are equal, they will be sent to the corresponding queue. If they do not match the bindingKey, the message will be discarded.

Example of application scenario, as shown in the following figure:

For example, there are many kinds of logs generated by services, such as error, info, debuf, etc. However, our only requirement is to write the error log to disk, so we can route the error log to the error queue by routing, and then the corresponding write disk service gets the message and writes it to disk.

As shown above, communication types are topics. Compared with the fourth mode, the similarity is that they all match according to rountingKey, but the difference is that the topic mode supports fuzzy matching.