概述

之前已经对rabbitMQ的一些基本概念做了介绍和不同MQ之间的比较，今天主要对rabbitMQ的一些方面做扩展。

---

01

消息队列

Broker：简单来说就是消息队列服务器实体。

Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。

Queue：消息队列载体，每个消息都会被投入到一个或多个队列。

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

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

vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。每个虚拟主机是隔离的,互不影响.

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

consumer：消息消费者，就是接受消息的程序。

channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。

---

02

消息队列的工作过程

(1)客户端连接到消息队列服务器，打开一个channel。

(2)客户端声明一个exchange，并设置相关属性。

(3)客户端声明一个queue，并设置相关属性。

(4)客户端使用routing key，在exchange和queue之间建立好绑定关系。

(5)客户端投递消息到exchange。

---

03

消费模式 :推(push)模式和拉(pull)模式。

Pull(推模式)是指由Broker(中介,这里是队列),主动推送消息至消费端，实时性较好，不过需要一定的流制机制来确保服务端推送过来的消息不会压垮消费端。

而拉模式是指消费端主动向Broker端请求拉取(一般是定时或者定量)消息，实时性较推模式差，但是可以根据自身的处理能力而控制拉取的消息量。

---

04

消息持久化

rabbit如何进行消息持久化操作呢？exchange是实现发布订阅的基础，其类型包含fanout、headers、direct、、topic。我们本次仅讨论类型为topic。

发布订阅模式执行消息发送的流程：

RabbitMQ要实现发布订阅持久化，按照消息的传输流程，可以分成三类：

Exchange 持久化：如果不设定Exchange持久化，那么在RabbitMQ由于某些异常等原因重启之后，Exchange会丢失。Exchange丢失， 会影响发送端发送消息到RabbitMQ。

Queue持久化：发送端将消息发送至Exchange，Exchange将消息转发至关联的Queue。如果Queue不设置持久化，那么在RabbitMQ重启之后，Queue信息会丢失。导致消息发送至Exchange，但Exchange不知道需要将该消息发送至哪些具体的队列。

Message持久化：发送端将消息发送至Exchange，Exchange将消息转发至关联的Queue，消息存储于具体的Queue中。如果RabbitMQ重启之后，由于Message未设置持久化，那么消息会在重启之后丢失。

为了保证发布订阅的持久化，必须设置Exchange、Queue、Message的持久化，才可以保证消息最终不会丢失。虽然持久化会造成性能损耗，但为了生产环境的数据一致性，这是我们必须做出的选择。但我们可以通过设置消息过期时间、降低发送消息大小等其他方式来尽可能的降低MQ性能的降低。

消息队列持久化包括3个部分：

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

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

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

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

---

05

消息发送步骤

exchange接收到消息后，就根据消息的key和已经设置的binding，进行消息路由，将消息投递到一个或多个队列里。

exchange也有几个类型，完全根据key进行投递的叫做Direct交换机，例如，绑定时设置了routing key为”abc”，那么客户端提交的消息，只有设置了key为”abc”的才会投递到队列。对key进行模式匹配后进行投递的叫做Topic交换 机，符号”#”匹配一个或多个词，符号”*”匹配正好一个词。

例如”abc.#”匹配”abc.def.ghi”，”abc.*”只匹配”abc.def”。还有一种不需要key的，叫做Fanout交换机，它采取广播模式，一个消息进来时，投递到与该交换机绑定的所有队列。

---

RabbitMQ的Connection是昂贵的，但Channel是廉价的，在多线程环境下，尽量创建少数Connection，然后在每个Connection中创建多个Channel，利用Channel实现Connection复用，从而提高系统性能。很像Java NIO里的Selector到Channel的多路复用。

生产端发送消息时，同一个Channel的basicPublish方法并不是线程安全的，因此更加体现出多Channel的重要性。如果生产端需要使用多线程发送消息，那么必须创建多个Channel，每一个线程单独使用一个Channel，但是这些Channel可以来自同一个Connection。假如线程数量过多，那么也不可以无限制的创建Channel，需要使用Channel Pool(连接池)的思路去控制并发。

后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~