在上篇文章中，我们介绍了消费端的确认，那么在生产者有没有确认机制呢？答案是有的。 参考我们发送消息的代码段:

channel.basic_publish(exchange='testexchange', routing_key='hello', body='Hello World!{}'.format(i),
                          mandatory=True,
                          properties=pika.BasicProperties(
                              delivery_mode=2,  # 消息持久化
                          ))

如果在发送方发出消息后，如果exchange写错了，或者没有任何队列绑定我们发送的exchange，那么在这时候发送方是对此浑然不知的，而rabbitmq为了解决这个问题下面介绍下。

生产者将信道设置成confirm（确认）模式，一旦信道进入confirm模式，所有在该信道上面发布的消息都会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后，RabbitMQ就会发送一个确认（Basic.Ack）给生产者（包含消息的唯一ID），这就使得生产者知晓消息已经正确到达了目的地了。如果消息和...

首先，我们先看下这样的业务场景，在消息发出后，Consumer接收到了生产者所发出的消息，但在Consumer突然出错崩溃，或者异常退出了，但是生产者消息已经发出来了，那么这个消息可能就会丢失，为了解决这样的问题，RabbitMQ引入了ack机制。 消费者在订阅队列时，可以指定autoAck参数，当autoAck等于false时，RabbitMQ会等待消费者显式地回复确认信号后才从内存(或者磁盘)中移去消息(实质上是先打上删除标记，之后再删除)。当autoAck等于true时，RabbitMQ会⾃自动把发送出去的消息置为确认， 然后从内存(或者磁盘)中删除，而不管消费者是否真正地消费到了这些消息。 当采用ack消息确认机制后，只要将autoAck设置为false。消费者就可以有足够的时间来处理消息，而不用担心消费过程中突然异常退出导致消息丢失的情况，因为RabbitMQ会一直持有消息，直到消费者调用basic.ack为止。在这种情况下，对于RabbitMQ来说，队列中的消息就可以分为两部分，一部分是等待发送给消费者的消息，另外一部分就是等待接收消费者确认的消息。那么如果在这个时候，消费者突然发生中断，在消费中的消息会怎么处理呢？ 如果RabbitMQ一直没有接收到消费者的确认消息，并且消费者的连接已经关闭，那么RabbitMQ就会重新将让消息进入队列中，等待下一个消费者消费...

基本介绍

RabbitMQ, 是一个使用erlang编写的AMQP(高级消息队列协议)的服务实现. 简单来说, 就是一个功能强大的消息队列服务.流程上来说，是发消息者(producer)把消息放到队列(queue)中去，然后收消息者(consumer)从队列中取出消息. RabbitMQ在这个基本概念之上, 多做了一层抽象, 在发消息者和队列之间, 加入了交换器 (Exchange). 这样发消息者和队列就没有直接联系, 转而变成发消息者把消息给交换器, 交换器根据调度策略再把消息再给队列。
rabbitmq中几个比价重要的概念如下: - Producer，生产者，创建消息，然后发布到rabbitmq中，消息一般可以包含两个部分：消息体（payload）和标签（label），消息体一般是带有业务逻辑结构的数据。 - Consumer，消费者，接收消息。消费者连接到rabbitmq服务器，并订阅到队列上。当消费者消费一条消息时，只是消费消息体，存入到队列中的消息只有消息体。 - Broker 消费中间件的服务节点。 - 交换机 生产者将消息发送到Exchange（交换器，通常也可以用大写的“X”来表示），由交换器将消息路由到一个或者多个队列中。如果路由不到，或许会返回给生产者，或许直接丢弃。

消息队列运转过程：

使用示例

下面介绍下python如何使用rabbitmq...