RabbitMQ学习总结（二）

1、简单队列模式

该模式不需要生命Exchange仅使用queue队列来直接交换消息。

消费者消息应答no-ack
channel.basic_consume(callback,queue='hello',no_ack=True)，默认情况no_ack=False表示consumer完成消息处理后需手动应答。向生队列服务器说明消息已处理完成，可以删除。
如果消费者遇到情况(its channel is closed, connection is closed, or TCP connection is lost)挂掉了，那么，RabbitMQ会重新将该任务添加到队列中，并由其他consumer获取该消息，确保消息不会丢失。
消费者回调函数中ch.basic_ack(delivery_tag=method.delivery_tag)，表示手动应答了服务器。

服务端持久化
RabbitMQ支持消息的持久化，也就是数据写在磁盘上，当我们需要可靠的消息处理的时候应该设置消息持久化。消息队列持久化包括3个部分:

(1)exchange持久化，在声明时指定durable => 1

(2)queue持久化，在声明时指定durable => 1

(3)消息持久化，在投递时指定delivery_mode => 2(1是非持久化)

如果exchange和queue都是持久化的，那么它们之间的binding也是持久化的。如果exchange和queue两者之间有一个持久化，一个非持久化，就不允许建立绑定。

 消息分发顺序

默认状态下，RabbitMQ将第n个Message分发给第n个Consumer。当然n是取余后的。它不管Consumer是否还有unacked Message，只是按照这个默认机制进行分发。那么如果有个Consumer工作比较重，那么就会导致有的Consumer基本没事可做，有的Consumer却是毫无休息的机会。那么，RabbitMQ是如何处理这种问题呢？
通过 basic.qos 方法设置prefetch_count=1 。这样RabbitMQ就会使得每个Consumer在同一个时间点最多处理一个Message。换句话说，在接收到该Consumer的ack前，他它不会将新的Message分发给它。


最终版本
设置消息确认，服务器的持久化，和消息分发顺序后，最终版本