RabbitMq基础教程之基本概念

RabbitMq基础教程之基本概念

RabbitMQ是一个消息队列，和Kafka以及阿里的ActiveMQ从属性来说，干的都是一回事。消息队列的主要目的实现消息的生产者和消费者之间的解耦，支持多应用之间的异步协调工做

因为工做缘由，接触和使用rabbitmq做为生产环境下的消息队列，所以准备写一些博文，记录下这个过程当中的收货；而开篇除了环境搭建以外，就是对于其内部的基本概念进行熟悉和了解了。

基础环境搭建能够参考： 《RabbitMq基础教程之安装与测试》

本文则主要集中在如下几点：

• 几个基本概念（Message, Publisher, Exchange, Binding, Queue, Channel, Consuer, Virtual host)
• 消息分发的几种策略
• ACK是什么鬼

<!-- more -->

I. 基本概念

1. 消息队列

首先来一张消息队列的经典图，能够划分为三个角色: Producer, Queue, Consumer

• Queue：为承载消息的容器，为何是队列而不是栈呢？主要是由于绝大部分的场景，咱们都是但愿消息是先进先出，有顺序的
• Producer：生产者，就是产生消息，并不断往队列塞的角色
• Consumer：消费者，也就是不断从队列中获取消息的角色

看到这个模型，若是对JDK的容器有必定的了解，很容易能够想到借助 ArrayBlockingQueue 或者 ListBlockingQueue 就能够实现简易的消息队列（也就是咱们常说的生产者-消费者模型）

2. 实例理解消息队列

其实在生活中，这种模型用得很是多，就好比咱们都会接触的网购快递，能够说是一个典型的消息队列的case了：

商家不断的把商品扔给快递公司（注意不是直接将商品给买家），而快递公司则将商品根据地质分发对应的买家

对上面这个过程进行拆解，能够映射扮演的角色

• 商品：Message，传递的消息，由商家投递给快递公司时，须要进行打包（通常Producer生产消息也会将实体数据进行封装）
• 商家：Produer 生产者
• 快递公司： Queue，消息的载体
• 买家：Consumer 消费者

那么快递公司时怎么知道要把商品给对应的买家呢？根据包裹上的地址+电话

• 一样消息队列也须要一个映射规则，实现Message和Consumer之间的路由

3. RabbitMQ基本概念

经过上面的实例对比，发现基本的消息队列定义的元素太少，这里则正好能够看一下RabbitMQ是怎么具体来实现消息队列的

• Message：消息，包含消息头（即附属的配置信息）和消息体（即消息的实体内容）
• Publisher：生产者，向交换机发布消息的主体
• Exchange：交换机，用来接收生产者发送的消息并将这些消息路由给服务器中的队列
• Binding：绑定，用于给Exchange和Queue创建关系，就是咱们熟知的配对的红娘
• Queue：消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者链接到这个队列将其取走。
• Connection：链接
• Channel：通道，MQ与外部打交道都是经过Channel来的，发布消息、订阅队列仍是接收消息，这些动做都是经过Channel完成；简单来讲就是消息经过Channel塞进队列或者流出队列
• Consumer：消费者，从消息队列中获取消息的主体
• Virtual Host: 虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每一个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有本身的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础，必须在链接时指定，RabbitMQ 默认的 vhost 是 /
• Broker：消息队列服务器实体

上面是一些专业的概念，那么能够怎么映射到前面的快递上呢？

II. Exchange类型

生产者，将消息投递给Exchange，而后由Exchange将消息路由到对应的Queue上，供消费者消费，那么这个路由有哪些方式呢？

1. Direct策略

消息中的路由键（routing key）若是和 Binding 中的 binding key 一致， 交换器就将消息发到对应的队列中

简单来说，就是路由键与队列名彻底匹配

• 若是一个队列绑定到交换机要求路由键为“dog”
• 只转发 routing key 标记为“dog”的消息，
• 不会转发“dog.puppy”，也不会转发“dog.guard”等等
• 它是彻底匹配、单播的模式

