https://www.cnblogs.com/aspirant/p/9451239.html

什么是MQ

MQ全称为Message Queue，消息队列（MQ）是一种应用程序对应应用程序的通信方法。MQ是消费-生产者模型的一个典型的代表。一端往消息队列中不断写入消息，而另一端则可以读取队列中的消息

RabbitMQ是MQ的一种。下面详细介绍下RabbitMQ的基本概念

1.队列、生产者、消费者

队列是RabbitMQ的内部对象，用于存储消息。生产者（下图中的P）生成消息并投递到队列中，消费者（下图中的C）可以从队列中获取消息并消费。

多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理

2.Exchange、Binding

刚才我们看到生产者将消息投递到队列中，实际上这在RabbitMQ中这种事情永远都不会发生。实际的情况是，生产者将消息发送到Exchange（交换器，下图中X），再通过Binding将Exchange与Queue关联起来

3.Exchange Type、Binding key、routing key

在绑定（binding）Exchange与Queue的同时，一般会指定一个binding key。在绑定多个Queue 到同一个Exchange 的时候，这些Binding 允许使用相同的binding key。

生产者在将消息发送给Exchange 的时候，一般会指定一个routing key，来指定这个消息的路由规则，生产者就可以在发送消息给Exchange时，通过指定routing key 来决定消息流向哪里。

RabbitMQ常用的Exchange Type有三种：fanout、direct、topic

fanout：

把所有发送到该Exchange 的消息投递到所有与它绑定的队列中

direct：

把消息投递到那些binding key与 routing key 完全匹配的队列中

topic：

将消息路由到binding key与 routing key 模式匹配的队列中

RabbitMQ的结构图

解析问题

1.可以自动创建队列，也可以手动创建队列，如果自动创建队列，那么是谁负责创建队列呢？是生产者还是消费者

如果队列不存在，当然消费者不会收到任何消息。但是如果队列不存在，那么生产者发送的消息就会丢失。所以，为了数据不丢失，消费者和生产者都可以创建队列。

那么如果创建一个已经存在的队列呢。

需要注意的是没有任何影响，也就是说第二次创建如果参数和第一次不一样，那么该操作虽然成功，但是队列属性并不会改变。
队列对于负载均衡的处理是完美的。对于多个消费者来说，RabbitMQ使用轮询的方式均衡的发送给不同的消费者。

2.RabbitMQ的消息确认机制

默认情况下。如果消息已经被某个消费者正确的接收到了，那么该消息就会被从队列中移除。当然也可以让同一个消息发送到很多的消费者。

如果一个队列没有消费者，那么，如果这个队列有数据到达，那么这个数据就会被缓存，不会被丢弃。当有消费者时，这个数据会被立即发送到这个消费者，这个数据被消费者正确收到时，这个数据就被从队列中删除。
那么什么是正确收到呢？通过ack。每个消息抖音被acknowledged（确认，ack）。我们可以显示的在程序中去ack，也可以自动的ack。如果有数据没有被ack，那么：
RabbitMQ Server会把这个信息发送到下一个消费者
如果这个app有bug，忘记了ack，那么RabbitMQ Server不会再发送数据给他，因为Server 认为这个消费者处理能力有限
而且ack 的机制可以起到限流的作用（Benefitto throttling）：在消费者处理完成数据后发送ack，甚至在额外的延时后发送ack，将有效的均衡消费者的负载。

1.背景

RabbitMQ是一个由erlang 开发的AMQP（Advanced Message Queue）的开源实现。

2.应用场景

2.1异步处理

场景说明：用户注册后，需要发注册邮件和注册短信，传统的做法有两种，1串行的方式，2并行的方式
1.串行方式：
将注册信息写入数据库后，发送注册邮件，在发送注册短信，以上三个任务全部完成后，才返回给客户端。这有一个问题是，邮件，短信并不是必须的，他只是一个通知，而这种做法让客户端等待没必要等待的东西

2.并行方式
将注册信息写入数据库后，发送邮件的同时，发送短信，以上三个任务完成后，返回给客户端，并行的方式能提高处理的时间。

假设三个业务节点分别用时50ms，串行方式使用150ms，并行使用时间100ms，虽然性能已经提高了处理时间，但是，前面说过，邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功，应该是写入数据后就返回。
3.消息队列
引入消息队列后，把发送邮件，短信 不是必须的业务逻辑异步处理

由此可见，引入消息队列后，用户的响应时间就等于写入数据库时间+写入消息队列的时间，引入消息队列后处理后，响应时间是串行的3倍，是并行的2倍。

2.2应用解耦

