吃透RabbitMQ一

前言

早在之前就了解到了消息中间件，但是一直没有系统的学习，最近花了一段时间系统学习了当下最为主流的 RabbitMQ 消息队列，学习过程中也随时记录，刚开始学习的时候懵懵懂懂，做的笔记都比较杂乱，系统学习完后我将笔记内容不断反复修改，对章节进行设计调整，最终整合出了以下好理解、案例多、超详细的 RabbitMQ 学习笔记，希望能帮到大家～,这是我在网上找的一片文章，非常棒。

一、MQ相关的概念

1.1、MQ的基本概念

什么是MQ

MQ(message queue)，从字面意思上看就个 FIFO 先入先出的队列，只不过队列中存放的内容是 message 而已，它是一种具有接收数据、存储数据、发送数据等功能的技术服务。

在互联网架构中，MQ 是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务，用于上下游传递消息。使用了 MQ 之后，消息发送上游只需要依赖 MQ，不用依赖其他服务

为啥要用MQ

常见的MQ消息中间件有很多，例如ActiveMQ、RabbitMQ、Kafka、RocketMQ等等。那么为什么我们要使用它呢？因为它能很好的帮我解决一些复杂特殊的场景：

1️⃣ 高并发的流量削峰

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

2️⃣ 应用解耦

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

3️⃣ 异步处理

有些服务间调用是异步的，例如 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 服务还能及时的得到异步处理成功的消息。

4️⃣ 分布式事务

以订单服务为例，传统的方式为单体应用，支付、修改订单状态、创建物流订单三个步骤集成在一个服务中，因此这三个步骤可以放在一个jdbc事务中，要么全成功，要么全失败。而在微服务的环境下，会将三个步骤拆分成三个服务，例如：支付服务，订单服务，物流服务。三者各司其职，相互之间进行服务间调用，但这会带来分布式事务的问题，因为三个步骤操作的不是同一个数据库，导致无法使用jdbc事务管理以达到一致性。而 MQ 能够很好的帮我们解决分布式事务的问题，有一个比较容易理解的方案，就是二次提交。基于MQ的特点，MQ作为二次提交的中间节点，负责存储请求数据，在失败的情况可以进行多次尝试，或者基于MQ中的队列数据进行回滚操作，是一个既能保证性能，又能保证业务一致性的方案，如下图所示：

5️⃣ 数据分发

MQ 具有发布订阅机制，不仅仅是简单的上游和下游一对一的关系，还有支持一对多或者广播的模式，并且都可以根据规则选择分发的对象。这样一份上游数据，众多下游系统中，可以根据规则选择是否接收这些数据，能达到很高的拓展性。

常用的MQ

1️⃣ ActiveMQ

• 优点：单机吞吐量万级，时效性 ms 级，可用性高，基于主从架构实现高可用性，消息可靠性较低的概率丢失数据
• 缺点：官方社区现在对 ActiveMQ 5.x 维护越来越少，高吞吐量场景较少使用。

2️⃣ Kafka

大数据的杀手锏，谈到大数据领域内的消息传输，则绕不开 Kafka，这款为大数据而生的消息中间件，以其百万级 TPS 的吞吐量名声大噪，迅速成为大数据领域的宠儿，在数据采集、传输、存储的过程中发挥着举足轻重的作用。目前已经被 LinkedIn，Uber, Twitter, Netflix 等大公司所采纳。

• 优点：性能卓越，吞吐量高，单机写入 TPS 约在百万条/秒，时效性 ms 级，可用性非常高；其次 kafka 是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据导致服务不可用，消费者采用 Pull 方式获取消息，消息有序，通过控制能够保证所有消息被消费且仅被消费一次。此外 kafka 有优秀的第三方 Kafka Web 管理界面 Kafka-Manager，在日志领域比较成熟，被多家公司和多个开源项目使用；最后 kafka 在功能支持方便面它功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用。
• 缺点：Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，load 越高，发送消息响应时间变长，使用短轮询方式，实时性取决于轮询间隔时间，消费失败不支持重试；支持消息顺序，但是一台代理宕机后，就会产生消息乱序，社区更新较慢；
• 选用场景：Kafka 主要特点是基于Pull 的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。大型公司建议可以选用，如果有日志采集功能，肯定是首选 kafka 了。

3️⃣RocketMQ

RocketMQ 出自阿里巴巴的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进。被阿里巴巴广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog 分发等场景。

