RabbitMQ 集群简介

RabbitMQ 作为消息代理服务器，对于独立应用来说简直完美。但当应用程序需要高可用队列来满足额外的投递保证，或者将 RabbitMQ 用作众多应用程序的中心消息通信总线时，RabbitMQ 内建的集群能力能够跨越多台服务器，提供强大的、内聚的环境。

RabbitMQ 集群无缝封装了多台 RabbitMQ 服务器。在 RabbitMQ 集群里，运行时状态包括交换器、队列、绑定器、用户、虚拟主机以及策略，它们对所有节点都可用。由于这种共享运行时状态的特性，集群中的每个节点都能绑定、发布或者删除连接到第一个节点时创建的交换器。

一些集群节点专门用于服务前端应用程序发布消息，而另一些节点则只用来服务队列和消费者。集群提供了绝佳的方式来创建 HA（高可用）队列，以创建可以容错的 RabbitMQ 环境。HA 队列可以跨越多个集群节点并共享同步队列状态和消息数据。假设 HA 队列中的某个节点发生故障的话，集群中的其他节点仍然保存着消息和队列状态。当故障的节点重新加入集群时，该节点会完全同步自节点故障以来所有被消费的消息。

虽然 RabbitMQ 内建集群有不少优点，但是对其本身的限制和劣势的认识也很重要。首先，集群是按照低延迟环境进行设计的。千万不要跨越 WAN 或者互联网来搭建 RabbitMQ 集群。集群中的状态同步和跨节点的消息投递需要低延迟的通信，只有 LAN 可以满足这一要求。

另一个需要重点考量的问题是 RabbitMQ 的集群大小。维护集群共享状态的工作和开销与集群中节点数据的多少成正比。比如，使用管理 API 来获取大型集群中的统计数据所需要的时间就要比单个节点的要长的多。上述操作耗费的时间和集群中最慢的那个节点响应速度有关。RabbitMQ 社区中的传统观念要求集群中节点数量的上限在 32 到 64 个。每向集群中新添加一个节点，就要为集群中的状态同步增加了更多的复杂性。集群中的每个节点必须知道集群中的其他节点。这种非线性的复杂度会拖慢跨节点的消息投递和集群的管理。