RabbitMQ集群和镜像队列在幕后的行为

有人可以解释在发布到从节点时具有多个节点和队列的RabbitMQ集群中幕后发生的事情吗？

这篇博客概述了究竟会发生什么.

但是当我发布到从属节点时会发生什么？此节点是否会将消息首先发送给主节点？

该消息将重定向到主队列 - 即创建队列的节点.

但是你如何处理主失败？然后其中一个奴隶将被选为主人,所以你必须知道连接到哪里？

同样,这里也包含了这个内容.实质上,您需要一个单独的服务来轮询RabbitMQ并确定节点是否存活.RabbitMQ 为此提供了管理API.您的发布和使用应用程序需要直接或通过相互数据存储引用此服务,以确定要发布或使用的正确节点.

与兔子的连接是永久性的,所以如果它失败了,你必须重新创建它.此外,在这种情况下,您必须重新发送消息,否则您将丢失它们.

您需要订阅连接中断的事件以对断开的连接作出反应.您需要在客户端上构建一定级别的冗余,以确保消息不会丢失.如上所述,我建议您引入专门用于询问RabbitMQ的服务.您的客户端可以尝试将消息发布到上次已知的活动连接,如果失败,客户端可能会向监视器服务请求RabbitMQ群集的最新列表.假设存在至少一个活动节点,则客户端可以建立与其的连接并成功发布消息.

即使有了这一切,消息仍然可能丢失,因为当我杀死节点时它们可能正在传输中

有些边缘情况你无法覆盖冗余,RabbitMQ也不能.例如,当消息登陆队列时,HA策略调用后台进程将消息复制到备份节点.在此过程中,消息可能会在保留到备份节点之前丢失.如果活动节点立即失败,则消息将永久丢失.对此无能为力.不幸的是,当我们达到通过网络传输的实际字节数时,我们可以构建的安全措施数量有限.

因此,消费者应用程序将需要以幂等方式执行重复数据删除或处理传入消息.

您可以通过多种方式处理此问题.例如,将message-ttl值设置为相对较低的值将确保重复的消息不会长时间保留在队列中.您还可以使用唯一引用标记每条消息,并在使用者级别检查该引用.当然,这需要存储已处理消息的缓存以比较传入消息; 这个想法是,如果先前处理的消息到达,其标签将由消费者缓存,并且可以忽略该消息.

我一直强调的一点是,基于AMQP和基于队列的解决方案是您的基础架构提供工具,而不是整个解决方案.您必须根据业务需求弥补这些差距.通常,最好的解决方案是通过反复试验得出的.我希望我的建议有用.我博客上的一些RabbitMQ的设计解决方案,这里包括你提到的问题在这里,如果你有兴趣.