• 优点：单机吞吐量十万级，可用性非常高，采用分布式架构，消息可以做到 0 丢失，MQ 功能较为完善，扩展性好，支持 10 亿级别的消息堆积，不会因为堆积导致性能下降，采用 java 语言实现。
• 缺点：支持的客户端语言不多，目前是 java 及 c++，其中 c++不成熟；社区活跃度一般,没有在MQ核心中去实现 JMS 等接口，有些系统要迁移需要修改大量代码。
• 选用场景：天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。RoketMQ 在稳定性上可能更值得信赖，这些业务场景在阿里双 11 已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择 RocketMQ。

4️⃣ RabbitMQ

2007 年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

• 优点：由于 erlang 语言的高并发特性，性能较好；吞吐量到万级，MQ 功能比较完备、健壮、稳定、易用、跨平台、支持多种语言如Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持 AJAX 文档齐全；开源提供的管理界面非常棒，用起来很好用，社区活跃度高；更新频率相当高。
• 缺点：商业版需要收费，学习成本较高。
• 选用场景：结合 erlang 语言本身的并发优势，性能好时效性微秒级，社区活跃度也比较高，管理界面用起来十分方便，如果你的数据量没有那么大，中小型公司优先选择功能比较完备的 RabbitMQ。

1.2、消息队列协议

什么是协议

协议：是在TCP/IP协议基础之上构建的种约定成的规范和机制，目的是让客户端进行沟通和通讯。并且这种协议下规范必须具有持久性，高可用，高可靠的性能。

为什么不直接采用TCP/IP协议去传递消息？因为TCP/IP协议太过于简单，并不能承载消息的内容和载体，因此在此之上增加一些内容，给消息的传递分发高可用提供基础。

我们知道消息中间件负责数据的传递，存储，和分发消费三个部分，数据的存储和分发的过程中肯定要遵循某种约定成俗的规范，是采用底层的TCP/IP，UDP协议还是在这基础上自己构建等，而这些约定成俗的规范就称之为：协议。

所谓协议是指：

计算机底层操作系统和应用程序通讯时共同遵守的组约定，只有遵循共同的约定和规范，系统和底层操作系统之间才能相互交流。 和一般的网络应用程序的不同，它主要负责数据的接受和传递，所以性能比较的高。 协议对数据格式和计算机之间交换数据都必须严格遵守规范。

网络协议的三要素

1. 语法：语法是用户数据与控制信息的结构与格式，以及数据出现的顺序。
2. 语义：语义是解控制信息每个部分的意义。它规定了需要发出何种控制信息以及完成的动作与做出什么样的响应。
3. 时序：时序是对事件发生顺序的详细说明。

# 类比http请求协议
1. 语法：http规定了请求报文和响应报文的格式
2. 语义：客户端主动发起请求称之为请求。（这是一种定义，同时你发起的是post/get请求）
3. 时序：一个请求对应个响应。（定先有请求在有响应，这个是时序）

而消息中间件采用的并不是http协议，而常见的消息中间件协议有：OpenWire、AMQP、MQTT、Kafka、OpenMessage协议

面试题：为什么消息中间件不直接使用http协议呢？

因为http请求报文头和响应报文头是比较复杂的，包含了cookie、数据的加密解密、状态码、晌应码等附加的功能，但是对于个消息而言，我们并不需要这么复杂，也没有这个必要性，它其实就是负责数据传递，存储，分发就够，要追求的是高性能。尽量简洁，快速。 大部分情况下http大部分都是短链接，在实际的交互过程中，一个请求到响应很有可能会中断，中断以后就不会就行持久化，就会造成请求的丢失。这样就不利于消息中间件的业务场景，因为消息中间件可能是一个长期的获取消息的过程，出现问题和故障要对数据或消息就行持久化等，目的是为了保证消息和数据的高可靠和稳健的运行。

常用消息中间件协议

1.AMQP协议（Advanced Message Queuing Protocol—高级消息队列协议）

它由摩根大通集团联合其他公司共同设计。是一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。

特性：分布式事务支、消息的持久化支持、高性能和高可靠的消息处理优势

AMQP典型的实现者是RabbitMQ、ACTIVEMQ等，其中RabbitMQ由Erlang开发

2.MQTT协议（Message Queueing Telemetry Transport—消息队列遥测传输协议）

它是一种基于发布/订阅（publish/subscribe）模式的”轻量级”通讯协议，该协议构建于TCP/IP协议上，由IBM在1999年发布。

特点：轻量、结构简单、传输快、不支持事务、没有持久化设计

