RabbitMQ介绍 + python操作

一、消息队列　　

　　RabbitMQ是目前非常热门的一款消息中间件，不管是互联网大厂还是中小企业都在大量使用。

1.1 什么是消息队列

　　MQ全称为Message Queue，即消息队列。“消息队列”是在消息的传输过程中保存消息的容器。它是典型的：生产者、消费者模型。生产者不断向消息队列中生产消息，消费者不断的从队列中获取消息。因为消息的生产和消费都是异步的，而且只关心消息的发送和接收，没有业务逻辑的侵入，这样就实现了生产者和消费者的解耦。 

1.2 开发中消息队列通常有如下应用场景：

1、任务异步处理：

　　高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如说，大量的insert，update之类的请求同时到达MySQL，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。将不需要同步处理的并且耗时长的操作由消息队列通知消息接收方进行异步处理。减少了应用程序的响应时间。

2、应用程序解耦合：

　　MQ相当于一个中介，生产方通过MQ与消费方交互，它将应用程序进行解耦合。

1.3 AMQP和JMS

　　MQ是消息通信的模型，并发具体实现。现在实现MQ的有两种主流方式：AMQP、JMS。

　　两者间的区别和联系：

• JMS是定义了统一的接口，来对消息操作进行统一；AMQP是通过规定协议来统一数据交互的格式
• JMS限定了必须使用Java语言；AMQP只是协议，不规定实现方式，因此是跨语言的。
• JMS规定了两种消息模型；而AMQP的消息模型更加丰富

1.4 常见MQ产品

• ActiveMQ：基于JMS
• RabbitMQ：基于AMQP协议，erlang语言开发，稳定性好
• RocketMQ：基于JMS，阿里巴巴产品，目前交由Apache基金会
• Kafka：分布式消息系统，高吞吐量

二、RabbitMQ简介

　　以熟悉的电商场景为例，如果商品服务和订单服务是两个不同的微服务，在下单的过程中订单服务需要调用商品服务进行扣库存操作。按照传统的方式，下单过程要等到调用完毕之后才能返回下单成功，如果网络产生波动等原因使得商品服务扣库存延迟或者失败，会带来较差的用户体验，如果在高并发的场景下，这样的处理显然是不合适的，那怎么进行优化呢？这就需要消息队列登场了。

　　消息队列提供一个异步通信机制，消息的发送者不必一直等待到消息被成功处理才返回，而是立即返回。消息中间件负责处理网络通信，如果网络连接不可用，消息被暂存于队列当中，当网络畅通的时候在将消息转发给相应的应用程序或者服务，当然前提是这些服务订阅了该队列。如果在商品服务和订单服务之间使用消息中间件，既可以提高并发量，又降低服务之间的耦合度。

　　RabbitMQ就是这样一款我们苦苦追寻的消息队列。RabbitMQ是一个开源的消息代理的队列服务器，用来通过普通协议在完全不同的应用之间共享数据。

　　RabbitMQ是使用Erlang语言来编写的，并且RabbitMQ是基于AMQP协议的。Erlang语言在数据交互方面性能优秀，有着和原生Socket一样的延迟，这也是RabbitMQ高性能的原因所在。可谓“人如其名”，RabbitMQ像兔子一样迅速。

RabbitMQ除了像兔子一样跑的很快以外，还有这些特点：

• 开源、性能优秀，稳定性保障
• 提供可靠性消息投递模式、返回模式
• 与Spring AMQP完美整合，API丰富
• 集群模式丰富，表达式配置，HA模式，镜像队列模型
• 保证数据不丢失的前提做到高可靠性、可用性

MQ典型应用场景：

• 异步处理。把消息放入消息中间件中，等到需要的时候再去处理。
• 流量削峰。例如秒杀活动，在短时间内访问量急剧增加，使用消息队列，当消息队列满了就拒绝响应，跳转到错误页面，这样就可以使得系统不会因为超负载而崩溃。
• 日志处理
• 应用解耦。假设某个服务A需要给许多个服务（B、C、D）发送消息，当某个服务（例如B）不需要发送消息了，服务A需要改代码再次部署；当新加入一个服务（服务E）需要服务A的消息的时候，也需要改代码重新部署；另外服务A也要考虑其他服务挂掉，没有收到消息怎么办？要不要重新发送呢？是不是很麻烦，使用MQ发布订阅模式，服务A只生产消息发送到MQ，B、C、D从MQ中读取消息，需要A的消息就订阅，不需要了就取消订阅，服务A不再操心其他的事情，使用这种方式可以降低服务或者系统之间的耦合。

三、AMQP协议和RabbitMQ

　　提到RabbitMQ，就不得不提AMQP协议。AMQP协议是具有现代特征的二进制协议。是一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。

先了解一下AMQP协议中间的几个重要概念：

