RabbitMQShovel的原理好用法是什么
RabbitMQ Shovel的原理好用法是什么,很多新手对此不是很清楚,为了帮助大家解决这个难题,下面小编将为大家详细讲解,有这方面需求的人可以来学习下,希望你能有所收获。
创新互联建站是一家专业提供张家川回族自治企业网站建设,专注与网站设计、成都网站设计、H5场景定制、小程序制作等业务。10年已为张家川回族自治众多企业、政府机构等服务。创新互联专业网络公司优惠进行中。
Shovel能够可靠、持续地从一个Broker中的队列(作为源端,即source)拉取数据并转发至另一个Broker中的交换器(作为目的端,即destination)。作为源端的队列和作为目的端的交换器可以位于同一个Broker上,也可以位于不同的Broker上。
Shovel原理
broker1中有交换器exchange1和队列queue1,且这两者通过路由键"rk1"进行绑定;broker2中有交换器exchange2和队列queue2,且这两者通过路由键"rk2"进行绑定。
在队列queue1和交换器exchange2之间配置一个Shovel link,当一条内容为"shovel test payload" 的消息从客户端发送至交换器exchange1的时候,这条消息会经过上图中的数据流转最后存储在队列queue2中。如果在配置Shovel link设置了add-forward-headers参数为true,则在消费到队列queue2中这条消息的时候会有特殊的headers属性标记。如下图:上面讲述的是源端为队列,目的端为交换器,下面看一下目的端也为队列的示意图:虽然看起来队列queue1是通过Shovel link直接将消息转发至queue2的,其实中间也是经由broker2的交换器转发,只不过这个交换器是默认的交换器而己。
再看一下源端是交换器,目的端是交换器的示意图:虽然看起来交换器exchange1是通过Shovel link直接将消息转发至exchange2上的,实际上在broker1中会新建一个队列(名称由RabbitMQ自定义,比如上图中的"amq.gen-ZwolUsoUchY6a7xaPyrZZH")并绑定exchange1,消息从交换器exchange1过来先存储在这个队列中,然后Shovel再从这个队列中拉取消息进而转发至交换器exchange2。
broker1和broker2中的exchange1、queue1、exchange2及queue2都可以在Shovel成功连接源端或者目的端Broker之后再第一次创建(执行一系列相应的AMQP配置声明时),它们并不一定需要在Shovel link建立之前创建。Shovel可以为源端或者目的端配置多个Broker的地址,这样可以使得源端或者目的端的Broker失效后能够尝试重连到其他Broker之上(随机挑选)。
可以设置reconnect delay参数以避免由于重连行为导致的网络泛洪,或者可以在重连失败后直接停止连接。针对源端和目的端的所有配置声明会在重连成功之后被重新发送。
Shovel使用
Shovel插件默认也在RabbitMQ的发布包中,执行rabbitmq-plugins enable rabbitmqshovel命令可以开启Shovel功能,该命令默认也会开启amqpclient插件。要开启Shovel的管理插件,需要执行rabbitmq-plugins enable rabbitmqshovelmanagement命令。
Shovel既可以部署在源端,也可以部署在目的端。有两种方式可以部署Shovel: 静态方式和动态方式。静态方式是指在rabbitmq.config配置文件中设置,而动态方式是指通过Runtime Parameter设置。我们这里讲动态方式配置,基于插件的WEB管理界面进行配置。
Name:该Shovel配置的名称
Source:Source中需要指定协议类型、连接的源节点地址,源端的类型(队列、交换器,如果是交换器还需要填入routingKey)
Prefetch count:该参数表示Shovel内部缓存的消息条数,可以参考Federation的相关参数。Shovel的内部缓存是源端服务器和目的端服务器之间的中间缓存部分
Auto-delete:默认为Never表示不删除自己,如果设置为After initial length transferred,则再消息转移完成后删除自己。
Destination:Destination需要指定协议类型,连接的目的节点地址,目的端的类型(队列、交换器,如果是交换器还需要填入routingKey)
Add forwarding headers:如果设置为true,则会在转发的消息内添加x-shovelled的header属性
Reconnect delay:指定在Shovel link失效的情况下,重新建立连接前需要等待的时间,单位为秒。如果设置为0,则不会进行重连动作,即Shovel会在首次连接失效时停止工作。默认为5秒。
Acknowledgement mode:参考Federation的配置。no ack表示无须任何消息确认行为;on publish表示Shovel会把每一条消息发送到目的端之后再向源端发送消息确认; on confirm表示Shovel会使用publisher confirm机制,在收到目的端的消息确认之后再向源端发送消息确认。
Shovel处理消息堆积
消息堆积是在使用消息中间件过程中遇到的最正常不过的事情。消息堆积是一把双刃剑,适量的堆积可以有削峰、缓存之用,但是如果堆积过于严重,那么就可能影响到其他队列的使用,导致整体服务质量的下降。
处理消息堆积的整体思路是为集群准备一个备用集群,当在线的集群某个队列消息堆积严重时,则开启Shovel将消息导入到备用机群的某一个,等到在线集群消息堆积状况回暖时,再开启Shovel从备用集群的队列中导入到原集群中的队列。
下图是Federation/Shovel与集群的区别
看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注创新互联行业资讯频道,感谢您对创新互联的支持。
网页题目:RabbitMQShovel的原理好用法是什么
标题URL:http://cdiso.cn/article/jpcgoh.html