MQ is all called the message queue, and Message Queuing (MQ) is an application-to-application communication method. Applications communicate by reading and writing messages to and from the queue (data for the application), without requiring a dedicated connection to link them. Message passing refers to the process of communicating between programs by sending data in a message, rather than by directly invoking each other, and directly invoking techniques such as remote procedure calls. Queuing refers to an application communicating through a queue. The use of queues removes the requirement that both the receiving and sending applications execute concurrently.
MQ featuresMQ is a typical representative of the consumer-producer model, where one end writes messages to the message queue, while the other end reads or subscribes to messages in the queue. MQ is similar to JMS, but the difference is that JMS is a standard and API definition for the Sun Java Messaging Middleware Service, and MQ follows the specific implementations and products of the AMQP protocol.
Usage ScenariosIn the project, some operations without immediate return and time-consuming are extracted and processed asynchronously, which greatly saves the request response time of the server and improves the throughput of the system.
ConceptBind: Binds queue and exchange, which is the message queue that conforms to what routing rules will be placed, and Broker: The Message Queuing server entity in its simplest case.
Exchange: A message switch that specifies what rules the message is routed to and to which queue.
Queue: A message queue carrier in which each message is put into one or more queues.
Binding: Bind, which is the role of binding exchange and queue according to routing rules.
Routing key: The routing keyword, exchange messages are delivered based on this keyword.
Vhost: Virtual host, a broker can open multiple vhost, as a separate user permissions.
Producer: The message producer is the program that delivers the message.
Consumer: The message consumer is the program that receives the message.
Channel: The message channels, in each connection of the client, multiple channels can be established, each channel represents a session task. The use of Message Queuing is probably as follows: (1) The client connects to the Message Queuing server and opens a channel.
(2) The client declares an exchange and sets the related properties.
(3) The client declares a queue and sets the related properties.
(4) The client uses routing key to establish a good binding relationship between Exchange and queue.
(5) Clients post messages to exchange. When Exchange receives a message, it routes messages to one or more queues based on the key of the message and the binding that has been set. There are several types of exchange, which are called direct switches that are delivered entirely according to key, for example, when the routing key is set to "ABC", the client submits a message that only the key "ABC" is set to be posted to the queue. When the key is matched with a pattern, it is called a topic switch, and the symbol "#" matches one or more words, and the symbol "*" matches exactly one word. For example, "abc.#" matches "Abc.def.ghi", "abc.*" matches only "Abc.def". There is also a need for a key, called the fanout Switch, which takes broadcast mode, when a message comes in, it is posted to all queues that are bound to the switch. RABBITMQ supports the persistence of messages, that is, data is written on disk, and for data security reasons, I think most users will choose to persist. Message Queuing persistence consists of 3 parts:
(1) Exchange persistence, specifying durable + 1 at the time of declaration
(2) Queue persistence, specify durable when declaring = 1
(3) Message persistence, specifying Delivery_mode = 2 on delivery (1 non-persistent) if both Exchange and queue are persisted, the binding between them is persistent. If there is a persistence between Exchange and queue, a non-persisted, binding is not allowed.
RBBITMQ Basic Knowledge