应用场景：适用于计算能力有限、低带宽、网络不稳定的场景

支持者：RabbitMQ、ACTIVEMQ（默认情况下关闭，需要打开）

3.OpenMessage协议

是近几年由阿里、雅虎和滴滴出行、 Stremalio等公司共同参与创立的分布式消息中间件、流处理等领域的应用开发标准。

特点：结构简单、解析速度快、支持事务和持久化设计

4.Kafka协议

基于TCP/IP的二进制协议。消息内部是通过长度来分割，由些基本数据类型组成。

特点：结构简单、解析速度快、无事务支持、有持久化设计

1.3、消息队列持久化

持久化简单来说就是将数据存入磁盘，而不是存在内存中随服务器重启断开而消失，使数据能够永久保存。

常见的持久化方式和对比：

	ActiveMQ	RabbitMQ	Kafka	RocketMQ
文件存储	支持	支持	支持	支持
数据库	支持	/	/	/

1.4、消息的分发策略

MQ消息队列有如下几个角色：

1. Producer：消息生产者。负责产生和发送消息到 Broker
2. Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue
3. Consumer：消息消费者。负责从 Broker 中获取消息，并进行相应处理

生产者产生消息后，MQ进行存储，消费者如何获得消息呢？

一般的获取方式无外乎外推（push）或者（pull）两种方式，典型的git就有推拉机制，我们发送的http请求就是一种典型的拉取数据库数据返回的过程。而消息队列MQ是一种推送过程，而这些推机制会适用到很多的业务场景，也有很多对应的推机制策略

场景分析一

比如我在APP上下了一个订单，我们的系统和服务很多，我们如何得知这个消息被那个系统或者那些服务或者系统进行消费，此时就需要一个消费策略，或称为消费的方法论。

场景分析二

在发送消息的过程中可能会出现异常，或者网络的抖动，故障等等因为造成消息的无法消费，比如用户在下订单，消费MQ接受，订单系统出现故障，导致用户支付失败，那么这个时候就需要消息中间件就必须支持消息重试机制策略。也就是支持：出现问题和故障的情况下，消息不丢失还可以进行重发

📄 消息分发策略的机制和对比

	ActiveMQ	RabbitMQ	Kafka	RocketMQ
发布订阅	支持	支持	支持	支持
轮询分发	支持	支持	支持	/
公平分发	/	支持	支持	/
重发	支持	支持	/	支持
消息拉取	/	支持	支持	支持

1.5、消息队列的高可用和高可靠

所谓高可用：是指产品在规定的条件和规定的时刻或时间内处于可执行规定功能状态的能力。

当业务量增加时，请求也过大，一台消息中间件服务器的会触及硬件（CPU、内存、磁盘）的极限，一台消息服务器你已经无法满足业务的需求，所以消息中间件必须支持集群部署，来达到高可用的目的。

1️⃣ Master-slave主从共享数据的部署方式

将多个消息服务器Broker连接共享一块消息存储空间，其中Master节点负责消息的写入。客户端会将消息写入到Master节点，一旦Master挂掉，slave节点继续服务，从而形成高可用。

2️⃣ Master-slave主从同步部署方式

该模式写入消息同样在Master节点上，但是主结点会同步数据到slave节点形成副本，和zookeeper或者redis主从机制很类似。这样可以达到负载均衡的效果，如果消费者有多个，就可以到不同的节点进行消费，但是消息的拷贝和同步会占用很大的贷款和网络资源。在rabbitMQ中会有使用

3️⃣ 多主集群同步部署模式

和上述方式区别不大，但是该方式任意节点都可以进行写入。

4️⃣ 多主集群转发部署模式

如果插入的数据是Broker1，元数据信息会存储数据的相关描述和记录存放的位置（队列），它会对描述信息，也就是元数据进行同步；

如果消费者在Broker2中进行消费，发现自己没有对应的消息，就会在自己的元数据信息中去查询，如果查询到了直接返回。如果没有查询到就会将该消息的信息携带在请求中转发到其他节点去询问，直到找到所需的信息为止。

场景：比如买火车票或者黄牛买演唱会门票，比如第一个黄牛没有顾客说要买的演唱会门票，但是他会去联系其他的黄牛询问，如果有就返回

5️⃣ Master-slave与Breoker-cluster组合的方案

实现多主多从的热备机制来完成消息的高可用以及数据的热备机制，在生产规模达到定的阶段的时候，这种使用的频率比较高。

