乐趣区

关于golang:我们一起来学RabbitMQ-五RabbitMQ-应知应会的面试题

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 预取模式

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

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

RabbitMQ 中既然有了connections 为什么还要有 channel

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 有哪些知识点?

生产者

  • 音讯生产者,投递音讯
  • 音讯个别蕴含两个局部:音讯体(payload)和标签(Label)

消费者

  • 生产音讯,接管音讯
  • 消费者连贯到 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

欢送点赞,关注,珍藏

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

好了,本次就到这里

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

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

退出移动版