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

MQ 是什么？

MQ（Message Queue）音讯队列

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

什么是队列？

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

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

• 异步通信

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

• 业务解耦

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

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

• 流量削峰

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

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

MQ 有啥劣势呢？

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

罕用 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

欢送点赞，关注，珍藏

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

好了，本次就到这里

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

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