RABBITMQ Task Force column to implement load distribution for high-performance tasks [Python instance]__python

Annoying, Official introduction:

RABBITMQ is one of the messaging middleware implementations of AMQP (Advanced Message Queuing protocol), originally originated from the financial system for storing and forwarding messages in distributed systems, and performing well in terms of ease of use, scalability, and high availability. Message-oriented middleware is mainly used for decoupling between components, and the sender of the message does not need to know the existence of the message consumer and vice versa

Comparison of RABBITMQ Redis

RABBITMQ and Redis can do queues, but they still make a difference, for example, Redis message queues, if the worker fails to process when it pops out of the queue, the data does not go back to the queue, and the failed processing data is pushed into the queue from the business manually. RABBMITMQ can automatically handle failed worker so that data is not lost; RABBITMQ can also ensure that data is persisted during transmission, and that data in channels and queues can be set to persistent.

Comparison of RABBITMQ Zeromq

RABBITMQ, although not as fast as ZEROMQ, has provided more reliable MQ to a certain extent, with persistent and preventing crashes.

There is also a detailed comparison of the following.

First to understand the rabbitmq of some of the proper nouns ~

Concept:

Channel: Channel, AMQP supports multiple MQ communication channels on a TCP connection, and each channel can be used as a traffic flow.

Producer: producer, is the source of the message produced.

Exchange: Switches can be understood as routing rules that have routing tables.

Queues: Queues, the cache container that loads messages.

Consumer: Consumer, a client that connects to a queue and takes a message away.

Core idea: In Rabbitmq, the producer never sends messages directly to the queue.

In fact, some producers don't even know if the message was sent to a queue. The producer is only responsible for sending the message to the switch, and the switch knows exactly where the message should be sent.

Bind: bindings, which can actually be understood as routing rules for switches. Each message has a property called a routing key (routing key), which is a simple string. A binding binds the "switch, routing key, message delivery queue" together to form a routing rule.

Exchange type: Switch types:

Fanout: Do not process routing keys and forward to all bound queues

Direct: Processing routing keys must match exactly, that is, the routing key string is the same before forwarding

Topic: The routing key pattern matches when the queue needs to be bound to a pattern. The symbol "#" matches one or more words, and the symbol "*" matches no more than a few words. Therefore "audit.#" can match to "audit.irs.corporate", but "audit.*" will only match to "Audit.irs"

About the legendary performance ~

The following picture is a comprehensive test by some Daniel.

For RABBITMQ Zeromq, although I do not have a specific test, but practical applications are applied. ZEROMQ's speed doesn't have to be questioned, it's really fast, but he doesn't do the storage persistence and usability of the data, and if the client doesn't open it, he'll go out with the information, whether you're there or not. But RABBITMQ to consider a lot, look at the following figure everyone will know.

RABBITMQ, although the sex can be compared with ZEROMQ, but the application in the project is not bad.

If it is not installed, please look at the image below

Here is the bag he depends on. See this, you should know he was written in Erlang.

Write a small demo sent to the "producer", you can think of a boss, this time to do things to share.

1 2 3 4 5 6 7 8 9 <