《RabbitMQ消息中间件面试专题及答案.》由会员分享，可在线阅读，更多相关《RabbitMQ消息中间件面试专题及答案.（5页珍藏版）》请在金锄头文库上搜索。
1、问题一：RabbitMQ 中的 broker 是指什么？cluster 又是指什么？答：broker 是指一个或多个 erlang node 的逻辑分组，且 node 上运行着 RabbitMQ 应用程序。cluster 是在 broker 的基础之上，增加了 node 之间共享元数据的约束。问题二：什么是元数据？元数据分为哪些类型？包括哪些内容？与 cluster 相关的元数据有哪些？元数据是如何保存的？元数据在 cluster 中是如何分布的？答：在非cluster模式下，元数据主要分为Queue元数据（queue名字和属性等）、Exchange 元数据（exchange 名字、类型和属性
2、等）、Binding 元数据（存放路由关系的查找表）、Vhost元数据（vhost范围内针对前三者的名字空间约束和安全属性设置）。在cluster 模式下，还包括 cluster 中 node 位置信息和 node 关系信息。元数据按照 erlangnode 的类型确定是仅保存于 RAM 中，还是同时保存在 RAM 和 disk 上。元数据在cluster 中是全 node 分布的。下图所示为 queue 的元数据在单 node 和 cluster 两种模式下的分布图。问题三：RAM node 和 disk node 的区别？答：RAM node 仅将 fabric（即 queue、excha
3、nge 和 binding 等 RabbitMQ 基础构件）相关元数据保存到内存中，但 disk node 会在内存和磁盘中均进行存储。RAM node 上唯一会存储到磁盘上的元数据是 cluster 中使用的 disk node 的地址。要求在 RabbitMQ cluster 中至少存在一个 disk node 。问题四：RabbitMQ 上的一个 queue 中存放的 message 是否有数量限制？答：可以认为是无限制，因为限制取决于机器的内存，但是消息过多会导致处理效率的下降。问题五：RabbitMQ 概念里的 channel、exchange 和 queue 这些东东是逻辑概念，还
4、是对应着进程实体？这些东东分别起什么作用？答：queue 具有自己的 erlang 进程；exchange 内部实现为保存 binding 关系的查找表；channel是实际进行路由工作的实体，即负责按照routing_key将message投递给queue 。由 AMQP 协议描述可知，channel 是真实 TCP 连接之上的虚拟连接，所有AMQP 命令都是通过 channel 发送的，且每一个 channel 有唯一的 ID。一个 channel 只能被单独一个操作系统线程使用，故投递到特定 channel 上的 message 是有顺序的。但一个操作系统线程上允许使用多个 channe
5、l 。channel 号为 0 的 channel 用于处理所有对于当前 connection 全局有效的帧，而 1-65535 号 channel 用于处理和特定 channel 相关的帧。AMQP 协议给出的 channel 复用模型如下其中每一个 channel 运行在一个独立的线程上，多线程共享同一个 socket。问题六：vhost 是什么？起什么作用？答：vhost可以理解为虚拟broker，即mini-RabbitMQ server。其内部均含有独立的queue、exchange和binding等，但最最重要的是，其拥有独立的权限系统，可以做到vhost 范围的用户控制。当然，从
6、 RabbitMQ 的全局角度，vhost 可以作为不同权限隔离的手段（一个典型的例子就是不同的应用可以跑在不同的 vhost 中）。【cluster 相关】问题七：在单 node 系统和多 node 构成的 cluster 系统中声明 queue、exchange ，以及进行 binding 会有什么不同？答：当你在单 node 上声明 queue 时，只要该 node 上相关元数据进行了变更，你就会得到 Queue.Declare-ok 回应；而在 cluster 上声明 queue ，则要求 cluster 上的全部node 都要进行元数据成功更新，才会得到 Queue.Declare-
7、ok 回应。另外，若 node 类型为 RAM node 则变更的数据仅保存在内存中，若类型为 disk node 则还要变更保存在磁盘上的数据。问题八：客户端连接到 cluster 中的任意 node 上是否都能正常工作？ 答：是的。客户端感觉不到有何不同。问题九：若 cluster 中拥有某个 queue 的 owner node 失效了，且该 queue 被声明具有durable 属性，是否能够成功从其他 node 上重新声明该 queue ？答：不能，在这种情况下，将得到 404 NOT_FOUND 错误。只能等 queue 所属的 node 恢复后才能使用该 queue 。但若该 q
8、ueue 本身不具有 durable 属性，则可在其他 node 上重新声明。问题十：cluster 中 node 的失效会对 consumer 产生什么影响？若是在 cluster 中创建了mirrored queue ，这时 node 失效会对 consumer 产生什么影响？答：若是 consumer 所连接的那个 node 失效（无论该 node 是否为 consumer 所订阅queue 的 owner node），则 consumer 会在发现 TCP 连接断开时，按标准行为执行重连逻辑，并根据“Assume Nothing”原则重建相应的fabric即可。若是失效的node为co
9、nsumer 订阅 queue 的 owner node，则 consumer 只能通过 Consumer CancellationNotification 机制来检测与该 queue 订阅关系的终止，否则会出现傻等却没有任何消息来到的问题。问题十一：能够在地理上分开的不同数据中心使用 RabbitMQ cluster 么？答：不能。第一，你无法控制所创建的 queue 实际分布在 cluster 里的哪个 node 上（一般使用 HAProxy + cluster 模型时都是这样），这可能会导致各种跨地域访问时的常见问题；第二，Erlang 的 OTP 通信框架对延迟的容忍度有限，这可能会触
10、发各种超时，导致业务疲于处理；第三，在广域网上的连接失效问题将导致经典的“脑裂”问题，而RabbitMQ 目前无法处理（该问题主要是说 Mnesia）。【综合问题】问题十二：为什么 heavy RPC 的使用场景下不建议采用 disk node ？答：heavy RPC 是指在业务逻辑中高频调用 RabbitMQ 提供的 RPC 机制，导致不断创建、销毁 reply queue ，进而造成 disk node 的性能问题（因为会针对元数据不断写盘）。所以在使用 RPC 机制时需要考虑自身的业务场景。问题十三：向不存在的 exchange 发 publish 消息会发生什么？向不存在的 queu
11、e 执行consume 动作会发生什么？答：都会收到 Channel.Close 信令告之不存在（内含原因 404 NOT_FOUND）。问题十四：routing_key 和 binding_key 的最大长度是多少？ 答：255 字节。问题十五：RabbitMQ 允许发送的 message 最大可达多大？答：根据 AMQP 协议规定，消息体的大小由 64-bit 的值来指定，所以你就可以知道到底能发多大的数据了。问题十六：什么情况下 producer 不主动创建 queue 是安全的？答：1.message 是允许丢失的；2.实现了针对未处理消息的 republish 功能（例如采用Publ
12、isher Confirm 机制）。问题十七：“dead letter”queue 的用途？答：当消息被 RabbitMQ server 投递到 consumer 后，但 consumer 却通过 Basic.Reject 进行了拒绝时（同时设置 requeue=false），那么该消息会被放入“dead letter”queue 中。该 queue 可用于排查 message 被 reject 或 undeliver 的原因。问题十八：为什么说保证 message 被可靠持久化的条件是 queue 和 exchange 具有durable 属性，同时 message 具有 persisten
13、t 属性才行？答：binding 关系可以表示为 exchange binding queue 。从文档中我们知道，若要求投递的 message 能够不丢失，要求 message 本身设置 persistent 属性，要求 exchange 和 queue 都设置 durable 属性。其实这问题可以这么想，若 exchange 或 queue 未设置durable 属性，则在其 crash 之后就会无法恢复，那么即使 message 设置了 persistent 属性，仍然存在 message 虽然能恢复但却无处容身的问题；同理，若 message 本身未设置persistent 属性，则
14、message 的持久化更无从谈起。问题十九：什么情况下会出现 blackholed 问题？答：blackholed 问题是指，向 exchange 投递了 message ，而由于各种原因导致该message 丢失，但发送者却不知道。可导致 blackholed 的情况：1.向未绑定 queue 的exchange 发送 message；2.exchange 以 binding_key key_A 绑定了 queue queue_A，但向该 exchange 发送 message 使用的 routing_key 却是 key_B。问题二十：如何防止出现 blackholed 问题？答：没有特
15、别好的办法，只能在具体实践中通过各种方式保证相关 fabric 的存在。另外， 如果在执行 Basic.Publish 时设置 mandatory=true ，则在遇到可能出现 blackholed 情况时，服务器会通过返回 Basic.Return 告之当前 message 无法被正确投递（内含原因 312NO_ROUTE）。问题二十一：Consumer Cancellation Notification 机制用于什么场景？答：用于保证当镜像 queue 中 master 挂掉时，连接到 slave 上的 consumer 可以收到自身 consume 被取消的通知，进而可以重新执行 consume 动作从新选出的 master 出获得消息。若不采用该机制，连接到 slave 上的 consumer 将不会感知 master 挂掉这个事情，导致后续无法再收到
