Python Operations RABBITMQ Series (II): Multiple receive-side consumer messages

Today, we're going to start talking about RABBITMQ a little bit more advanced. Understanding this step is very useful for us in designing highly concurrent systems. Of course, you can also use Kafka. But still forget, there are a few hard conditions do not support, or use RABBITMQ bar.

Circular distribution:

Initiates a send end to send a message to the queue, at which time multiple receive ends are started. The message sent will send a message to the receiving end one next to each other.

That is, by default, multiple receiving ends are consuming messages in turn. After the queue is sent to the consumer, it is immediately deleted. So the question is, what happens when a consumer deals with a message and terminates abnormally? At this point, we would prefer this: if the consumer hangs up, the message is automatically forwarded to another consumer for processing.

Fortunately, RABBITMQ is effectively confirming the mechanism. After the consumer receives the message, the normal processing completes, at this time only then notifies the queue to be free to delete. So the problem comes again, consumers hang up even the confirmation message can not be sent out, how to do? The RABBITMQ maintains the consumer's connection information. The consumer hangs up, the connection channel to the server is shut down, or the TCP connection is lost. When the server knows the situation, it automatically re-sends the message.

Here's another question, what if the server hangs up? Note: Durable=true. This is when the server hangs up the queue still exists. Delivery_mode=2:server hangs the message still exists. If you guarantee that the message is not lost, both parameters must be set.

Send side:

Import Pika
Import Sys

Connection = Pika. Blockingconnection (Pika. Connectionparameters (host= ' localhost '))
Channel = Connection.channel ()

# Durable:server hangs up the queue still exists
Channel.queue_declare (queue= ' task_queue ', durable=true)

# Send a message using the default switch. When Exchange is empty, the default is used. delivery_mode=2: Causes the message to persist. and queue name Bindings Routing_key
Message = '. Join (sys.argv[1:]) or "Hello world!"
Channel.basic_publish (exchange= ",
Routing_key= ' Task_queue ',
Body=message,
Properties=pika. Basicproperties (
delivery_mode=2,
))
Print ("[x] Sent%r"% message)
Connection.close ()

Receiving end:

Import Pika
Import time

Connection = Pika. Blockingconnection (Pika. Connectionparameters (host= ' localhost '))
Channel = Connection.channel ()

Channel.queue_declare (queue= ' task_queue ', durable=true)
Print (' [*] waiting for messages. To exit Press CTRL + C ')


DEF callback (ch, method, properties, body):
Print ("[x] Received%r"% body)
Time.sleep (Body.count (b '. '))
Print ("[x] Done")
# Manually confirm the message
Ch.basic_ack (Delivery_tag=method.delivery_tag)


# Basic_consume: This function has no_ack parameters. This parameter defaults to False. Indicates that the message needs to be confirmed. How to understand: No is set to False, indicating that you want to confirm
Channel.basic_consume (Callback, queue= ' Task_queue ')
Channel.start_consuming ()

Fair Dispatch:

At the moment, we already know how to ensure that the message is not lost, then the problem comes again. Some consume fast and some do slow. In this way, some of you are exhausted and have nothing to do. How to solve this problem?

The RABBITMQ has been taken into account. That is: The job is finished, the notice to Server,server sent to that.

At the top of the receiving end of the

Channel.basic_consume (Callback, queue= ' Task_queue ')

Code before adding:

Channel.basic_qos (Prefetch_count=1)

Can

Now, our message is one for a consumer. Next, we'll talk about sending the same message to multiple consumers.

Python Operations RABBITMQ Series (II): Multiple receive-side consumer messages