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能在你要求的时限内成功启动。
标签:node,RAM,mirrored,server,queue,cluster,RabbitMQ,disk 来源: https://blog.csdn.net/qq_39311377/article/details/110700439