RabbitMQ 实战指南-学习笔记1

什么是消息中间件

消息 (Message) 是指在应用间传送的数据。消息可以非常简单，比如只包含文本字符串、 JSON 等，也可以很复杂，比如内嵌对象。

消息队列中间件 (Message Queue Middleware ，简称为 MQ) 是指利用高效可靠的消息传递 机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传 递和消息排队模型，它可以在分布式环境下扩展进程间的通信。

消息队列中间件，也可以称为消息队列或者消息中间件。它一般有两种传递模式:点对点 (P2P, Point-to-Point) 模式和发布/订阅 (Pub/Sub) 模式。点对点模式是基于队列的，消息生产 者发送消息到队列，消息消费者从队列中接收消息，队列的存在使得消息的异步传输成为可能。 发布订阅模式定义了如何向 一个内容节点发布和订阅消息，这个内容节点称为主题 (topic) ，主 题可以认为是消息传递的中介，消息发布者将消息发布到某个主题，而消息订阅者则从主题中 订阅消息。主题使得消息的订阅者与消息的发布者互相保持独立，不需要进行接触即可保证消 息的传递，发布/订阅模式在消息的一对多广播时采用 。

消息中间件的作用

消息中间件凭借其独到的特性，在不同的应用场景下可以展现不同的作用 。总的来说，消息中间件的作用可以概括如下。

解辑:在项目启动之初来预测将来会碰到什么需求是极其困难的。消息中间件在处理过程 中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，这允许你独 立地扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束即可 。

冗余〈存储) : 有些情况下，处理数据的过程会失败。消息中间件可以把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。在把一个消息从消息中间件中删 除之前，需要你的处理系统明确地指出该消息己经被处理完成，从而确保你的数据被安全地保 存直到你使用完毕。

扩展性:因为消息中间件解捐了应用的处理过程，所以提高消息入队和处理的效率是很容易的，只要另外增加处理过程即可，不需要改变代码，也不需要调节参数。

削峰: 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常 见。如果以能处理这类峰值为标准而投入资源，无疑是巨大的浪费 。 使用消息中间件能够使关 键组件支撑突发访问压力，不会因为突发的超负荷请求而完全崩惯 。

可恢复性: 当系统一部分组件失效时，不会影响到整个系统 。 消息中间件降低了进程间的 稿合度，所以即使一个处理消息的进程挂掉，加入消息中间件中的消息仍然可以在系统恢复后 进行处理 。

顺序保证: 度上的顺序性。

在大多数使用场景下，数据处理的顺序很重要，大部分消息中间件支持一定程

缓冲: 在任何重要的系统中，都会存在需要不同处理时间的元素。消息中间件通过一个缓 冲层来帮助任务最高效率地执行，写入消息中间件的处理会尽可能快速 。 该缓冲层有助于控制 和优化数据流经过系统的速度。

异步通信: 在很多时候应用不想也不需要立即处理消息 。 消息中间件提供了异步处理机制， 允许应用把一些消息放入消息中间件中，但并不立即处理它，在之后需要的时候再慢慢处理 。

RabbitMQ 整体上是一个生产者与消费者模型

生产者和消费者

Producer: 生产者就是投递消息的 一方。

生产者创建消息，然后发布到 RabbitMQ 中.
消息一般可以包含 2 个部分:消息体和标签 (Label) 。

• 消息体:也可以称之为 payload ，在实际应用中，消 息体一般是一个带有业务逻辑结构 的数据，比如一个 JSON字符串。当然可以进一步对这个消息体进行序列化操作
• 消息的标签:用来表述这条消息 ， 比如 一个交换器的名称和 一个路由键

生产者把消息交由 RabbitMQ 之后会根据标签把消息发送给感兴趣 的消费者 C Consumer ) 。

Consumer: 消费者就是接收消息的一方。

消费者连接到 RabbitMQ 服务器，并订阅到队列上 。 当消费者消费一条消息时 ， 只是消费 消息的消息体 C payload ) 。 在消息路由的过程中 ， 消息的标签会丢弃 ， 存入到队列中的消息只 有消息体，消费者也只会消费到消息体 ， 也就不知道消息的生产者是谁，当然消费者也不 需要 知道 。

Broker 消息中间件的服务节点

对于 RabbitMQ 来说，一个 RabbitMQ Broker 可 以 简单地看作 一个 RabbitMQ 服务节点 ，或者 RabbitMQ 服务实例 。 大多 数情况下 也可 以 将一个 RabbitMQ Broker 看作一 台 RabbitMQ 服务器 。

生产者将消息存入 RabbitMQ Broker，以及消费者从 Broker 中消费数据的整个流程

队列

Queue: 队列，是 RabbitMQ 的内部对象，用于存储消息