举例说明

Exchange和两个队列绑定在一块儿：

• Q1的bindingkey是orange
• Q2的binding key是black和green.
• 当Producer publish key是orange时, exchange会把它放到Q1上, 若是是black或green就会到Q2上, 其他的Message被丢弃

2. Fanout策略

从上图也能够看出，这种策略，将忽略所谓的routing key,将消息分发到全部绑定的Queue上，更加相似咱们理解的广播模式

3. Topic策略

topic 交换器经过模式匹配分配消息的路由键属性，将路由键和某个模式进行匹配，此时队列须要绑定到一个模式上

能够理解为直接策略的进阶版，直接策略是彻底精确匹配，而topic则支持正则匹配，知足某类指定规则的（如以xxx开头的路由键），能够键消息分发过去

• # 匹配0个或多个单词
• * 匹配很少很多一个单词

一个更直观的实例以下

Producer发送消息时须要设置routing_key,

• Q1 的binding key 是”.orange.“
• Q2 是 “..rabbit” 和 “lazy.#”：
• 产生一个 test.orange.mm 消息，则会路由到Q1；而若是是 test.orange则没法路由到Q1,由于Q1的规则是三个单词，中间一个为orange，不知足这个规则的都无效
• 产生一个 test.qq.rabbit 或者 lazy.qq 均可以分发到Q2；即路由key为三个单词，最后一个为rabbit或者不限制单词个数，主要第一个是lazy的消息，均可以分发过来
• 若是产生的是一个 test.orange.rabbit消息，则Q1和Q2均可以知足

4. Headers策略

这个实际上用得很少，它是根据Message的一些头部信息来分发过滤Message，忽略routing key的属性，若是Header信息和message消息的头信息相匹配

5. 小结

主要使用的消息分发策略有三个，直接，路由和扇形，简单的小结下应用场景和区别

a. Direct Exchange

直接彻底匹配模式，适用于精准的消息分发

b. Topic Exchange

Routing Key的匹配模式，支持Routing Key的模糊匹配方式，更适用于多类消息的聚合

c. Fanout Exchange

忽略Routing Key, 将消息分配给全部的Queue，广播模式，适用于消息的复用场景

III. ACK

消息队列的一个重要指标，当有消费者获取了消息以后，对这个消息我应该怎么办？是直接删除仍是等某个合适的机会再删除？又或者是干脆不删除，就留着了？

在实际的应用场景中，消息正常消费以后，咱们但愿的是这个消息就不要了，可是消费的过程当中若是出现了bug，则但愿不要删除消息，等我修复这个bug后，能够把这个消息从新的投递给我

1. ack机制

Consumer接收到了消息以后，必须返回一个ack的标志，表示消息是否成功消费，若是返回true，则表示消费成功了，而后这个消息就会从RabbitMQ的队列中删掉；若是返回false，且设置为从新入队，则这个消息能够被从新投递进来

一般实际编码中，默认是自动ACK的，若是消息的重要性程度较高，咱们应该设置为主动ACK，在接收到消息以后，自主的返回对应的ACK信息

这一块更多地内容能够查看实际使用篇

IV. 其余

1. 参考

• Consumer Acknowledgements and Publisher Confirms
• RabbitMQ Tutorials
• RabbitMQ】三种Exchange模式——订阅、路由、通配符模式

2. 一灰灰Blog： https://liuyueyi.github.io/hexblog

一灰灰的我的博客，记录全部学习和工做中的博文，欢迎你们前去逛逛

3. 声明

尽信书则不如，已上内容，纯属一家之言，因我的能力有限，不免有疏漏和错误之处，如发现bug或者有更好的建议，欢迎批评指正，不吝感激

• 微博地址: 小灰灰Blog
• QQ： 一灰灰/3302797840

4. 扫描关注