RabbitMQ

RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件，也称面向消息的中间件。

AMQP是一个面向消息中间件的开放式标准应用层协议，定义了以下特性：

消息方向、消息队列、消息路由、可靠性和安全性。

 

概念解释：

Broker：MQ的服务器实体，是一个中间件应用，是整个MQ的server端。

Exchange：消息交换机，接收消息的第一入口。我在绘图时给X添加了一个route，是因为Exchange本身带有route规则的，根据P送来的routeKey配合自己定义的路由规则来决定将消息发送给哪个Queue。

Queue：消息队列，如同java中的queue概念一样，消息压存等待被消费的地方。

Route Key：与Exchange带的路由规则一起配合，决定了X与Q之间多对多的映射关系。

Binding：X-Q连线叫做绑定，单独的X和单独Q没有异议。

Connection：一个Client-Broker（包括producer-broker和consumer-broker）叫做一个连接，是客户端与broker之间进行通信的物理通道。

Channel：用于连接生产者与消费者的逻辑通道，每个链接可建立多个相互隔离的多个channel。

 

一次投递经历的环节是：

1， P与broker建立连接

2， 声明1或N个交换机，再声明1或N个Queue，再订好交换机和Queue之间的路由映射，整个过程就叫绑定。

3， P投递消息到交换机，X根据R决定传给哪个或哪几个Q。

4， C与broker建立连接，声明自己消费哪个Q

5， 一次消息传递结束。

 

 

Exchange几种类型：

1， Direct：完全RouteKey匹配规则

2， Topic：模糊匹配，也就是主题匹配规则。符合#匹配一个或多个词，符合*只能匹配一个词。

3， Fanout：不需要RouteKey，无节操广播模式。

MQ的持久化：

这里标题用的是MQ的持久化，而不是RabbitMQ的持久化，因为RabbitMQ、Kafka等都具有持久化容灾的功能。为了使MQ的读写速度达到极致，各类MQ技术上都采用内存存储的方式来提高响应速度，这种设计致命的缺陷就是一旦出现掉电、宕机等异常出现，MQ重启后内存中未消费的信息将会全部丢失，又重新投胎了一次。

为了弥补这一缺陷，MQ都有自己的持久化机制，原理都是在一定策略下将未消费的信息固化到磁盘中，又在一定策略下清理已消费的部分。持久化越频繁，灾难时丢失的内容越少，开销越大，策略的订制需要根据生产场景来定，取其中的平衡。这也是各种MQ都有定义持久化级别这一参数的原因。

 

RabbitMQ的持久化：

消息持久化在投递时指定delivery_mode,等于1表示不做持久化，大于1表示做持久化。

Exchange做持久化，在声明时设置参数durable；

Queue做持久化，在声明时设置参数durable。

绑定两头的Exchange和Queue必须同时是持久化或非持久化的，不能不相同。

 

Docker安装：

作为研发人员，推荐用docker容器来启动RabbitMQ，因为只要不是为了对组件要有更深的理解，docker足够我们使用了。

命令：docker pull docker.io/rabbitmq

命令：docker run -p 5672:5672  rabbitmq:latest