RabbitMQ: Introduction to AMQP
Building large and complex systems is always associated with solving data exchange problems between their various nodes. Additional difficulties are brought by such factors as fault tolerance requirements, geographic separation of subsystems, the presence of nodes interacting with several others at once. It is not always convenient to use the notorious client-server system, and the point-to-point architecture may not be the most appropriate representation of connections.
And then, one day, the engineers gathered with spirit, and developed the AMQP - Advanced Message Queuing Protocol. This protocol allows you to not worry about where the recipients of the message are, how many of them there are, from whom it is necessary to wait for the message when it will be delivered to the recipient. In addition, AMQP removes many more routine tasks from the developer and allows you to deal with the immediate problem, rather than the maintenance of the development process.
AMQP has three basic concepts:
The exchange of messages is carried out within one exchanger (there is also a chain linking, but about this another time), in which the connections are defined, which are the peculiar routes along which messages go to this exchanger. Each route connects the exchanger with one or more queues. Software that implements the described actions is called an AMQP server. Nodes that put messages into exchangers and receive them from queues are called AMQP clients. In other words, the AMQP server provides a data bus, and AMQP clients use this bus to exchange messages with each other.
Customers can create new exchangers (we will talk about their types later) and queues:
The process of putting data on the bus is called publishing. When an AMQP client publishes a message to the bus, it sets the name of the exchanger and the name of the connection:
Up to this point, one of the clients must complete a bundle, indicating the name of the exchanger, the queue and the route corresponding to it:
As a result, the message <message> will be delivered to the queue <queue1>. But this is not all, because the message path does not end with the queue. One of the AMQP clients subscribes to receive messages that fall into a given queue:
where <pid> is the process id. Hereinafter, work with AMQP will be described from the point of view of programming on Erlang, in client implementations in other languages, messages are read from the queue by explicit instructions, or callbacks and subscriptions are not displayed as such. After subscribing to the queue, all messages that fall into it will be sent to the signed process. If several processes are signed for one queue, messages will be distributed to subscribers using the round-robin method.
')
To receive a response, when sending a request, the Message-To field is filled in the message properties, which, as a rule, contains a private type queue to which only the sender is subscribed.
That's all for now, next time I will try to write about the types of exchangers and show code examples, although you can see them right now right here .
And then, one day, the engineers gathered with spirit, and developed the AMQP - Advanced Message Queuing Protocol. This protocol allows you to not worry about where the recipients of the message are, how many of them there are, from whom it is necessary to wait for the message when it will be delivered to the recipient. In addition, AMQP removes many more routine tasks from the developer and allows you to deal with the immediate problem, rather than the maintenance of the development process.
AMQP has three basic concepts:
- Exchange (exchange)
- Queue
- Connection, or route (routing key)
The exchange of messages is carried out within one exchanger (there is also a chain linking, but about this another time), in which the connections are defined, which are the peculiar routes along which messages go to this exchanger. Each route connects the exchanger with one or more queues. Software that implements the described actions is called an AMQP server. Nodes that put messages into exchangers and receive them from queues are called AMQP clients. In other words, the AMQP server provides a data bus, and AMQP clients use this bus to exchange messages with each other.
Customers can create new exchangers (we will talk about their types later) and queues:
Exchange.Declare <exchange1> TYPE <type> Queue.Declare <queue1>
The process of putting data on the bus is called publishing. When an AMQP client publishes a message to the bus, it sets the name of the exchanger and the name of the connection:
Message.Publish <message> TO <exchange1> WITH <route1>
Up to this point, one of the clients must complete a bundle, indicating the name of the exchanger, the queue and the route corresponding to it:
Queue.Bind <queue1> TO <exchange1> WITH <route1>
As a result, the message <message> will be delivered to the queue <queue1>. But this is not all, because the message path does not end with the queue. One of the AMQP clients subscribes to receive messages that fall into a given queue:
Queue.Subscribe <pid> TO <queue>
where <pid> is the process id. Hereinafter, work with AMQP will be described from the point of view of programming on Erlang, in client implementations in other languages, messages are read from the queue by explicit instructions, or callbacks and subscriptions are not displayed as such. After subscribing to the queue, all messages that fall into it will be sent to the signed process. If several processes are signed for one queue, messages will be distributed to subscribers using the round-robin method.
')
To receive a response, when sending a request, the Message-To field is filled in the message properties, which, as a rule, contains a private type queue to which only the sender is subscribed.
That's all for now, next time I will try to write about the types of exchangers and show code examples, although you can see them right now right here .
Source: https://habr.com/ru/post/64192/
All Articles