上一篇中的例子是一个生产者对应一个消费者，那能不能一个生产者对应一个消费者呢？ 下面来测试一下，顺便观察一下它的分发策略。。。
步骤一：先编辑生产者代码（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参数，只有那些对生产者不关心的消息可以加上。