场景：双11是购物狂欢节，用户下单后，订单系统需要通知库存系统，传统做法就是订单系统调用库存系统的接口。

这种做法有一个缺点

1. 当库存系统出现故障时，订单就会失败
2. 订单系统和库存系统高耦合

引入消息队列

1. 订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。

2. 库存系统：订阅下单的消息，获取下单消息，进行库操作。

   1. 就算库存出现故障，消息队列也能保证消息的可靠投递，不会导致消息丢失。

      流量削峰

      流量削峰一般在秒杀活动中应用广泛
      场景：秒杀活动，一般会因为流量过大，导致应用挂掉，为了解决这个问题，一般在应用前端加入消息队列
      作用：

3. 可以控制活动人数，超过此一定阈值的订单直接丢弃

4. 可以缓解短时间的高流量压垮应用（应用程序按自己的最大处理能力获得订单）

1. 用户的请求，服务器收到之后，首先写入消息队列，加入消息队列长度超过最大值，则直接抛弃用户请求或跳转到错误页面
2. 秒杀业务根据消息队列中的请求信息，在做后续处理。

3.系统架构

几个概念说明：

Broker

提供一种传输服务，他的角色就是维护一条从生产者到消费者的路线，保证数据能按照指定的方式进行传输

Exchange

消息交换机，他指定消息按照什么规则，路由到那个队列

Queue

消息的载体，每个消息都会被投放到一个或多个队列

Binding

绑定，他的作用就是把exchange和queue 按照路由规则绑定起来

Routing Key

路由关键字，exchange根据这个关键字进行消息投递

vhost

虚拟主机，一个broker里可以有多个vhost，用作不同用户的权限分离

Producer

消息生产者，就是投递消息的程序

Consumer

消息消费者，就是接收消息的程序

Channel

消息通道，在客户端的每个连接里，可以建立多个channel

4.任务分发机制

4.1Routing-robin dispathching循环分发

RabbitMQ的分发机制非常适合扩展，而且他是专门为并发程序设计的，如果现在load加重，那么只需要创建更多的Consumer 来进行任务处理。

4.2Message acknowledgment 消息确认

为了保证数据不被丢失，RabbitMQ支持消息确认机制，为了保证数据能被正确处理而不仅仅是被Consumer收到，那么我们不能采用no-ack，而应该是在处理完数据之后发送ack
在处理完数据之后发送ack，就是告诉RabbitMQ数据已经被接收，处理完成，RabbitMQ可以安全的删除他了，如果Consumer退出了但是没有发送ack，那么RabbitMQ就会把这个Message发送到下一个Consumer，这样就保证在Consumer异常退出情况下数据也不会丢失
RabbitMQ没有用到超时机制。RabbitMQ仅仅通过Consumer的连接中断来确认该Message并没有正确处理，也就是说RabbitMQ给了Consumer足够长的时间来做数据处理
如果忘记ack，那么当Consumer退出时，Message会重新分发，然后RabbitMQ会占用越来越多的内存。

5.Message durability消息持久化

要持久化队列queue的持久化需要在声明中指定durable = True
注意：队列的名字一定要是Broker中不存在的，不然不能改变此队列的任何属性
队列和交换机有一个创建时候指定的标志durable，durable的唯一含义就是具有这个标志的队列和交换机会在重启之后重新建立，他不表示说在队列中的消息会在重启后恢复
消息持久化包括3部分

1.exchange持久化，在声明时指定durable => true

hannel.ExchangeDeclare(ExchangeName, "direct", durable: true, autoDelete: false, arguments: null);//声明消息队列，且为可持久化的

2.queue持久化，在声明时指定durable => true

channel.QueueDeclare(QueueName, durable: true, exclusive: false, autoDelete: false, arguments: null);//声明消息队列，且为可持久化的

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

channel.basicPublish("", queueName, MessageProperties.PERSISTENT_TEXT_PLAIN, msg.getBytes());

如果exchange和queue都是持久化的，那么他们之间的binding也是持久化的，如果exchange和queue两者之间有一个持久化，一个非持久化，则不允许建立绑定
注意：一旦创建了队列和交换机，就不能修改其标志了，例如，创建了一个non-durable的队列，然后想把他改变成durable，唯一的办法就是删除这个队列然后重新创建。

6.Fair dispath 公平分发

分发机制不是那么优雅，默认状态下，RabbitMQ将第n个Message分发给第n个Consumer。n是取余后的，他不管Consumer是否还有unacked Message，只是按照这个默认的机制进行分发。
那么如果有个Consumer工作比较重，那么就会导致有的Consumer基本没事可做，有的Consumer却毫无休息的机会，RabbitMQ是如何处理这种问题呢？

