最全面透彻的RabbitMQ指南

概念

RabbitMQ是实现了高级消息队列协议&＃xff08;AMQP&＃xff09;的开源消息代理软件&＃xff08;亦称面向消息的中间件&＃xff09;。RabbitMQ服务器是用Erlang语言编写的&＃xff0c;而集群和故障转移是构建在开放电信平台框架上的。所有主要的编程语言均有与代理接口通讯的客户端库。

RabbitMQ是一套开源&＃xff08;MPL&＃xff09;的消息队列服务软件&＃xff0c;是由 LShift 提供的一个 Advanced Message Queuing Protocol (AMQP) 的开源实现&＃xff0c;由以高性能、健壮以及可伸缩性出名的 Erlang 写成。

AMQP

AMQP 其实和Http一样 都是一种协议&＃xff0c; 只不过 Http是针对网络传输的&＃xff0c; 而AMQP是基于消息队列的

AMQP 协议中的基本概念

**Broker: **

接收和分发消息的应用&＃xff0c;我们在介绍消息中间件的时候所说的消息系统就是Message Broker。

**Virtual host: **

出于多租户和安全因素设计的&＃xff0c;把AMQP的基本组件划分到一个虚拟的分组中&＃xff0c;类似于网络中的namespace概念。当多个不同的用户使用同一个RabbitMQ server提供的服务时&＃xff0c;可以划分出多个vhost&＃xff0c;每个用户在自己的vhost创建exchange&＃xff0f;queue等。

「Connection:」

publisher&＃xff0f;consumer和broker之间的TCP连接。断开连接的操作只会在client端进行&＃xff0c;Broker不会断开连接&＃xff0c;除非出现网络故障或broker服务出现问题。

**Channel: **

如果每一次访问RabbitMQ都建立一个Connection&＃xff0c;在消息量大的时候建立TCP Connection的开销将是巨大的&＃xff0c;效率也较低。Channel是在connection内部建立的逻辑连接&＃xff0c;如果应用程序支持多线程&＃xff0c;通常每个thread创建单独的channel进行通讯&＃xff0c;AMQP method包含了channel id帮助客户端和message broker识别channel&＃xff0c;所以channel之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。

「Exchange:」

message到达broker的第一站&＃xff0c;根据分发规则&＃xff0c;匹配查询表中的routing key&＃xff0c;分发消息到queue中去。常用的类型有&＃xff1a;direct (point-to-point), topic (publish-subscribe) and fanout (multicast)。

**Queue: **

消息最终被送到这里等待consumer取走。一个message可以被同时拷贝到多个queue中。

「Binding:」

exchange和queue之间的虚拟连接&＃xff0c;binding中可以包含routing key。Binding信息被保存到exchange中的查询表中&＃xff0c;用于message的分发依据。

Exchange的类型

「direct :」

这种类型的交换机的路由规则是根据一个routingKey的标识&＃xff0c;交换机通过一个routingKey与队列绑定 &＃xff0c;在生产者生产消息的时候 指定一个routingKey 当绑定的队列的routingKey 与生产者发送的一样 那么交换机会吧这个消息发送给对应的队列。

「fanout:」

这种类型的交换机路由规则很简单&＃xff0c;只要与他绑定了的队列&＃xff0c; 他就会吧消息发送给对应队列&＃xff08;与routingKey没关系&＃xff09;

「topic:」

(因为*在这个笔记软件里面是关键字&＃xff0c;所以下面就用星替换掉了)这种类型的交换机路由规则也是和routingKey有关 只不过 topic他可以根据:星,#&＃xff08; 星号代表过滤一单词&＃xff0c;#代表过滤后面所有单词&＃xff0c; 用.隔开&＃xff09;来识别routingKey 我打个比方 假设 我绑定的routingKey 有队列A和B A的routingKey是&＃xff1a;星.user B的routingKey是: #.user

那么我生产一条消息routingKey 为&＃xff1a;error.user 那么此时 2个队列都能接受到&＃xff0c; 如果改为 topic.error.user 那么这时候 只有B能接受到了

