MQ 是什么？

MQ（Message Queue）音讯队列

用队列机制来实现软件之间的通信，消费者能够到指定队列拉取音讯，或者订阅相应的队列，由MQ服务端给其推送音讯

什么是队列？

是一种数据结构，遵循 FIFO （先进先出）准则

凭啥要应用 MQ ， MQ 有啥劣势？

  • 异步通信

将以前也不中不必要的同步操作，优化成异步操作，进步性能

  • 业务解耦

将原有A模块间接调用B模块的接口，优化成，A模块的申请给到MQ，A模块的事件就做完了

MQ会被动推给B模块，或者B模块本人来拉

  • 流量削峰

当某一时间大量的流量打到服务器上，服务器一时间无奈接受，会宕机

这个时候，若申请都是从音讯队列外面进去，则可能保障这种大流量的状况下，服务器依然可能有序的稳固的解决申请

MQ 有啥劣势呢？

  • 零碎可用性升高，对外部有依赖了
  • 须要思考 MQ 音讯失落，反复生产的问题
  • 须要破费精力保障音讯的程序性，一致性

罕用 MQ 性能比照

ActiveMQ RabbitMQ RocketMQ Kafka
开发语言 java erlang java scala
单机吞吐量 万级 万级 十万级 十万级
时效性 ms级 us级 ms级 ms级以内
可用性 高
主从架构		 高
主从架构		 十分高
分布式架构		 十分高
分布式架构
音讯可靠性 较低概率失落音讯 根本不丢 能够做到根本不丢 能够做到根本不丢
性能反对 反对性能全 性能好
延时低
并发能力强		 MQ 性能较欠缺
反对分布式，扩展性好		 次要用于大数据和日志采集

MQ 如何防止音讯沉积

  • 进步生产速率（集群的形式）
  • 消费者批量获取音讯进行生产

MQ 如何防止消费者反复生产（幂等性问题）

  • 全局ID（减少标记位） + 保障业务一致性

MQ 如何保障音讯不失落

  • 音讯确认机制
  • 长久化
  • 音讯 ACK

MQ 如何保障音讯程序一致性

  • 绑定同一个消费者和队列

MQ 推与拉取架构模型是怎么样的？

  • MQ 服务器与消费者建设长连贯后，MQ 服务器会被动推数据给到消费者
  • 当消费者第一次启动的时候，会去找MQ 服务器拉数据

mq有哪些生产模式

  • 推模式
    注册一个消费者后，RabbitMQ会在音讯可用时，主动将音讯进行推送给消费者。这种形式效率最高最及时。
  • 拉模式
    属于一种轮询模型，发送一次get申请，取得一个音讯。如果此时RabbitMQ中没有音讯，会取得一个示意空的回复。
  • 主动确认

消费者生产音讯的时候，将主动向RabbitMQ进行确认。

  • 手动确认

消费者生产音讯的时候，手动调用相应函数进行ack 应答

  • qos预取模式

在确认音讯被接管之前，消费者能够事后要求接管肯定数量的音讯，在解决完肯定数量的音讯后，批量进行确认

当然，如果消费者应用程序在确认音讯之前解体，则所有未确认的音讯将被从新发送给其余消费者

RabbitMQconnectionschannel

connection 是什么

connection 是 生产者或消费者与 RabbitMQ Broker 建设的连贯，是一个TCP连贯

一旦 TCP 连贯建设起来，客户端紧接着能够创立一个 AMQP 信道（Channel），每个信道都会被指派一个惟一的 ID

信道是建设在 Connection 之上的虚构连贯，多个信道复用一个TCP连贯，能够缩小性能开销，同时也便于管理

因为一个利用须要向RabbitMQ 中生成或者生产音讯的话，都要建一个TCP连贯，TCP连贯开销十分大，如果遇到应用顶峰，性能瓶颈也随之浮现

信道复用连贯劣势：

  • 复用TCP连贯，缩小性能开销，便于管理
  • RabbitMQ 保障每一个信道的私密性

当每个信道的流量不是很大时，复用繁多的 Connection 能够在产生性能瓶颈的状况下无效地节俭 TCP 连贯资源

信道自身的流量很大时，这时候多个信道复用一个 Connection 就会产生性能瓶颈，进而使整体的流量被限度了，此时就须要开拓多个 Connection，将这些信道均摊到这些 Connection 中