• Server：接收客户端的连接，实现AMQP实体服务。
• Connection：连接，应用程序与Server的网络连接，TCP连接。
• Channel：信道，消息读写等操作在信道中进行。客户端可以建立多个信道，每个信道代表一个会话任务。
• Message：消息，应用程序和服务器之间传送的数据，消息可以非常简单，也可以很复杂。有Properties和Body组成。Properties为外包装，可以对消息进行修饰，比如消息的优先级、延迟等高级特性；Body就是消息体内容。
• Virtual Host：虚拟主机，用于逻辑隔离。一个虚拟主机里面可以有若干个Exchange和Queue，同一个虚拟主机里面不能有相同名称的Exchange或Queue。
• Exchange：交换器，接收消息，按照路由规则将消息路由到一个或者多个队列。如果路由不到，或者返回给生产者，或者直接丢弃。RabbitMQ常用的交换器常用类型有direct、topic、fanout、headers四种，后面详细介绍。
• Binding：绑定，交换器和消息队列之间的虚拟连接，绑定中可以包含一个或者多个RoutingKey。
• RoutingKey：路由键，生产者将消息发送给交换器的时候，会发送一个RoutingKey，用来指定路由规则，这样交换器就知道把消息发送到哪个队列。路由键通常为一个“.”分割的字符串，例如“com.rabbitmq”。
• Queue：消息队列，用来保存消息，供消费者消费。

我们完全可以直接使用 Connection 就能完成信道的工作，为什么还要引入信道呢?
试想这样一个场景， 一个应用程序中有很多个线程需要从 RabbitMQ 中消费消息，或者生产消息，那么必然需要建立很多个 Connection，也就是许多个 TCP 连接。然而对于操作系统而言，建立和销毁 TCP 连接是非常昂贵的开销，如果遇到使用高峰，性能瓶颈也随之显现。 RabbitMQ 采用 TCP 连接复用的方式，不仅可以减少性能开销，同时也便于管理 。

　　下图是AMQP的协议模型：

　　正如图中所看到的，AMQP协议模型有三部分组成：生产者、消费者和服务端。

　　生产者是投递消息的一方：

1. 首先连接到Server，建立一个连接，开启一个信道；
2. 然后生产者声明交换器和队列，设置相关属性，并通过路由键将交换器和队列进行绑定。
3. 同理，消费者也需要进行建立连接，开启信道等操作，便于接收消息。
4. 接着生产者就可以发送消息，发送到服务端中的虚拟主机，虚拟主机中的交换器根据路由键选择路由规则，然后发送到不同的消息队列中，这样订阅了消息队列的消费者就可以获取到消息，进行消费。
5. 最后还要关闭信道和连接。

RabbitMQ是基于AMQP协议实现的，其结构如下图所示，和AMQP协议简直就是一模一样。

组成部分说明：

• Broker：消息队列服务进程，此进程包括两个部分：Exchange和Queue
• Exchange：消息队列交换机，按一定的规则将消息路由转发到某个队列，对消息进行过虑。
• Queue：消息队列，存储消息的队列，消息到达队列并转发给指定的
• Producer：消息生产者，即生产方客户端，生产方客户端将消息发送
• Consumer：消息消费者，即消费方客户端，接收MQ转发的消息。

生产者发送消息流程：

• 生产者和Broker建立TCP连接。
• 生产者和Broker建立通道。
• 生产者通过通道消息发送给Broker，由Exchange将消息进行转发。
• Exchange将消息转发到指定的Queue（队列）

消费者接收消息流程：

• 消费者和Broker建立TCP连接
• 消费者和Broker建立通道
• 消费者监听指定的Queue（队列）
• 当有消息到达Queue时Broker默认将消息推送给消费者。
• 消费者接收到消息。
• ack回复

四、常用交换器

　　RabbitMQ常用的交换器类型有direct、topic、fanout、headers四种。

4.1 Direct Exchange

　　该类型的交换器将所有发送到该交换器的消息被转发到RoutingKey指定的队列中，也就是说路由到BindingKey和RoutingKey完全匹配的队列中。

 4.2 Topic Exchange

　　该类型的交换器将所有发送到Topic Exchange的消息被转发到所有RoutingKey中指定的Topic的队列上面。

　　Exchange将RoutingKey和某Topic进行模糊匹配，其中“”用来匹配一个词，“#”用于匹配一个或者多个词。例如“com.#”能匹配到“com.rabbitmq.oa”和“com.rabbitmq”；而"login."只能匹配到“com.rabbitmq”。

 4.3 Fanout Exchange

　　该类型不处理路由键，会把所有发送到交换器的消息路由到所有绑定的队列中。优点是转发消息最快，性能最好。

4.4 Headers Exchange

　　该类型的交换器不依赖路由规则来路由消息，而是根据消息内容中的headers属性进行匹配。headers类型交换器性能差，在实际中并不常用。

五、6种消息模型

