消息队列之 RabbitMQ（一）

消息队列

消息队列 (Messaeg Queue) 是一种使用队列 (Queue) 作为底层存储数据结构，可用于解决不同进程与应用之间通讯的分布式消息容器，也称为消息中间件。

什么是消息队列

• 消息队列(message queue，MQ)，从字面意思上看，本质是个队列，FIFO 先入先出，只不过队列中存放的内容是message 而已，还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ 是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了 MQ 之后，消息发送上游只需要依赖 MQ，不用依赖其他服务。

为什么要用消息队列

消息通讯

• 消息队列最主要功能收发消息，其内部有高效的通讯机制，因此非常适合用于消息通讯。我们可以基于消息队列开发点对点聊天系统，也可以开发广播系统，用于将消息广播给大量接收者。

流量消峰

• 举个例子，如果订单系统最多能处理一万次订单，这个处理能力应付正常时段的下单时绰绰有余，正常时段我们下单一秒后就能返回结果。但是在高峰期，如果有两万次下单操作系统是处理不了的，只能限制订单超过一万后不允许用户下单。使用消息队列做缓冲，我们可以取消这个限制，把一秒内下的订单分散成一段时间来处理，这时有些用户可能在下单十几秒后才能收到下单成功的操作，但是比不能下单的体验要好。

应用解耦

• 以电商应用为例，应用中有订单系统、库存系统、物流系统、支付系统。用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障，都会造成下单操作异常。当转变成基于消息队列的方式后，系统间调用的问题会减少很多，比如物流系统因为发生故障，需要几分钟来修复。在这几分钟的时间里，物流系统要处理的内存被缓存在消息队列中，用户的下单操作可以正常完成。当物流系统恢复后，继续处理订单信息即可，中单用户感受不到物流系统的故障，提升系统的可用性。
  

异步处理

• 有些服务间调用是异步的，例如 A 调用 B，B 需要花费很长时间执行，但是 A 需要知道 B 什么时候可以执行完，以前一般有两种方式，A 过一段时间去调用 B 的查询 api 查询。或者 A 提供一个 callback api， B 执行完之后调用 api 通知 A 服务。这两种方式都不是很优雅，使用消息总线，可以很方便解决这个问题，A 调用 B 服务后，只需要监听 B 处理完成的消息，当 B 处理完成后，会发送一条消息给 MQ，MQ 会将此消息转发给 A 服务。这样 A 服务既不用循环调用 B 的查询 api，也不用提供 callback api。同样B 服务也不用做这些操作。A 服务还能及时的得到异步处理成功的消息。
  

目前使用得比较多的消息队列有 ActiveMQ，RabbitMQ，Kafka，RocketMQ 等。本文主要讲述的是 RabbitMQ，RabbitMQ 是用 Erlang 语言开发的一个实现了 AMQP 协议的消息队列服务器，相比其他同类型的消息队列，最大的特点在保证可观的单机吞吐量的同时，延时方面非常出色。

RabbitMQ

RabbitMQ 的概念

• RabbitMQ是一个消息代理。它的工作就是接收和转发消息。你可以把它想像成一个邮局：你把信件放入邮箱，邮递员就会把信件投递到你的收件人处。在这个比喻中，RabbitMQ就扮演着邮箱、邮局以及邮递员的角色。RabbitMQ和邮局的主要区别在于，它处理纸张，而是接收、存储和发送消息（message）这种二进制数据。

RabbitMQ相关名词介绍

RabbitMQ 内部结构

Message

• 消息，由Header和body组成，Header是由生产者添加的各种属性的集合，包括Message是否被持久化、优先级是多少、由哪个Message Queue接收等；body是真正需要发送的数据内容；

Publisher

• 消息的生产者，也是一个向交换器发布消息的客户端应用程序。

Exchange

• 消息交换机，作用是接收来自生产者的消息，并根据路由键转发消息到所绑定的队列。生产者发送上的消息，就是先通过 Exchnage 按照绑定 (binding) 规则转发到队列的。
• 交换机类型 (Exchange Type) 有四种：fanout、direct、topic，headers，其中 headers 并不常用。

Binding

• 绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表，Binding 操作一般用于 RabbitMQ 的路由工作模式和主题工作模式。

Queue

• 消息队列，内部用于存储消息的对象，是真正用来存储消息的结构。它是消息的容器，也是消息的终点。在生产端，生产者的消息最终发送到指定队列，而消费者也是通过订阅某个队列，达到获取消息的目的。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。

Connection

• 网络连接，是 RabbitMQ 内部对象之一，用于管理每个到 RabbitMQ 的 TCP 网络连接。

Channel

• 信道，多路复用连接中的一条独立的双向数据流通道，也是我们与 RabbitMQ 打交道的最重要的一个接口，我们大部分的业务操作是在 Channel 这个接口中完成的，包括定义 Queue、定义 Exchange、绑定 Queue 与 Exchange、发布消息等。
• 信道是建立在真实的TCP连接内地虚拟连接，AMQP 命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销，所以引入了信道的概念，以复用一条 TCP 连接。

Consumer

• 消息的消费者，表示一个从消息队列中取得消息的客户端应用程序。

Virtual Host