RabbitMQ
  • 削峰填谷
  • 生产者和消费者业务解耦
  • 服务间异步通信
  • 定时工作
  • 程序生产

为什么抉择 RabbitMQ

当初的市面上有很多 MQ 能够抉择，比方 ActiveMQ、ZeroMQ、Appche Qpid为什么要抉择 RabbitMQ？

  • 除了 Qpid，RabbitMQ 是惟一一个实现了 AMQP 规范的音讯服务器
  • 可靠性，RabbitMQ 的长久化反对，保障了音讯的稳定性
  • 高并发，RabbitMQ 应用了 Erlang 开发语言，Erlang 是为电话交换机开发的语言，天生自带高并发光环，和高可用个性
  • 集群部署简略，正是应为 Erlang 使得 RabbitMQ 集群部署变的超级简略
  • 社区活跃度高，依据网上材料来看，RabbitMQ 也是首选

RabbitMQ 的特点是什么?

  • 牢靠

    RabbitMQ 应用 如长久化、传输确认及公布确认等机制来保障可靠性

  • 灵便的路由

通过交换器来路由音讯

对于典型的路由性能， RabbitMQ 己经提供了一些内置的交换器来实现

针对更简单的路由性能，能够将多个 交换器绑定在一起，这个就须要通过插件来实现了

  • 扩展性

多个 RabbitMQ 节点能够组成一个集群，也能够依据理论业务状况动静地扩大集群中节点

  • 高可用性

队列能够在集群中的机器上设置镜像，使得在局部节点呈现问题的状况下队列依然可用

  • 反对的协定多

RabbitMQ 除了原生反对 AMQP 协定，还反对 STOMP， MQTT等多种消息中间件协定

  • 多语言客户端

RabbitMQ 简直反对所有罕用语言，比方 GO、 Java、 Python、 Ruby、 PHP等

  • WEB 治理界面

RabbitMQ 提供了一个易用的用户界面，使得用户能够监控和治理音讯、集群中的节点等

  • 命令插件机制

RabbitMQ 提供了许多插件 ， 以实现从多方面进行扩大，当然也能够编写本人的插件

生产者Producer和消费者Consumer 有哪些知识点？

生产者

payloadLabel

消费者

  • 生产音讯，接管音讯

  • 消费者连贯到 RabbitMQ 服务器，并订阅到队列

    生产音讯时只生产音讯体，抛弃标签

RabbitMQ 音讯长久化中的坑

默认状况下重启服务器会导致音讯失落，咱们如何保障重启 RabbitMQ 不失落数据？

那就是做长久化，长久化须要满足如下三个条件才能够复原 RabbitMQ 的数据

  • 投递音讯的时候 durable 设置为 true，音讯长久化
  • 音讯曾经达到长久化交换器上
  • 音讯曾经达到长久化的队列上

长久化的工作原理

Rabbit 会将长久化音讯写入磁盘上的长久化日志文件，等音讯被生产之后，Rabbit 会把这条音讯标识为期待垃圾回收

长久化的优缺点

长处

  • 数据长久化，数据不失落

毛病

  • 对性能有影响，写硬盘比写内存性能低，从而升高服务的吞吐量

RabbitMQ ACK 应答机制

ACK 应答分为手动和主动，各有优劣

  • 如果音讯不太重要，失落也没有影响，那么主动 ACK 会比拟不便

  • 如果音讯十分重要，不容失落。那么最好在生产实现后手动 ACK

    否则接管音讯后就主动 ACK，RabbitMQ 就会把音讯从队列中删除。若此时消费者宕机或解决业务失败，那么音讯就失落了

ACK 机制的开发注意事项

如果遗记了 ACK，那么结果很重大

当 Consumer 退出时候，Message 会始终从新散发。而后 RabbitMQ 会占用越来越多的内容，因为 RabbitMQ 会长工夫运行，这个” 内存透露” 是致命的

为什么须要限流，消费者流量管制

  • 某一时刻，生产者在 RabbitMQ 队列中沉积了很多音讯，此时有一个消费者启动，大量的音讯会推送到消费者下面，这种刹时大流量会把消费者打挂
  • 生产者和消费者效率不均衡的状况，会导致消费者端性能降落，服务端卡顿或者解体

RabbitMQ 的组成

  • 生产者 producer
  • 消费者 consumer
  • 交换机 exchange

用于承受、调配音讯

  • 音讯 message
  • 队列 queue