5.1 基本消息模型

在上图的模型中，有以下概念：

• P：生产者，也就是要发送消息的程序

• C：消费者：消息的接受者，会一直等待消息到来。

• queue：消息队列，图中红色部分。可以缓存消息；生产者向其中投递消息，消费者从其中取出消息。 

1、不用显示声明交换机，只需声明一个队列

2、生产者指定队列名发送消息给mq，然后会有一个默认的交换机将消息转发给这个队列。

3、消费者负责监听这个队列，一有消息就会得到通知做出响应。

消息确认机制（ACK）

消息一旦被消费者接收，队列中的消息就会被删除。那么问题来了：RabbitMQ怎么知道消息被接收了呢？

如果消费者领取消息后，还没执行操作就挂掉了呢？或者抛出了异常？消息消费失败，但是RabbitMQ无从得知，这样消息就丢失了！

因此，RabbitMQ有一个ACK机制。当消费者获取消息后，会向RabbitMQ发送回执ACK，告知消息已经被接收。

回执ACK分两种情况：

1. 自动ACK：消息一旦被接收，消费者自动发送ACK。如果消息不太重要，丢失也没有影响，那么自动ACK会比较方便
2. 手动ACK：消息接收后，不会发送ACK，需要手动调用。如果消息非常重要，不容丢失。那么最好在消费完成后手动ACK，否则接收消息后就自动ACK，RabbitMQ就会把消息从队列中删除。如果此时消费者宕机，那么消息就丢失了。

所以消息有三种状态：

5.2 work消息模型

工作队列或者竞争消费者模式

　　work queues与入门程序相比，多了一个消费端，两个消费端共同消费同一个队列中的消息，但是一个消息只能被一个消费者获取。

　　这个消息模型在Web应用程序中特别有用，可以处理短的HTTP请求窗口中无法处理复杂的任务。

接下来我们来模拟这个流程：

• P：生产者：任务的发布者
• C1：消费者1：领取任务并且完成任务，假设完成速度较慢（模拟耗时）
• C2：消费者2：领取任务并且完成任务，假设完成速度较快

1、和简单队列模式基本一样，不过有一点不同，该模式有多个消费者在监听队列。

2、rabbitmq会以轮询的方式将消息发给多个消费者确保一条消息只会被一个消费者消费

3、任务分发默认使用的是公平队列调度的原则

5.3 Publish/subscribe（发布订阅模式 - 本质用的交换器是Fanout）

Publish/subscribe模型示意图 ：

1. 和上面2种模式默认提供交换机不同的是，该模式需要显示声明交换机，
2. 然后可以创建多个队列和这个交换机进行绑定。
3. 生产者发消息给mq时需要指定交换机，然后交换机将消息转发给与自己绑定的所有队列
4. 消费者监听指定的队列获得消息。每个队列可以有多个消费者监听，同样也是以轮询的机制发给消费者
5. 实际使用Exchange的广播路由模式（Fanout）

生产者

和前面两种模式不同：

• 1） 声明Exchange，不再声明Queue

• 2） 发送消息到Exchange，不再发送到Queue

订阅模型分类
说明下：

1. 一个生产者多个消费者
2. 每个消费者都有一个自己的队列
3. 生产者没有将消息直接发送给队列，而是发送给exchange(交换机、转发器)
4. 每个队列都需要绑定到交换机上
5. 生产者发送的消息，经过交换机到达队列，实现一个消息被多个消费者消费
6. 例子：注册->发邮件、发短信

　　X（Exchanges）：交换机一方面：接收生产者发送的消息。另一方面：知道如何处理消息，例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作，取决于Exchange的类型。

Exchange类型有以下几种：

• Fanout：广播，将消息交给所有绑定到交换机的队列
• Direct：定向（路由），把消息交给符合指定routing key 的队列
• Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列
• Header：header模式与routing不同的地方在于，header模式取消routingkey，使用header中的 key/value（键值对）匹配队列。
• Header模式不展开了，感兴趣可以参考这篇文章https://blog.csdn.net/zhu_tianwei/article/details/40923131

Exchange（交换机）只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑定，或者没有符合路由规则的队列，那么消息会丢失！

思考：

　　思考1：publish/subscribe与work queues有什么区别。

区别：

　　1）work queues不用定义交换机，而publish/subscribe需要定义交换机。

　　2）publish/subscribe的生产方是面向交换机发送消息，work queues的生产方是面向队列发送消息(底层使用默认交换机)。

　　3）publish/subscribe需要设置队列和交换机的绑定，work queues不需要设置，实际上work queues会将队列绑定到默认的交换机 。

相同点：

　　所以两者实现的发布/订阅的效果是一样的，多个消费端监听同一个队列不会重复消费消息。

　　思考2：实际工作用 publish/subscribe还是work queues。

