RabbitMQ learning Summary

RabbitMQ learning Summary

During this time, I have been learning the design model and have been trying to write a series of blog posts related to the design model. However, it is difficult to understand the design model, and it is neither simple nor simple, however, if you want to have a deep understanding and use it freely in the project architecture, you still have to spend some time accumulating it. A little far away ~

Today, let's talk about MQ, taking RabbitMQ as an example.

1. Definition

Message Queue: the container that saves messages during message transmission.

This is a classic consumption-producer model, which is abstract. For example: thread A needs to send messages to thread B (thread A and thread B are not necessarily on the same machine). Thread A first sends messages to the MQ server, then, line B reads or subscribes to messages in the message queue on the message server. No direct communication is performed between thread A and thread B. The MQ server acts as a relay in the middle.

2. Applicable application scenarios

It is more suitable for asynchronous transmission. Here we will explain what is asynchronous and synchronous.

Asynchronous: the sender does not care whether the message is successfully sent. Only the message is sent, and does not obtain whether the message is successfully sent.

Synchronization: the sender is concerned about whether the message is successfully sent. After the message is sent, the sender waits for the receiver to return the status code. Based on the status code, the sender determines whether the message is successfully sent and then performs the relative action.

The following uses synchronization and Asynchronization in Http as an example:

For example, the communication between the common B/S architecture client and the server is synchronous, that is, the request is submitted ---> wait for the server to finish processing and return the message ---> get the message returned by the server and complete processing.

For example, Ajax is asynchronous, and requests are triggered through events ---> server processing (the browser can still do other tasks without waiting) ---> processing is complete.

Some may be curious about how the application scenario is synchronized and asynchronous, which means you are not very familiar with the close connection between technology and application scenarios.

3. RabbitMQ

There are many similar products in the message queue. In the future, I will independently post a blog post to describe them. Here we use RabbitMQ as an example.

RabbitMQ is a standard implementation of AMQP (Advanced Message Queue Protocol). For more information, see http://www.rabbitmq.com/getstarted.html.

3.1. Role Concept

Every open-source project has its own design method and module role, and RabbitMQ is no exception. The structure is as follows:

Broker: the entity of the Message Queue Server.

Exchange: the message switch, which specifies the rules of the message and the queue to which the message is routed.

Queue: Message Queue carrier. Each message is put into one or more queues.

Binding: Binding. It binds exchange and queue according to routing rules.

Routing Key: The route keyword. exchange ships messages based on this keyword.

Vhost: Virtual Host. Multiple vhosts can be opened in a broker to separate permissions of different users.

Producer: Message producer, which is the Program for delivering messages.

Consumer: the message consumer, which is the program that receives the message.

Channel: Message channel. Multiple channels can be created in each connection of the client. Each channel represents a session task.

3.2. Working Process

• Producer client:

1. The client connects to the RabbitMQ server and opens a message channel );
2. The client declares a message switch (exchange) and sets related properties.
3. The client declares a queue and sets related attributes.
4. The client uses the routing key to establish a binding relationship between the message switch (exchange) and Message queue (queue.
5. All messages delivered by the client are sent on the message switch (exchange ).
6. The client closes the Message channel and the connection to the server.

• Server:

After receiving a message, exchange performs message routing based on the Message key (the generation rules of this key are not studied for the time being. If you know it, you can leave a message to tell me) and the set binding, ship messages to one or more message queues.

There are also several types of exchange:

(1). Direct switch: deliver based entirely on the key. For example, if the routing key is set to abc during binding, the client will deliver the information to the queue only when the key is set to abc;

(2). Topic switch: deliver after the key matches the mode. For example, the symbol "#" matches one or more characters, and the symbol "*" matches a string of consecutive letter characters, such as "abc. # "can match" abc. def. ghi ", and" abc. * "only matches" abc. def ".

(3). Fanout switch: it adopts the broadcast mode. When a message comes in, it will be delivered to all the queues bound to the switch.

• Consumer Client:

(No research at the moment, subsequent updates)

Install RabbitMQ in CentOS 5.6

Detailed installation record of RabbitMQ client C ++

Try RabbitMQ in Python

Deployment of production instances in the RabbitMQ Cluster Environment

Use PHP + RabbitMQ in Ubuntu

Process of installing RabbitMQ on CentOS

RabbitMQ concept and Environment Construction

RabbitMQ getting started

3.3. Message persistence of RabbitMQ

RabbitMQ supports data persistence, that is, writing data on a disk increases data security. Message Queue persistence consists of three parts:

1. Message switch (exchange) persistence, specifying durable as 1 during Declaration
2. Message queue (queue) persistence, specifying durable as 1 during Declaration
3. Message persistence. The delivery_mode is set to 2 upon delivery (1 is non-persistent)

If exchange and queue are both persistent, the Binding between them is also persistent. If the message switch and the message queue are persistent and non-persistent, binding is not allowed.

For more details, please continue to read the highlights on the next page:

1 2 3 4 5 6 7 Next Page

[Content navigation]
Page 1: Article 1: Theory	Page 2: Quick Start HelloWorld
Page 3rd: Article 3: Work Queue	Page 4: Publish/Subscribe
Page 5: Article 5: Routing	Page 6: Topic-type exchange
Page 7: RCP (Remote Procedure Call Protocol)