RabbitMQ 的生产者生产消息井最终技递到队列中，消费者可以从队列中获取消息并消费 。

交换器、路由键、绑定

Exchange 交换器

生产者将消息发送到 Exchange (交换器，通常也 可以用大写的 “X” 来表示)，由交换器将消息路由到一个或者多个队列中。如果路由不到，或 许会返回给生产者，或许直接丢弃(我记得看过一些资料之前是路由不到直接丢弃, 现在是将其存放在黑洞也就是一个暂存区储存起来)。

RabbitMQ 中的 交换器有四种类型，不同的类型有着不 同的路由策略

RoutingKey 路由键

• 生产者将消息发给交换器的时候， 一般会指定一个 RoutingKey ，用 来指定这个消息的路由规则，而这个 RoutingKey需要与交换器类型和绑定键 (BindingKey) 联 合使用才能最终生效。
• 在交换器类型和绑定键 (BindingKey)固定的情况下，生产者可以在发送消息给交换器时， 通过指定 RoutingKey 来决定消息流向哪里。

Binding:绑定

RabbitMQ 中通过绑定将交换器与队列关联起来，在绑定的时候一般会指定一个绑定键 ( BindingKey ) ，这样 RabbitMQ 就知道如何正确地将消息路由 到 队列了

生产者将消息发送给交换器时，需要一个 RoutingKey ，当 BindingKey 和 RoutingKey 相匹配时，消息会被路由 到对应 的 队列 中
注意:

在绑定多个队列到同一个交换器的时候 ，这些绑定允许使用 相 同的 BindingKey 0 BindingKey 并不是在所有的情况下都生效，它依赖于交换器类型 ， 比 如 fanout 类型 的交换器就会无视 BindingKey ， 而是将消息路由到所有绑定到该交换器的队列中

比喻:

交换器相 当于投递包裹 的邮箱 ， RoutingKey 相 当于填写在包裹上的 地址， BindingKey 相 当于包裹 的 目 的地， 当填写在包裹上 的地址和实际想要投递的地址相匹配 时， 那么这个包裹就会被正确投递到 目 的地， 最后这个目 的地的"主人"一一队列可以保留这 个包裹。如果填写 的地址出 错 ，邮递员不能正确投递到目的地， 包裹可能会回退给寄件人 ，也 有可能被丢弃。

交换器类型

RabbitMQ 常用的交换器类型有 fanout、 direct、 topic、 headers 这四种
AMQP 协议里还提 到另外两种类型: System 和自定义

fanout广播

它会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。

direct

direct 类型的交换器路由规则也很简单，它会把消息路由到那些BindingKey 和 RoutingKey 完全匹配的队列中。

• 交换器的类型为 direct，如果我们发送一条消息，并在发送消息的时候设置 路由键为" warning" ，则消息会路由到 Queuel和 Queue2
• 如果在发送消息的时候设置路由键为" info" 或者 “debug” ，消息 只会路由到 Queue2 。果以其他的路由键发送消息，则消息不会路由到这两个队列中。
  

topic 主题

topic 类型的交换器在匹配规则上进行了 扩展，它与 direct 类型的交换器相似，也是将消息路由到 BindingKey 和 RoutingKey 相匹配的队 列中，但这里的匹配规则有些不同，它约定:

• RoutingKey 为一个点号".“分隔的字符串(被点号”."分隔开的每一段独立的字符串称为一个单词 )，如 “com.rabbitmq.client”、“java.util.concurrent”、 “com.hidden.client”
• BindingKey 和 RoutingKey 一样也是点号"."分隔的字符串;
• BindingKey 中可以存在两种特殊字符串"*“和”#"，用于做模糊匹配，其中"*“用于匹配一个单词，”#"用于匹配多规格单词(可以是零个)。

路由键为" com.rabbitmq.client" 的消息会同时路由到 Queue1和 Queue2; 路由键为" com.hidden.client" 的消息只会路由到 Queue2 中:
路由键为" com.hidden.demo" 的消息只会路由到 Queue2 中:
路由键为 “java.rabbitmq.demo” 的消息只会路由到 Queue1中:
路由键为" java.util.concurrent" 的消息将会被丢弃或者返回给生产者(需要设置 mandatory 参数) ，因为它没有匹配任何路由键。

headers

headers 类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中 的 headers 属性进行匹配。在绑定队列和交换器时制定一组键值对 ， 当发送消息到交换器时， RabbitMQ 会获取到该消息的 headers (也是一个键值对的形式) ，对比其中的键值对是否完全 匹配队列和交换器绑定时指定的键值对，如果完全匹配则消息会路由到该队列，否则不会路由 到该队列 。 headers 类型的交换器性能会很差，而且也不实用，基本上不会看到它的存在。