　　建议使用 publish/subscribe，发布订阅模式比工作队列模式更强大（也可以做到同一队列竞争），并且发布订阅模式可以指定自己专用的交换机。

5.4 Routing 路由模型（交换机类型：direct）

Routing模型示意图：

 

P：生产者，向Exchange发送消息，发送消息时，会指定一个routing key。

X：Exchange（交换机），接收生产者的消息，然后把消息递交给 与routing key完全匹配的队列

C1：消费者，其所在队列指定了需要routing key 为 error 的消息

C2：消费者，其所在队列指定了需要routing key 为 info、error、warning 的消息

5.5 Topics 通配符模式（交换机类型：topics）

Topics模型示意图：

　　每个消费者监听自己的队列，并且设置带统配符的routingkey,生产者将消息发给broker，由交换机根据routingkey来转发消息到指定的队列。

　　Routingkey一般都是有一个或者多个单词组成，多个单词之间以“.”分割，例如：inform.sms

通配符规则：

通配符规则：

#：匹配一个或多个词
*：匹配不多不少恰好1个词

举例：

audit.#：能够匹配audit.irs.corporate 或者 audit.irs
audit.*：只能匹配audit.irs

5.6 RPC

RPC模型示意图：

基本概念：

　　Callback queue 回调队列，客户端向服务器发送请求，服务器端处理请求后，将其处理结果保存在一个存储体中。而客户端为了获得处理结果，那么客户在向服务器发送请求时，同时发送一个回调队列地址reply_to。

　　Correlation id 关联标识，客户端可能会发送多个请求给服务器，当服务器处理完后，客户端无法辨别在回调队列中的响应具体和那个请求时对应的。为了处理这种情况，客户端在发送每个请求时，同时会附带一个独有correlation_id属性，这样客户端在回调队列中根据correlation_id字段的值就可以分辨此响应属于哪个请求。

流程说明：

1. 当客户端启动的时候，它创建一个匿名独享的回调队列。
2. 在 RPC 请求中，客户端发送带有两个属性的消息：一个是设置回调队列的 reply_to 属性，另一个是设置唯一值的 correlation_id 属性。
3. 将请求发送到一个 rpc_queue 队列中。
4. 服务器等待请求发送到这个队列中来。当请求出现的时候，它执行他的工作并且将带有执行结果的消息发送给 reply_to 字段指定的队列。
5. 客户端等待回调队列里的数据。当有消息出现的时候，它会检查 correlation_id 属性。如果此属性的值与请求匹配，将它返回给应用

面试题：

1、避免消息堆积？

1） 采用workqueue，多个消费者监听同一队列。
2）接收到消息以后，而是通过线程池，异步消费。

2、如何避免消息丢失？

1） 消费者的ACK机制。可以防止消费者丢失消息。
但是，如果在消费者消费之前，MQ就宕机了，消息就没了？
2）可以将消息进行持久化。要将消息持久化，前提是：队列、Exchange都持久化

六、高级特性

6.1 过期时间（TTL）

　　Time To Live，也就是生存时间，是一条消息在队列中的最大存活时间，单位是毫秒。了解Redis的朋友应该一看就明白，二者很像。

　　RabbitMQ可以对消息和队列设置TTL。

　　RabbitMQ支持设置消息的过期时间，在消息发送的时候可以进行指定，每条消息的过期时间可以不同。

　　RabbitMQ支持设置队列的过期时间，从消息入队列开始计算，直到超过了队列的超时时间配置，那么消息会变成死信，自动清除。

　　如果两种方式一起使用，则过期时间以两者中较小的那个数值为准。

　　当然也可以不设置TTL，不设置表示消息不会过期；如果设置为0，则表示除非此时可以直接将消息投递到消费者，否则该消息将被立即丢弃。

6.2 消息确认

　　为了保证消息从队列可靠地到达消费者，RabbitMQ提供了消息确认机制。消费者订阅队列的时候，可以指定autoAck参数，当autoAck为true的时候，RabbitMQ采用自动确认模式，RabbitMQ自动把发送出去的消息设置为确认，然后从内存或者硬盘中删除，而不管消费者是否真正消费到了这些消息。当autoAck为false的时候，RabbitMQ会等待消费者回复的确认信号，收到确认信号之后才从内存或者磁盘中删除消息。

　　消息确认机制是RabbitMQ消息可靠性投递的基础，只要设置autoAck参数为false，消费者就有足够的时间处理消息，不用担心处理消息的过程中消费者进程挂掉后消息丢失的问题。

6.3 持久化

　　消息的可靠性是RabbitMQ的一大特色，那么RabbitMQ是如何保证消息可靠性的呢？答案就是消息持久化。持久化可以防止在异常情况下丢失数据。RabbitMQ的持久化分为三个部分：交换器持久化、队列持久化和消息的持久化。