用于存储生产者的音讯

  • 信道 channel AMQP

音讯推送应用的通道

  • 连贯 connections

生成者或者消费者与Rabbit 建设的TCP 连贯

  • 路由键 routingKey

用于把生成者的数据调配到交换器上

  • 绑定键 BindingKey

用于把交换器的音讯绑定到队列上

  • 连贯管理器 ConnectionFactory

应用程序与 Rabbit 之间建设连贯的管理器，程序代码中应用

  • VHost

vhost 能够了解为虚构 broker，即虚拟机

其外部均含有独立的 queue、exchange 和 binding 等

领有独立的权限零碎，做到资源隔离，资源高效利用

RabbitMQ 的六种模式

  • single

简略的生产者生产音讯，放入队列，消费者生产音讯

  • work

当生产者生产音讯的速度大于消费者生产的速度，就要思考用 work 工作模式，这样能进步处理速度进步负载

work 模式与 single 模式相似， 只是work 模式比 single 模式多了一些消费者

  • publish

利用场景：简略音讯队列的应用，一个生产者一个消费者

  • routing

音讯生产者将音讯发送给交换机依照路由判断,路由是字符串(info) 以后产生的音讯携带路由字符(对象的办法),交换机依据路由的key

只能匹配上路由key对应的音讯队列,对应的消费者能力生产音讯

  • topic

话题模式，一个音讯被多个消费者获取，音讯的指标 queue 可用 BindingKey 以通配符

  • rpc

通过近程过程调用的形式实现

存储机制

  • 长久化音讯

长久化的音讯在达到队列时就被写入磁盘，长久化的音讯也会在内存中保留一份备份，这样能够进步肯定的性能，当内存吃紧的时候会从内存中革除

  • 非长久化音讯

个别只保留在内存中，在内存吃紧的时候会被换入到磁盘中，以节俭内存空间

RabbitMQ中音讯可能有的几种状态

  • alpha

音讯内容(包含音讯体、属性和 headers) 和音讯索引都存储在内存中

  • beta

    音讯内容保留在磁盘中，音讯索引保留在内存中

  • gamma

音讯内容保留在磁盘中，音讯索引在磁盘和内存中都有

  • delta

音讯内容和索引都在磁盘中

RabbitMQ 的队列构造？

  • rabbit_amqqueue_process

负责协定相干的音讯解决，即接管生产者公布的音讯、向消费者交付音讯、解决音讯的确认等

  • backing_queue

是音讯存储的具体模式和引擎，并向 rabbit_amqqueue_process 提供相干的接口以供调用

交换器无奈依据本身类型和路由键找到符合条件队列时，会如何解决？

咱们对交换机设置参数的时候，有一个标记叫做 mandatory

  • 当mandatory标记位设置为true时

如果exchange依据本身类型和音讯routingKey无奈找到一个适合的queue存储音讯，那么broker就会调用basic.return办法将音讯返还给生产者

  • 当mandatory设置为false时

前置条件和上述保持一致，此时 broker会间接将音讯抛弃

如何保障音讯可靠性嘞？

  • 音讯从生产者到 MQ

由事务机制，确认机制 来保障

  • MQ 本身可靠性

由长久化、集群、一般模式、镜像模式来保障

  • MQ 音讯到消费者

由basicAck机制、死信队列、音讯弥补等机制来保障

集群中的节点类型有哪些？

  • 内存节点

ram，将变更写入内存。

  • 磁盘节点

disc，磁盘写入操作

RabbitMQ中 要求起码有一个磁盘节点

如何保障 RabbitMQ 音讯队列的高可用?

RabbitMQ中有三种模式来保障：

  • 单机模式

个别是本地启动，本人学习和测试应用，不会用在生产环境上

  • 一般集群模式

在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个

  • 镜像集群模式

RabbitMQ的高可用模式

跟一般集群模式不一样的是，创立的 queue，无论元数据(元数据指 RabbitMQ 的配置数据)还是 queue 里的音讯都会存在于多个实例上，

而后每次写音讯到 queue 的时候，都会主动把音讯到多个实例的 queue 里进行音讯同步

参考资料：

RabbitMQ Tutorials

欢送点赞，关注，珍藏

敌人们，你的反对和激励，是我保持分享，提高质量的能源

好了，本次就到这里

技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。

我是小魔童哪吒，欢送点赞关注珍藏，下次见~