写在正文之前,最近很多小伙伴都在考虑要不要加入本次金三银四,那么他们害怕的点在哪里呢?无非就是下面这两点!
- 疫情当前,很多公司、企业都在不断裁员,害怕跳槽只跳了一半,自己跳了出去却没有公司要自己。
- 觉得自己工作经验不够,想在小公司再干一年。
以上这两点总结下来其实就是一句话!
对于自己的实力没有信心,自己所掌握的知识点还不足以支撑自己去跳槽,找到高薪岗位!
我其实一直有一句座右铭:新年过完了,其实马上就是下一个新年了,每次都想着等一等在去努力、等一等再去冲刺,那么永远都会慢别人一步!
所以赶紧私信我 【RabbitMQ面经】 免费领取 Java高阶学习资源 和 互联网企业面经!
正文
问题一:RabbitMQ 中的 broker 是指什么?cluster 又是指什么?
答:broker 是指一个或多个 erlang node
的逻辑分组,且 node 上运行着 RabbitMQ
应用程序。cluster 是在 broker 的基础之上,增加了 node 之间共享元数据的约束。
问题二:什么是元数据?元数据分为哪些类型?包括哪些内容?与 cluster 相关的元数据有哪些?元数据是如何保存的?元数据在 cluster 中是如何分布的?
答:在非 cluster
模式下,元数据主要分为 Queue
元数据(queue
名字和属性等)、Exchange 元数据(exchange
名字、类型和属性等)、Binding 元数据(存放路由关系的查找表)、Vhost 元数据(vhost
范围内针对前三者的名字空间约束和安全属性设置)。在 cluster
模式下,还包括 cluster
中 node 位置信息和 node 关系信息。元数据按照 erlang node
的类型确定是仅保存于 RAM 中,还是同时保存在 RAM 和 disk 上。元数据在 cluster
中是全 node
分布的。
问题三:RabbitMQ 概念里的 channel、exchange 和 queue 这些东东是逻辑概念,还是对应着进程实体?这些东东分别起什么作用?
答:queue
具有自己的 erlang
进程;exchange
内部实现为保存 binding
关系的查找表;channel
是实际进行路由工作的实体,即负责按照 routing_key
将 message
投递给 queue
。由 AMQP
协议描述可知,channel
是真实 TCP
连接之上的虚拟连接,所有 AMQP
命令都是通过 channel
发送的,且每一个 channel
有唯一的 ID
。一个 channel
只能被单独一个操作系统线程使用,故投递到特定 channel
上的 message
是有顺序的。但一个操作系统线程上允许使用多个 channel
。channel
号为 0 的 channel
用于处理所有对于当前 connection
全局有效的帧,而 1-65535 号 channel
用于处理和特定 channel
相关的帧。
其中每一个 channel
运行在一个独立的线程上,多线程共享同一个 socket
。
问题四:vhost 是什么?起什么作用?
答:vhost
可以理解为虚拟 broker ,即 mini-RabbitMQ server
。其内部均含有独立的 queue
、exchange
和 binding
等,但最最重要的是,其拥有独立的权限系统,可以做到 vhost
范围的用户控制。当然,从 RabbitMQ 的全局角度,vhost
可以作为不同权限隔离的手段(一个典型的例子就是不同的应用可以跑在不同的 vhost
中)。
问题五:若 cluster 中拥有某个 queue 的 owner node 失效了,且该 queue 被声明具有 durable 属性,是否能够成功从其他 node 上重新声明该 queue ?
答:不能,在这种情况下,将得到 404 NOT_FOUND
错误。只能等 queue
所属的 node
恢复后才能使用该 queue
。但若该 queue
本身不具有 durable
属性,则可在其他 node
上重新声明。
问题六:能够在地理上分开的不同数据中心使用 RabbitMQ cluster 么?
答:不能。第一,你无法控制所创建的 queue
实际分布在 cluster
里的哪个 node
上(一般使用 HAProxy + cluster
模型时都是这样),这可能会导致各种跨地域访问时的常见问题;第二,Erlang
的 OTP 通信框架对延迟的容忍度有限,这可能会触发各种超时,导致业务疲于处理;第三,在广域网上的连接失效问题将导致经典的“脑裂”问题,而 RabbitMQ 目前无法处理(该问题主要是说 Mnesia
)。
问题七:为什么 heavy RPC 的使用场景下不建议采用 disk node ?
答:heavy RPC
是指在业务逻辑中高频调用 RabbitMQ 提供的 RPC 机制,导致不断创建、销毁 reply queue
,进而造成 disk node
的性能问题(因为会针对元数据不断写盘)。所以在使用 RPC 机制时需要考虑自身的业务场景。
最后
011)]
[外链图片转存中…(img-vmJg2Zbw-1628608413015)]