　　交换器持久化可以通过在声明队列时将durable参数设置为true。如果交换器不设置持久化，那么在RabbitMQ服务重启之后，相关的交换器元数据会丢失，不过消息不会丢失，只是不能将消息发送到这个交换器了。

　　队列的持久化能保证其本身的元数据不会因异常情况而丢失，但是不能保证内部所存储的消息不会丢失。要确保消息不会丢失，需要将其设置为持久化。队列的持久化可以通过在声明队列时将durable参数设置为true。

　　设置了队列和消息的持久化，当RabbitMQ服务重启之后，消息依然存在。如果只设置队列持久化或者消息持久化，重启之后消息都会消失。

　　当然，也可以将所有的消息都设置为持久化，但是这样做会影响RabbitMQ的性能，因为磁盘的写入速度比内存的写入要慢得多。对于可靠性不是那么高的消息可以不采用持久化处理以提高整体的吞吐量。鱼和熊掌不可兼得，关键在于选择和取舍。在实际中，需要根据实际情况在可靠性和吞吐量之间做一个权衡。

6.4 死信队列

　　当消息在一个队列中变成死信之后，他能被重新发送到另一个交换器中，这个交换器成为死信交换器，与该交换器绑定的队列称为死信队列。

消息变成死信有下面几种情况:

• 消息被拒绝。通过调用basic.reject或者basic.nack并且设置requeue=false。
• 消息过期
• 队列达到最大长度

DLX也是一个正常的交换器，和一般的交换器没有区别，他能在任何的队列上面被指定，实际上就是设置某个队列的属性。当这个队列中有死信的时候，RabbitMQ会自动将这个消息重新发送到设置的交换器上，进而被路由到另一个队列，我们可以监听这个队列中消息做相应的处理。

死信队列设置：

• 设置死信队列的exchange和queue，然后进行绑定

• • Exchange：dlx.exchange
  • Queue：dlx.queue
  • RoutingKey：#

• 然后进行正常声明交换器、队列、绑定，只不过我们需要在队列上加一个参数即可：arguments.put（“x-dead-letter-exchange”,“dlx.exchange”）

死信队列有什么用？

　　当发生异常的时候，消息不能够被消费者正常消费，被加入到了死信队列中。后续的程序可以根据死信队列中的内容分析当时发生的异常，进而改善和优化系统。

https://blog.csdn.net/zhangcongyi420/article/details/100126666

6.5 延迟队列

　　一般的队列，消息一旦进入队列就会被消费者立即消费。延迟队列就是进入该队列的消息会被消费者延迟消费，延迟队列中存储的对象是的延迟消息，“延迟消息”是指当消息被发送以后，等待特定的时间后，消费者才能拿到这个消息进行消费。

　　延迟队列用于需要延迟工作的场景。最常见的使用场景：淘宝或者天猫我们都使用过，用户在下单之后通常有30分钟的时间进行支付，如果这30分钟之内没有支付成功，那么订单就会自动取消。除了延迟消费，延迟队列的典型应用场景还有延迟重试。比如消费者从队列里面消费消息失败了，可以延迟一段时间以后进行重试。

七、python操作mq 

7.1 RabbitMQ安装

ubuntu系统

install rabbitmq-server # 直接搞定

centos系统

1)Install Erlang

 1）Install Erlang
 # For EL5:
 rpm -Uvh http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
 # For EL6:
 rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
 # For EL7:
 rpm -Uvh http://download.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-8.noarch.rpm
 yum install erlang

2)Install RabbitMQ Server

rpm --import https://www.rabbitmq.com/rabbitmq-release-signing-key.asc
yum install rabbitmq-server-3.6.5-1.noarch.rpm

3)use RabbitMQ Server

chkconfig rabbitmq-server on
service rabbitmq-server stop/start

八、python 操作RabbitMq详解

8.1 基本实例

生产者（producter）：队列消息的产生者，负责生产消息，并将消息传入队列

import pika
import json

credentials = pika.PlainCredentials('shampoo', '123456')  # mq用户名和密码
# 虚拟队列需要指定参数 virtual_host，如果是默认的可以不填。
connection = pika.BlockingConnection(pika.ConnectionParameters(host = '10.1.62.170',port = 5672,virtual_host = '/',credentials = credentials))
channel=connection.channel()
# 声明消息队列，消息将在这个队列传递，如不存在，则创建
result = channel.queue_declare(queue = 'python-test')

for i in range(10):
    message=json.dumps({'OrderId':"1000%s"%i})
# 向队列插入数值 routing_key是队列名
    channel.basic_publish(exchange = '',routing_key = 'python-test',body = message)
    print(message)
connection.close()

消费者（consumer）：队列消息的接收者，负责 接收并处理 消息队列中的消息

import pika