这些集群模式最终目的都是为保证：消息服务器不会挂掉，出现了故障依然可以抱着消息服务继续使用。反正终归三句话：

要么消息共享 要么消息同步 要么元数据兴享

二、RabbitMQ安装启动

1、简介

官网：https://www.rabbitmq.com/

RabbitMQ是一个开源的遵循AMQP协议实现的基于Erlang语言编写，支持多种客户端（语言），用于在分布式系统中存储消息，转发消息，具有高可用高可扩性，易用性等特征。

2、下载安装启动RabbitMQ

我用的是windows，本次以windows为例

2.1、下载RabbitMQ

下载地址：https://www.rabbitmq.com/download.html

下载Erlang

RabbitMQ是采用 Erlang语言开发的，所以系统环境必须提供 Erlang环境，需要是安装 Erlang

Erlang和RabbitMQ版本对照：Erlang Version Requirements | RabbitMQ

这里安装最新版本rabbitmq-server-4.1.0.exe，对应的Erlang版本推荐27.x，我们下载OTP 27.3.3

下载地址：OTP Versions Tree

先安装erlang,再安装rabbitmq

编辑环境变量

验证是否安装成功 运行以下命令:

打开浏览器。访问 http://127.0.0.1:15672

出现管理页面：

账号：guest

密码：guest

三、RabbitMQ快速入门

3.1、RabbitMQ的概念

RabbitMQ 是一个消息中间件：它接受并转发消息。你可以把它当做一个快递站点，当你要发送一个包裹时，你把你的包裹放到快递站，快递员最终会把你的快递送到收件人那里，按照这种逻辑 RabbitMQ 是一个快递站，一个快递员帮你传递快件。RabbitMQ 与快递站的主要区别在于：它不处理快件而是接收，存储和转发消息数据。

3.2、AMQP协议

RabbitMQ是一种遵循AMQP协议的分布式消息中间件。AMQP 全称 “Advanced Message Queuing Protocol”，高级消息队列协议。它是应用层协议的一个开发标准，为面向消息的中间件设计。

3.3、RabbitMQ架构组成

• Broker：就是 RabbitMQ 服务，用于接收和分发消息，接受客户端的连接，实现 AMQP 实体服务。
• Virtual host：出于多租户和安全因素设计的，把 AMQP 的基本组件划分到一个虚拟的分组中，类似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时，可以划分出多个 vhost，每个用户在自己的 vhost 创建 exchange 或 queue 等。
• Connection：连接，生产者/消费者与 Broker 之间的 TCP 网络连接。
• Channel：网络信道，如果每一次访问 RabbitMQ 都建立一个 Connection，在消息量大的时候建立连接的开销将是巨大的，效率也较低。Channel 是在 connection 内部建立的逻辑连接，如果应用程序支持多线程，通常每个 thread 创建单独的 channel 进行通讯，AMQP method 包含了 channel id 帮助客户端和 message broker 识别 channel，所以 channel 之间是完全隔离的。Channel 作为轻量级的Connection 极大减少了操作系统建立 TCP connection 的开销。
• Message：消息，服务与应用程序之间传送的数据，由Properties和body组成，Properties可是对消息进行修饰，比如消息的优先级，延迟等高级特性，Body则就是消息体的内容。
• Virtual Host：虚拟节点，用于进行逻辑隔离，最上层的消息路由，一个虚拟主机理由可以有若干个Exhange和Queue，同一个虚
• 拟主机里面不能有相同名字的Exchange
• Exchange：交换机，是 message 到达 broker 的第一站，用于根据分发规则、匹配查询表中的 routing key，分发消息到 queue 中
• 去，不具备消息存储的功能。常用的类型有：direct、topic、fanout。
• Bindings：exchange 和 queue 之间的虚拟连接，binding 中可以包含 routing key，Binding 信息被保存到 exchange 中的查询表
• 中，用于 message 的分发依据。
• Routing key：是一个路由规则，虚拟机可以用它来确定如何路由一个特定消息
• Queue：消息队列，保存消息并将它们转发给消费者进行消费。

3.4、四大核心概念