通过basic.qos方法设置prefetch_count = 1,这样RabbitMQ就会使得每个Consumer在同一个时间点最多处理一个Message，换句话说，在接收到该Consumer的ack前，他不会讲新的Message分发给他

channel.basic_qos(prefetch_count=1)

注意：这种方法可能会导致queue满。当然，这种情况下你可能需要添加更多的Consumer，或创建更多的virtualHost来细化你的设计。

7.分发到多个Consumer

7.1Exchange

先来温习下交换机路由的几种类型：

Direct Exchange

直接匹配，通过Exchange名称+Routing Key来发送与接收消息

Fanout Exchange

广播订阅，向所有的消费者发布消息，但是只有消费者将队列绑定到该路由器才能接收消息，忽略Routing key。

Topic Exchange

主体匹配订阅，这里的主题指的是Routing key，Routing key可以采用通配符，如：*或#，RoutingKey命名采用 . 来分隔多个词，只有消费者将这队列绑定到该路由器且指定RoutingKey符合匹配规则时才能收到消息。

Headers Exchange

消息头订阅，消息发布前，为消息定义一个或多个键值对的消息头，然后消费者接收消息同时需要定义类似的键值对请求头（如x-mactch=all或者x_match=any），只有请求头与消息头匹配，才能接收消息，忽略RoutingKey

默认的exchange

如果用空字符串去声明一个exchange，那么系统就会使用“amq.direct”这个exchagne，我们创建一个queue时，默认的都会有一个和新建queue同名的routingkey绑定到这个默认exchange上去

channel.BasicPublish("", "TaskQueue", properties, bytes);

因为在第一个参数选择了默认的exchange，而我们声明的队列叫TaskQueue，所以默认的，他在新建一个也叫TaskQueue的routingkey，并绑定在默认的exchange上，导致我们可以在第二个参数routingkey中写TaskQueue，这样他就会找到定义的同名的queue，并把消息放进去。
如果有两个接收程序都是用了同一个queue和相同的routingkey去绑定direct exchange的话，分发的行为是负载均衡的，也就是说第一个程序1收到，第二个是程序2收到，以此类推
如果两个接收程序用了各自的queue，但使用相同的routingkey去绑定direct exchange 的话，分发的行为是复制的，也就是说每个程序都会收到这个消息的副本。行为相当于fanout类型的exchange。
下面详细来说：

7.2Bindings 绑定

绑定其实就是关联了exchange 和queue，或者这么说：queue对exchange的内容感兴趣，exchange要把他的Message delive到queue

7.3Direct exchange

Direct exchange的路由算法非常简单：通过bindingkey 的完全匹配，可以用下图来说明

Exchange和两个队列绑定在一起，Q1的bindingkey是orange，Q2的bindingkey是black和green。
当Producer publish key 是orange时，exchange会把它放到Q1上，如果是black或green就会到Q2上，其余的Message被丢弃。

7.4Multiple bindings

多个queue绑定同一个key也是可以的，对于下图的例子，Q1和Q2都绑定率black，对于routing key 是black 的Message，会被deliver 到Q1 和Q2，其余的Message都会被丢弃。

7.5Topic exchange

对于Message的routing key 是有限制的，不能是任意的。格式是以点号“.”分隔的字符表。比如：“stock.usd.nyse”，“nyse.vmw”，“quick.orange.rabbit”。你可以放任意的key在routing_key中，当然最长不能超过255bytes。
对于routing_key，有两个特殊字符

1. *（星号）代表任意一个单词

2. （hash）0个或多个单词

Producer发送消息时需要设置routing_key，routing_key包含三个单词和两个点号.，第一个key描述了celerity（灵巧），第二个是color（色彩），第三个是物种：
在这里我们创建了两个绑定：Q1的binding key是“ .orange. ”；Q2是“ ..rabbit” 和“lazy.#”：

1. Q1感兴趣所有orange 颜色的动物
2. Q2感兴趣所有rabbits和所有的lazy的。

例子：routing_key 为“quick.orange.rabbit”将会发送到Q1和Q2中
routing_key 为 “lazy.orange.rabbit.hujj.ddd”会被投递到Q2中，#匹配0个或多个单词

8.消息序列化

RabbitMQ使用ProtoBuf序列化消息，他可以作为RabbitMQ的Message的数据格式进行传输，由于是结构化的数据，这样就极大地方便了Consumer的数据高效处理，当然也可以使用XML，与XML相比，ProtoBuf有以下优势：

1. 简单
2. size小了3-10倍
3. 速度快了20-100倍
4. 易于编程
5. 减少了语义的歧义

Protobuf具有速度和空间的优势，使得他现在应用非常广泛