credentials = pika.PlainCredentials('shampoo', '123456')
connection = pika.BlockingConnection(pika.ConnectionParameters(host = '10.1.62.170',port = 5672,virtual_host = '/',credentials = credentials))
channel = connection.channel()
# 申明消息队列，消息在这个队列传递，如果不存在，则创建队列
channel.queue_declare(queue = 'python-test', durable = False)
# 定义一个回调函数来处理消息队列中的消息，这里是打印出来
def callback(ch, method, properties, body):
    ch.basic_ack(delivery_tag = method.delivery_tag)   # 手动ack，配合no ack = False 使用
    print(body.decode())

# channel.basic_qos(prefetch_count=1) 
# 告诉rabbitmq，用callback来接收消息
channel.basic_consume(# 消费消息
    callback, # 如果收到消息，就调用callback函数来处理消息
    queue='hello',# 要消费的队列
    # no ack=True # 消息确认
    # 一般不写。宕机则生产者检测到发给其他消费者
    )
# 开始接收信息，并进入阻塞状态，队列里有信息才会调用callback进行处理
channel.start_consuming()

非阻塞版数据接收：

启用会立即返回结果，如果有数据则进入回调函数，无数据则进行下一条，可以配合while使用

conn.process_data_events() #使用连接对象进行数据接收判断
print("无数据")

8.3.RabbitMQ消息分发轮询

一个生产者多个消费者
采用轮询机制；把消息依次分发
假如消费者处理雄安熙需要15秒，如果宕机了，那这个消息处理还没有处理完，怎么处理？
（可以模拟消费端断了，分别注释和不注释no_ack=True看一下）
没有回复，就代表消息没有处理完，
上面的效果消费端断了就转到另外一个消费端去了，但是生产者怎么知道消费端断了呢？
因为生产者和消费者是通过socket连接的，socket断了，就说明消费端断开了。

上面的模式只是依次分发，实际情况是机器配置不一样。怎么设置类似权重的操作？
RabbitMQ怎么办呢，RabbitMQ做了简单的处理就能实现公平的分发。
就是RabbitMQ给消费者发消息的时候检测下消费者里的消息数量，如果超过指定值（比如1条），就不给你发了。
只需要在消费者端，channel.basic_consume前加上就可以了。