• 生产者：产生数据发送消息的程序是生产者。
• 交换机：交换机是 RabbitMQ 非常重要的一个部件，一方面它接收来自生产者的消息，另一方面它将消息推送到队列中。交换机必须确切知道如何处理它接收到的消息，是将这些消息推送到特定队列还是推送到多个队列，亦或者是把消息丢弃，这个是由交换机类型决定的。
• 队列：队列是 RabbitMQ 内部使用的一种数据结构，尽管消息流经 RabbitMQ 和应用程序，但它们只能存储在队列中。队列仅受主机的内存和磁盘限制的约束，本质上是一个大的消息缓冲区。许多生产者可以将消息发送到一个队列，许多消费者可以尝试从一个队列接收数据。
• 消费者：消费与接收具有相似的含义。消费者大多时候是一个等待接收消息的程序。请注意生产者，消费者和消息中间件很多时候并不在同一机器上。同一个应用程序既可以是生产者又是可以是消费者。

3.5、RabbitMQ角色分类

• none：不能访问 management plugin
• management：查看自己相关节点信息
  • 列出自己可以通过AMQP登入的虚拟机
  • 查看自己的虚拟机节点virtual hosts的queues，exchanges和bindings信息
  • 查看和关闭自己的channels和connections
  • 查看有关自己的虚拟机节点virtual hosts的统计信息。包括其他用户在这个节点virtual hosts中的活动信息
• Policymaker
  • 包含management所有权跟
  • 查看和创建和删除自己的virtual hosts所属的policies和parameters信息
• Monitoring
  • 包含management所有权限
  • 罗列出所有的virtual hosts，包括不能登录的virtual hosts
  • 查看其他用户的connections和channels信息
  • 查看节点级别的数据如clustering和memory使用情况
  • 查看所有的virtual hosts的全局统计信息。
• Administrator

3.6、RabbitMQ消息模式

RabbitMQ提供6种模式，分别是 Hello World、Work Queues、Publish/Subscribe、Routing、Topics、RPC。本文详细讲述了前5种，并给出代码实现和思路。其中 Publish/Subscribe、Routing、Topics 三种模式可以统一归为 Exchange 模式，只是创建时交换机的类型不一样，分别是 fanout、direct、topic 三种交换机类型。

注意：简单模式和工作模式虽然途中没有画出交换机，但是都会有一个默认的交换机，类型为direct

简单模式：一个生产者，一个消费者，一个队列，采用默认交换机。可以理解为生产者P发送消息到队列Q，一个消费者C接收。

默认交换机，设置路由hello，发送一个消息hello world

创建一个hello队列，你会发现里面有一条消息

工作模式：一个生产者，多个消费者，一个队列，采用默认交换机。可以理解为生产者P发送消息到队列Q，可以由多个消费者C1、C2进行接收。

发布/订阅模式（fanout）

功能：一个生产者、一个 fanout 类型的交换机、多个队列、多个消费者。一个生产者发送的消息会被多个消费者获取。其中 fanout 类型就是发布订阅模式，只有订阅该生产者的消费者会收到消息。

接下来通过web界面的方式模拟发布订阅模式，首先新建一个fanout类型的交换机

然后声明两个队列

然后将队列与交换机进行绑定

路由模式（direct）

功能：一个生产者，一个 direct 类型的交换机，多个队列，交换机与队列之间通过 routing-key 进行关联绑定，多个消费者。生产者发送消息到交换机并且要指定routing-key，然后消息根据这交换机与队列之间的 routing-key 绑定规则进行路由被指定消费者消费。

接下来通过web界面的方式模拟发布订阅模式，首先新建一个direct类型的交换机

两个队列

绑定交换机

然后我们往交换机中发送一条消息，指定一个 routing-key

可以看到只有对应 routing-key 的 queue2 收到了消息

主题模式（topic)

说明：一个生产者，一个 topic 类型的交换机，多个队列，交换机与队列之间通过 routing-key 进行关联绑定，多个消费者。生产者发送消息到交换机并且要指定 routing-key，然后消息根据这交换机与队列之间的 routing-key 绑定规则进行路由被指定消费者消费。与路由模式不同是 routing-key 有指定的队则，可以更加的通用，满足更过的场景。routing-key 的规则如下：

• #：匹配一个或者多个词，例如lazy.# 可以匹配 lazy.xxx 或者 lazy.xxx.xxx
• *：只能匹配一个词，例如lazy.* 只能匹配 lazy.xxx

接下来通过web界面的方式模拟发布订阅模式，首先新建一个topic类型的交换机

然后绑定队列，设置路由key

然后我们向交换机中投递一条消息，指定一个路由key

可以看到只有满足路由key条件的queue1收到了消息

queue1查看消息

参数模式

作用：可以携带参数，根据参数进行过滤

下来通过web界面的方式模拟发布订阅模式，首先新建一个headers类型的交换机

然后我们向交换机中投递一条消息，指定参数