上一篇中的例子是一个生产者对应一个消费者,那能不能一个生产者对应一个消费者呢? 下面来测试一下,顺便观察一下它的分发策略。。。
步骤一:先编辑生产者代码(rabbit_send.py)
#top1:导入pika模块
import os
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
import pika
#top2:建立socket
connection = pika.BlockingConnection(pika.ConnectionParameters(‘localhost‘))
#top3:声明管道
channel = connection.channel()
#top4:在管道中声明Queue,Queue的名字是‘exclusive‘(随意)
channel.queue_declare(queue=‘exclusive‘)
#top5:在管道内发送消息
channel.basic_publish(exchange=‘‘,
routing_key=‘exclusive‘, #queue名称
body=‘Let s go!‘) #消息内容
#top6:关闭队列
connection.close()
步骤二:编辑消费者代码(rabbit_receive.py)
#top1:导入pika模块
import os
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
import pika
#top2:建立scoket
connection = pika.BlockingConnection(pika.ConnectionParameters(
‘localhost‘))
#top3:声明管道
channel = connection.channel()
#top4:声明Queue
channel.queue_declare(queue=‘exclusive‘)
#top5:定义一个处理消息的函数(所说的回调函数)
def callback(ch, method, properties, body):
print(" [x] Received %r" % body)
#top6:接收消息
channel.basic_consume(#消费消息
callback, #如果收到消息,就调用callback函数来处理消息
queue=‘exclusive‘,
no_ack=True)
#top7:此处的start只要一起动就一直运行了,因为它不止收一条
channel.start_consuming()
定义好生产者和消费者后,执行一个生产者多个消费者进行测试。测试结果是消息的接收机制是轮询的,生产者每发送一次消息,都由消费者轮流来接收。
接下来考虑一个情况,现在的代码是消费者接收到消息后调用callback函数去处理消息立刻打印,但是如果我的处理过程需要30秒的时间,恰好在这30秒的时间内消费者宕机了,这个消息还没有处理完,比如我有一个转账的业务,那转到一半宕机了,那咋整?应该有一个确认机制来确定到底是不是处理完了,消费者应该发送一个确认给生产者,然后生产者才把消息从消息队列里删除;还是纠结。。。。那消费者处理到一半宕机了,还怎么给生产者发确认。。。。
还用刚才的代码来测试,把在消费者处理消息的函数中加入一个time.sleep(30),再print一句话来模拟处理时间,再执行生产者和多个消费者,假如第一个消费者接收到消息我们把它停止,再观察别的消费者,没反应。。。。什么鬼?消息丢了!!!
那我们回过头来把no_ack=True注释掉,这个的意思是"不确认",再测试。结果是把第一个消费者断了,第二个消费者继续处理消息,保证消息被处理完,那为什么生产者知道消费者宕机了呢?因为socket断了,它是连接RabbitMQ的,它断了自然而然就知道消费者宕机了。。
一般我们不需要加no_ack=True参数,只有那些对生产者不关心的消息可以加上。
原文地址:http://blog.51cto.com/12730062/2059318
时间: 2024-10-30 17:08:50