channel.basic_qos(prefetch_count=1)# 类似权重，按能力分发，如果有一个消息，就不在给你发
channel.basic_consume(） # 消费消息

8.4 持久化

　　MQ默认建立的是临时 queue 和 exchange，如果不声明持久化，一旦 rabbitmq 挂掉，queue、exchange 将会全部丢失。所以我们一般在创建 queue 或者 exchange 的时候会声明 持久化。

1.queue 声明持久化

# 声明消息队列，消息将在这个队列传递，如不存在，则创建。durable = True 代表消息队列持久化存储，False 非持久化存储
result = channel.queue_declare(queue = 'python-test',durable = True)

2.exchange 声明持久化

# 声明exchange，由exchange指定消息在哪个队列传递，如不存在，则创建.durable = True 代表exchange持久化存储，False 非持久化存储
channel.exchange_declare(exchange = 'python-test', durable = True)

　　注意：如果已存在一个非持久化的 queue 或 exchange ，执行上述代码会报错，因为当前状态不能更改 queue 或 exchange 存储属性，需要删除重建。如果 queue 和 exchange 中一个声明了持久化，另一个没有声明持久化，则不允许绑定。

3.消息持久化

　　虽然 exchange 和 queue 都申明了持久化，但如果消息只存在内存里，rabbitmq 重启后，内存里的东西还是会丢失。所以必须声明消息也是持久化，从内存转存到硬盘。

# 向队列插入数值 routing_key是队列名。delivery_mode = 2 声明消息在队列中持久化，delivery_mod = 1 消息非持久化
    channel.basic_publish(exchange = '',routing_key = 'python-test',body = message,
                          properties=pika.BasicProperties(delivery_mode = 2))

4.acknowledgement 消息不丢失

　　消费者（consumer）调用callback函数时，会存在处理消息失败的风险，如果处理失败，则消息丢失。但是也可以选择消费者处理失败时，将消息回退给 rabbitmq ，重新再被消费者消费，这个时候需要设置确认标识。

channel.basic_consume(callback,queue = 'python-test',
# no_ack 设置成 False，在调用callback函数时，未收到确认标识，消息会重回队列。True，无论调用callback成功与否，消息都被消费掉
                      no_ack = False)

八、RabbitMq 发布与订阅

　　rabbitmq 的发布与订阅要借助交换机（Exchange）的原理实现：

 

Exchange 一共有三种工作模式：fanout, direct, topicd（Headers 不用）

8.1 模式一：fanout

这种模式下，传递到 exchange 的消息将会转发到所有与其绑定的 queue 上。

• 不需要指定 routing_key ，即使指定了也是无效。
• 需要提前将 exchange 和 queue 绑定，一个 exchange 可以绑定多个 queue，一个queue可以绑定多个exchange。
• 需要先启动 订阅者，此模式下的队列是 consumer 随机生成的，发布者 仅仅发布消息到 exchange ，由 exchange 转发消息至 queue。

发布者：

import pika
import json

credentials = pika.PlainCredentials('shampoo', '123456')  # mq用户名和密码
# 虚拟队列需要指定参数 virtual_host，如果是默认的可以不填。
connection = pika.BlockingConnection(pika.ConnectionParameters(host = '10.1.62.170',port = 5672,virtual_host = '/',credentials = credentials))
channel=connection.channel()
# 声明exchange，由exchange指定消息在哪个队列传递，如不存在，则创建。durable = True 代表exchange持久化存储，False 非持久化存储
channel.exchange_declare(exchange = 'python-test',durable = True, exchange_type='fanout')
for i in range(10):
    message=json.dumps({'OrderId':"1000%s"%i})
# 向队列插入数值 routing_key是队列名。delivery_mode = 2 声明消息在队列中持久化，delivery_mod = 1 消息非持久化。routing_key 不需要配置
    channel.basic_publish(exchange = 'python-test',routing_key = '',body = message,
                          properties=pika.BasicProperties(delivery_mode = 2))
    print(message)
connection.close()

订阅者：

import pika

credentials = pika.PlainCredentials('shampoo', '123456')
connection = pika.BlockingConnection(pika.ConnectionParameters(host = '10.1.62.170',port = 5672,virtual_host = '/',credentials = credentials))
channel = connection.channel()
# 创建临时队列,队列名传空字符，consumer关闭后，队列自动删除
result = channel.queue_declare('',exclusive=True)
# 声明exchange，由exchange指定消息在哪个队列传递，如不存在，则创建。durable = True 代表exchange持久化存储，False 非持久化存储
channel.exchange_declare(exchange = 'python-test',durable = True, exchange_type='fanout')
# 绑定exchange和队列  exchange 使我们能够确切地指定消息应该到哪个队列去
channel.queue_bind(exchange = 'python-test',queue = result.method.queue)
# 定义一个回调函数来处理消息队列中的消息，这里是打印出来
def callback(ch, method, properties, body):
    ch.basic_ack(delivery_tag = method.delivery_tag)
    print(body.decode())

channel.basic_consume(result.method.queue,callback,# 设置成 False，在调用callback函数时，未收到确认标识，消息会重回队列。True，无论调用callback成功与否，消息都被消费掉
                      auto_ack = False)
channel.start_consuming()

8.2 模式二：direct

这种工作模式的原理是 消息发送至 exchange，exchange 根据 路由键（routing_key）转发到相对应的 queue 上。

•  可以使用默认 exchange =' ' ，也可以自定义 exchange
• 这种模式下不需要将 exchange 和 任何进行绑定，当然绑定也是可以的。可以将 exchange 和 queue ，routing_key 和 queue 进行绑定
• 传递或接受消息时 需要 指定 routing_key
• 需要先启动 订阅者，此模式下的队列是 consumer 随机生成的，发布者 仅仅发布消息到 exchange ，由 exchange 转发消息至 queue。

发布者：

import pika
import json

credentials = pika.PlainCredentials('shampoo', '123456')  # mq用户名和密码
# 虚拟队列需要指定参数 virtual_host，如果是默认的可以不填。
connection = pika.BlockingConnection(pika.ConnectionParameters(host = '10.1.62.170',port = 5672,virtual_host = '/',credentials = credentials))
channel=connection.channel()
# 声明exchange，由exchange指定消息在哪个队列传递，如不存在，则创建。durable = True 代表exchange持久化存储，False 非持久化存储
channel.exchange_declare(exchange = 'python-test',durable = True, exchange_type='direct')

for i in range(10):
    message=json.dumps({'OrderId':"1000%s"%i})
# 指定 routing_key。delivery_mode = 2 声明消息在队列中持久化，delivery_mod = 1 消息非持久化
    channel.basic_publish(exchange = 'python-test',routing_key = 'OrderId',body = message,
                          properties=pika.BasicProperties(delivery_mode = 2))
    print(message)
connection.close()

消费者：

import pika

credentials = pika.PlainCredentials('shampoo', '123456')
connection = pika.BlockingConnection(pika.ConnectionParameters(host = '10.1.62.170',port = 5672,virtual_host = '/',credentials = credentials))
channel = connection.channel()
# 创建临时队列，队列名传空字符，consumer关闭后，队列自动删除
result = channel.queue_declare('',exclusive=True)
# 声明exchange，由exchange指定消息在哪个队列传递，如不存在，则创建。durable = True 代表exchange持久化存储，False 非持久化存储
channel.exchange_declare(exchange = 'python-test',durable = True, exchange_type='direct')
# 绑定exchange和队列  exchange 使我们能够确切地指定消息应该到哪个队列去
channel.queue_bind(exchange = 'python-test',queue = result.method.queue,routing_key='OrderId')
# 定义一个回调函数来处理消息队列中的消息，这里是打印出来
def callback(ch, method, properties, body):
    ch.basic_ack(delivery_tag = method.delivery_tag)
    print(body.decode())


#channel.basic_qos(prefetch_count=1)
# 告诉rabbitmq，用callback来接受消息
channel.basic_consume(result.method.queue,callback,
# 设置成 False，在调用callback函数时，未收到确认标识，消息会重回队列。True，无论调用callback成功与否，消息都被消费掉
                      auto_ack = False)
channel.start_consuming()

8.3 模式三：topicd

　　这种模式和第二种模式差不多，exchange 也是通过 路由键 routing_key 来转发消息到指定的 queue 。 不同点是 routing_key 使用正则表达式支持模糊匹配，但匹配规则又与常规的正则表达式不同，比如“#”是匹配全部，“*”是匹配一个词。

举例：routing_key =“#orderid#”，意思是将消息转发至所有 routing_key 包含 “orderid” 字符的队列中。代码和模式二 类似，就不贴出来了。

九、RabbitMQ RPC 实现（Remote procedure call）

　　不知道你有没有发现，上面的流都是单向的，如果远程的机器执行完返回结果，就实现不了了。
　　如果返回，这种模式叫什么呢，RPC（远程过程调用），snmp就是典型的RPC
　　RabbitMQ能不能返回呢，怎么返回呢？既是发送端又是接收端。
　　但是接收端返回消息怎么返回？可以发送到发过来的queue里么？不可以。
　　返回时，再建立一个queue，把结果发送新的queue里
　　为了服务端返回的queue不写死，在客户端给服务端发指令的的时候，同时带一条消息说，你结果返回给哪个queue

RPC client

import pika
import uuid
import time
 
class FibonacciRpcClient(object):
  def __init__(self):
    self.connection = pika.BlockingConnection(pika.ConnectionParameters(
        host='localhost'))
    self.channel = self.connection.channel()
    result = self.channel.queue_declare(exclusive=True)
    self.callback_queue = result.method.queue
 
    self.channel.basic_consume(self.on_response, # 只要一收到消息就调用on_response
                  no_ack=True,
                  queue=self.callback_queue) # 收这个queue的消息
 
  def on_response(self, ch, method, props, body): # 必须四个参数
    # 如果收到的ID和本机生成的相同，则返回的结果就是我想要的指令返回的结果
    if self.corr_id == props.correlation_id:
      self.response = body
 
  def call(self, n):
    self.response = None # 初始self.response为None
    self.corr_id = str(uuid.uuid4()) # 随机唯一字符串
    self.channel.basic_publish(
        exchange='',
        routing_key='rpc_queue', # 发消息到rpc_queue
        properties=pika.BasicProperties( # 消息持久化
          reply_to = self.callback_queue, # 让服务端命令结果返回到callback_queue
          correlation_id = self.corr_id, # 把随机uuid同时发给服务器
        ),
        body=str(n)
    )
    while self.response is None: # 当没有数据，就一直循环
      # 启动后，on_response函数接到消息，self.response 值就不为空了
      self.connection.process_data_events() # 非阻塞版的start_consuming()
      # print("no msg……")
      # time.sleep(0.5)
    # 收到消息就调用on_response
    return int(self.response)
 
if __name__ == '__main__':
  fibonacci_rpc = FibonacciRpcClient()
  print(" [x] Requesting fib(7)")
  response = fibonacci_rpc.call(7)
  print(" [.] Got %r" % response)

RPC server

import pika
import time
 
def fib(n):
  if n == 0:
    return 0
  elif n == 1:
    return 1
  else:
    return fib(n-1) + fib(n-2)
 
def on_request(ch, method, props, body):
  n = int(body)
  print(" [.] fib(%s)" % n)
  response = fib(n)
 
  ch.basic_publish(
      exchange='', # 把执行结果发回给客户端
      routing_key=props.reply_to, # 客户端要求返回想用的queue
      # 返回客户端发过来的correction_id 为了让客户端验证消息一致性
      properties=pika.BasicProperties(correlation_id = props.correlation_id),
      body=str(response)
  )
  ch.basic_ack(delivery_tag = method.delivery_tag) # 任务完成，告诉客户端
 
if __name__ == '__main__':
  connection = pika.BlockingConnection(pika.ConnectionParameters(
      host='localhost'))
  channel = connection.channel()
  channel.queue_declare(queue='rpc_queue') # 声明一个rpc_queue ,
 
  channel.basic_qos(prefetch_count=1)
  # 在rpc_queue里收消息,收到消息就调用on_request
  channel.basic_consume(on_request, queue='rpc_queue')
  print(" [x] Awaiting RPC requests")
  channel.start_consuming()

https://blog.csdn.net/weixin_44120629/article/details/88789529