「headers:」

这个类型的交换机很少用到&＃xff0c;他的路由规则 与routingKey无关 而是通过判断header参数来识别的&＃xff0c; 基本上没有应用场景&＃xff0c;因为上面的三种类型已经能应付了。

执行过程

1.客户端连接到消息队列服务器&＃xff0c;打开一个Channel。

2.客户端声明一个Exchange&＃xff0c;并设置相关属性。

3.客户端声明一个Queue&＃xff0c;并设置相关属性。

4.客户端使用Routing key&＃xff0c;在Exchange和Queue之间建立好绑定关系。

5.客户端投递消息到Exchange。

Exchange接收到消息后&＃xff0c;就根据消息的key和已经设置的Binding&＃xff0c;进行消息路由&＃xff0c;将消息投递到一个或多个队列里。有三种类型的Exchanges&＃xff1a;direct&＃xff0c;fanout&＃xff0c;topic&＃xff0c;每个实现了不同的路由算法&＃xff1a;

消息的ack机制

默认情况下&＃xff0c;如果Message 已经被某个Consumer正确的接收到了&＃xff0c;那么该Message就会被从queue中移除。当然也可以让同一个Message发送到很多的Consumer。

如果一个queue没被任何的Consumer Subscribe&＃xff08;订阅&＃xff09;&＃xff0c;那么&＃xff0c;如果这个queue有数据到达&＃xff0c;那么这个数据会被cache&＃xff0c;不会被丢弃。当有Consumer时&＃xff0c;这个数据会被立即发送到这个Consumer&＃xff0c;这个数据被Consumer正确收到时&＃xff0c;这个数据就被从queue中删除。

消息持久化

RabbitMQ支持消息的持久化&＃xff0c;也就是数据写在磁盘上&＃xff0c;为了数据安全考虑&＃xff0c;大多数用户都会选择持久化。消息队列持久化包括3个部分&＃xff1a;

1.Exchange持久化&＃xff0c;在声明时指定durable &＃61;> 1

2.Queue持久化&＃xff0c;在声明时指定durable &＃61;> 1

3.消息持久化&＃xff0c;在投递时指定delivery_mode &＃61;> 2&＃xff08;1是非持久化&＃xff09;

若Exchange和Queue都是持久化的&＃xff0c;那么它们之间的Binding也是持久化的&＃xff1b;而Exchange和Queue两者之间有一个持久化&＃xff0c;一个非持久化&＃xff0c;就不允许建立绑定。

特性

可伸缩性&＃xff1a;集群服务

消息持久化&＃xff1a;从内存持久化消息到硬盘&＃xff0c;再从硬盘加载到内存

支持的操作系统

1、Linux

2、WindowsNT到10

3、VxWorks

4、macOS

5、FreeBSD

6、Windows Server2003到2016

7、Solaris

8、TRU64

支持的编程语言

1、Swift

2、Java

3、Elixir

4、Python

5、Javascript

6、Objective-C

7、Go

8、Ruby

9、C#

7、Ruby

8、PHP

使用场景

1. 解耦&＃xff08;为面向服务的架构&＃xff08;SOA&＃xff09;提供基本的最终一致性实现&＃xff09;

2. 异步提升效率

3. 流量削峰&＃xff0c;流量削峰也是消息队列中的常用场景&＃xff0c;一般在秒杀或团抢活动中使用广泛

优缺点

在特殊场景下有其对应的好处&＃xff0c;解耦、异步、削峰。

「缺点」

1、系统的可用性降低

系统引入的外部依赖越多&＃xff0c;系统越容易挂掉。

2、系统的复杂性提高

引入了MQ之后&＃xff0c;需要考虑的问题也变得多了&＃xff0c;如何保证消息没有重复消费&＃xff1f;如何保证消息不丢失&＃xff1f;怎么保证消息传递的顺序&＃xff1f;

3、一致性问题

A系统发送完消息直接返回成功&＃xff0c;但是BCD系统之中若有系统写库失败&＃xff0c;则会产生数据不一致的问题。这就涉及到分布式事务的问题。