The previously published article has been deleted in time because the code part is not clear on the phone after editing. This article will be re-edited and published again. Please forgive me for the inconvenience!
ZZR , Python Chinese community columnist, OpenStack engineer, and former NLP researcher. Main interests: OpenStack, Python crawler, Python data analysis.
In the previous article, the problem solved by task_queue is that a message can only be received by one type of consumer. Now we have new requirements. We need a logging system. We hope that there are two kinds of consumers, one kind of consumer outputs logs to the screen, and the other kind of consumers writes to disk. In order to achieve this goal, we hope that the message will be cast into two queues and handed over to different consumers for processing. As follows:
For the producer, no longer specify which queue to receive messages, but which exchange to receive messages. The exchange does not save information. If there is no queue bound to the exchange, the message will be lost. code show as below:
For the consumer, create a temporary queue (
exclusive=Truewhen the consumer terminates, the queue will be destroyed), connect the queue to the exchange, and then receive the message sent by the exchange through this queue:
As shown in the figure below, each consumer has built its own temporary queue and bound it with the exchange:
In the above example, we did not specify routing_key during queue_bind() (to avoid confusion, we will call it binding_key later). 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 figure below, only when the routing_type of the message is the same as the binding_key of the queue will it be sent to the queue:
You can specify the same binding_key, as shown in the following figure:
In this way, we can transform the log system into the following mode, where different consumers only receive specific types of log information:
The complete code is as follows:
Topic exchange is similar to direct exchange, except that it allows binding_key to use special characters (note that special characters represent words, not letters):
*: Represents one word-
#: Represents zero or more words
For example, the following example. routing_key is defined as
"<celerity>.<colour>.<species>" . Give 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 : 2. three (but only once, because two and three are in the same queue)-quick.brown.fox: none, discard-orange: none, discard-quick.orange.male.rabbit: none, discard-lazy. orange.male.rabbit: Three
When the binding_key does not use these special characters, the topic exchange is actually a direct exchange; when the binding_key is used
#, the topic exchange is actually a fanout exchange, that is, all messages are received.
Some extreme examples: binding_key:,
*routing_key: empty string. Mismatch. binding_key:
..routing_key: . match. binding_key:,
#.*routing_key: apple. match.
In the previous article:
Review the code above again. First of all, it is clear that the default exchange is used in this case. For the producer, it delivers the message to the exchange, and then the exchange uses the routing key to determine which queue to deliver 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 this queue. In this process, the exchange actually has no sense of existence.