In the previous article, the problem solved by task_queue was that a message could only be received by a consumer. Now that we have new requirements, we need a logging system. We want to have two consumers, one that outputs the log to the screen and another that writes to the disk. In order to achieve this goal, we hope that the message is cast into two queues and handed over to different consumers for processing. As follows:
For the producer, no longer specify which queue to receive the message, but which exchange to receive the message. Exchange does not save the information, if there is no queue binding on this exchange, the message is lost. code show as below:
For the consumer, create a temporary queue (exclusive=True, when the consumer terminates, the queue will be destroyed), connect the queue to the exchange, and then receive the message sent by the exchange through the queue:
In the above example, we did not specify routing_key when queue_bind() (to avoid confusion, it will be called binding_key). The function of binding_key is related to the type of exchange. For fanout exchange, binding_key has no meaning. For direct exchange, as shown in the following figure, only the message’s routing_type will be sent to the queue if it is the same as the queue’s binding_key: direct-exchange
You can specify the same binding_key as shown below direct-exchange-multiple
In this way, we can transform the logging system into the following mode, different consumers only receive certain types of log information: python-four
The topic exchange is similar to direct exchange, except that it allows the binding_key to use special characters (note that special characters represent words, not letters): – *: represents a word – #: represents zero or more words
For example, the following example. The routing_key is defined as “<celerity>.<colour>.<species>”. Here are a few examples of routing_key matching: – quick.orange.rabbit: one, two – lazy.orange.elephant: one, two – quick.orange.fox: one – lazy.brown.fox: three – lazy.pink.rabbit: two, three (but only once, because the second and third are the same queue) – quick.brown.fox: no, discard – orange: no, discard – quick.orange.male.rabbit: no, discard – lazy. Orange.male.rabbit: three
When binding_key does not use these special characters, a topic exchange is actually direct exchange; when binding_key uses #, a topic exchange is actually a fanout exchange, that is, all messages are received.
In The Previous Article:
Let’s review the code above. First of all, it is clear that this situation uses the default exchange. For the producer, it passes the message to exchange and then exchanges the routing key to determine which queue to send the message to. In fact, it is equivalent to sending the message directly to the queue. The consumer directly specifies the name of the queue, that is, it is directly bound to the queue. Exchange does not have any sense of existence in this process.
And this one, in fact, the producer only recognizes exchange. It is only responsible for handing over the message to exchange. The consumer builds the queue itself and binds the queue to the exchange it is interested in. Exchange decides in what form it provides services, whether it is famous or direct.
Subscribe to our newsletter