• 虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础，必须在连接时指定，RabbitMQ 默认的 vhost 是 / 。
• 一个 VirtualHost 下面有一组不同 Exchnage 与 Queue，不同的 Virtual host 的 Exchnage 与 Queue 之间互相不影响。应用隔离与权限划分，Virtual host 是 RabbitMQ 中最小颗粒的权限单位划分。
• 如果要类比的话，我们可以把 Virtual host 比作 MySQL 中的数据库，通常我们在使用 MySQL 时，会为不同的项目指定不同的数据库，同样的，在使用 RabbitMQ 时，我们可以为不同的应用程序指定不同的 Virtual host。

Broker

• 表示消息队列服务器实体。

RabbitMQ 消息应答

概念

• 消费者完成一个任务可能需要一段时间，如果其中一个消费者处理一个长的任务并仅只完成了部分突然它挂掉了，会发生什么情况。RabbitMQ 一旦向消费者传递了一条消息，便立即将该消息标记为删除。在这种情况下，突然有个消费者挂掉了，我们将丢失正在处理的消息。以及后续发送给该消费这的消息，因为它无法接收到。
• 为了保证消息在发送过程中不丢失，rabbitmq 引入消息应答机制，消息应答就是:消费者在接收到消息并且处理该消息之后，告诉 rabbitmq 它已经处理了，rabbitmq 可以把该消息删除了。

自动应答

• 消息发送后立即被认为已经传送成功，这种模式需要在高吞吐量和数据传输安全性方面做权衡，因为这种模式如果消息在接收到之前，消费者那边出现连接或者 channel 关闭，那么消息就丢失 了，当然另一方面这种模式消费者那边可以传递过载的消息，没有对传递的消息数量进行限制，当然这样有可能使得消费者这边由于接收太多还来不及处理的消息，导致这些消息的积压，最终使得内存耗尽，最终这些消费者线程被操作系统杀死，所以这种模式仅适用在消费者可以高效并以某种速率能够处理这些消息的情况下使用。

手动应答

• 消费者从队列中获取消息后，服务器会将该消息标记为不可用状态，等待消费者的反馈，如果消费者一直没有反馈，那么该消息将一直处于不可用状态。

默认消息采用的是自动应答，所以我们要想实现消息消费过程中不丢失，需要把自动应答改为手动应答。

消息应答的方法

• A.Channel.basicAck(用于肯定确认)
  • RabbitMQ 已知道该消息并且成功的处理消息，可以将其丢弃了
• B.Channel.basicNack(用于否定确认)
• C.Channel.basicReject(用于否定确认)
  • 与 Channel.basicNack 相比少一个参数。 不处理该消息了直接拒绝，可以将其丢弃了

channel.basicAck()

void basicNack(long deliveryTag, boolean multiple, boolean requeue) throws IOException;
  参数：
	deliveryTag：该消息的index
	multiple：是否批量处理.true:将一次性ack所有小于deliveryTag的消息
	requeue：被拒绝的是否重新入队列

发布确认

发布确认原理

• 生产者将信道设置成 confirm 模式，一旦信道进入 confirm 模式，所有在该信道上面发布的消息都将会被指派一个唯一的 ID(从 1 开始)，一旦消息被投递到所有匹配的队列之后，broker 就会发送一个确认给生产者(包含消息的唯一 ID)，这就使得生产者知道消息已经正确到达目的队列了，如果消息和队列是可持久化的，那么确认消息会在将消息写入磁盘之后发出，broker 回传给生产者的确认消息中 delivery-tag 域包含了确认消息的序列号，此外 broker 也可以设置basic.ack 的multiple 域，表示到这个序列号之前的所有消息都已经得到了处理。
• confirm 模式最大的好处在于他是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用便可以通过回调方法来处理该确认消息，如果 RabbitMQ 因为自身内部错误导致消息丢失，就会发送一条 nack 消息，生产者应用程序同样可以在回调方法中处理该 nack 消息。

3 种发布确认

单独发布消息

• 同步等待确认，简单，但吞吐量非常有限。

批量发布消息

• 批量同步等待确认，简单，合理的吞吐量，一旦出现问题但很难推断出是那条消息出现了问题。

异步处理

• 最佳性能和资源使用，在出现错误的情况下可以很好地控制，但是实现起来稍微难些

交换机

Exchanges 概念

• RabbitMQ 消息传递模型的核心思想是: 生产者生产的消息从不会直接发送到队列。实际上，通常生产者甚至都不知道这些消息传递传递到了哪些队列中。
• 相反，生产者只能将消息发送到交换机(exchange)，交换机工作的内容非常简单，一方面它接收来自生产者的消息，另一方面将它们推入队列。交换机必须确切知道如何处理收到的消息。是应该把这些消息放到特定队列还是说把他们到许多队列中还是说应该丢弃它们。这就的由交换机的类型来决定。
  

Exchanges 的类型

• 总共有以下类型：直接(direct), 主题(topic) ,标题(headers) , 扇出(fanout)。
  • fanout：这种类型不处理路由键 (RoutingKey)，很像子网广播，每台子网内的主机都获得了一份复制的消息，发布 / 订阅模式就是指使用 fanout 交换机类型，fanout 类型交换机转发消息是最快的。
  • direct：模式处理路由键，需要路由键完全匹配的队列才能收到消息，路由模式使用的是 direct 类型的交换机。
  • topic：将路由键和某模式进行匹配。主题模式使用的是 topic 类型的交换机。

你知道的越多，你不知道的越多。