RabbitMQ中的cluster、mirrored queue，以及 warrens机制、RAM node、disk node及vhost介绍

1、RAM node和disk node的区别？

RAM node仅将fabric（即queue、exchange和binding等RabbitMQ基础构件）相关元数据保存到内存中，但disk node会在内存和磁盘中均进行存储。RAM node上唯一会存储到磁盘上的元数据是cluster中使用的disk node的地址。要求在RabbitMQ cluster中至少存在一个disk node。

2、vhost是什么？起什么作用？

vhost 可以理解为虚拟 broker，即mini-RabbitMQ server。其内部均含有独立的queue、exchange 和binding等，但最最重要的是，其拥有独立的权限系统，可以做到vhost 范围的用户控制。当然，从RabbitMQ的全局角度，vhost可以作为不同权限隔离的手段（一个典型的例子就是不同的应用可以跑在不同的vhost中）。

3、在单node系统和多node构成的cluster系统中声明queue、exchange，以及进行binding会有什么不同？

当你在单 node上声明queue时，只要该node上相关元数据进行了变更，你就会得到Queue.Declare-ok 回应；而在cluster上声明queue，则要求 cluster上的全部node都要进行元数据成功更新，才会得到Queue.Declare-ok回应。另外，若node类型为RAM node则变更的数据仅保存在内存中，若类型为disk node则还要变更保存在磁盘上的数据。

4、客户端连接到cluster中的任意node上是否都能正常工作？

是的。客户端没有什么不同。

5、若cluster中拥有某个queue的owner node失效了，且该queue被声明具有durable属性，是否能够成功从其他node上重新声明该queue？

不能，在这种情况下，将得到404 NOTFOUND错误。只能等queue所属的node恢复后才能使用该queue。但若该queue本身不具有durable属性，则可在其他node上重新声明。

6、为什么heavy RPC的使用场景下不建议采用 disk node？

heavy RPC是指在业务逻辑中高频调用RabbitMQ提供的RPC机制，导致不断创建、销毁reply queue，进而造成disk node的性能问题（因为会针对元数据不断写盘）。所以在使用RPC机制时需要考虑自身的业务场景。

7、routing_key和binding_key的最大长度是多少？

255字节。

8、什么情况下producer不主动创建queue是安全的？

（1）message是允许丢失的；
（2）实现了针对未处理消息的republish功能（例如采用Publisher Confirm 机制）。

9、RabbitMQ中的cluster、mirrored queue，以及 warrens机制分别用于解决什么问题？存在哪些问题？

cluster是为了解决当cluster中的任意node失效后，producer和consumer均可以通过其他node继续工作，即提高了可用性；另外可以通过增加node数量增加cluster的消息吞吐量的目的。cluster本身不负责 message的可靠性问题（该问题由producer通过各种机制自行解决）；cluster无法解决跨数据中心的问题（即脑裂问题）。另外，在cluster 前使用HAProxy可以解决 node的选择问题，即业务无需知道 cluster中多个node的ip地址。可以利用HAProxy进行失效node的探测，可以作负载均衡。下图为HAProxy +cluster 的模型。
Mirrored queue是为了解决使用cluster时所创建的queue的完整信息仅存在于单一node上的问题，从另一个角度增加可用性。若想正确使用该功能，需要保证：
（1）consumer需要支持 Consumer Cancellation Notification机制；
（2）consumer必须能够正确处理重复message。
Warrens是为了解决cluster中message可能被blackholed的问题，即不能接受producer不停 republish message但RabbitMQ server 无回应的情况。Warrens有两种构成方式，一种模型是两台独立的RabbitMQ server+HAProxy，其中两个server的状态分别为active和hot-standby。
该模型的特点为：两台server之间无任何数据共享和协议交互，两台server可以基于不同的RabbitMQ版本。

另一种模型为两台共享存储的RabbitMQ server+keepalived，其中两个server的状态分别为active和cold-standby。该模型的特点为：两台server基于共享存储可以做到完全恢复，要求必须基于完全相同的RabbitMQ版本。

Warrens模型存在的问题：
对于第一种模型，虽然理论上讲不会丢失消息，但若在该模型上使用持久化机制，就会出现这样一种情况，即若作为active的server异常后，持久化在该 server 上的消息将暂时无法被 consume，因为此时该 queue将无法在作为hot-standby的server上被重建，所以，只能等到异常的active server恢复后，才能从其上的queue中获取相应的message进行处理。而对于业务来说，需要具有：
a.感知AMQP连接断开后重建各种fabric的能力；
b.感知 active server 恢复的能力；
c.切换回 active server的时机控制，以及切回后，针对message先后顺序产生的变化进行处理的能力。
对于第二种模型，因为是基于共享存储的模式，所以导致active server异常的条件，可能同样会导致cold-standby server异常；另外，在该模型下，要求 active和cold-standby的server必须具有相同的node名和UID，否则将产生访问权限问题；最后，由于该模型是冷备方案，故无法保证cold-standby server能在你要求的时限内成功启动。