一个RabbitMQ消息代理是一个由一个或多个Erlang节点组成的逻辑组，其中的每个节点都共享users, virtual hosts, queues, exchanges, bindings, and runtime parameters。我们把这些相关节点组成的集合作为一个cluster（集群）。
What is Replicated?
所有数据需要在集群中的所有节点被复制。默认情况下，数据同一个数据只存在于其中一个节点上。为了在集群的节点之间复制数据，请高可用。
Hostname Resolution Requirements
RabbitMQ节点之间用域名名称，可以是简单的域名名称也可以用全限定的。因此，集群中的所有成员的hostnames（主机名）必须能够被解析。
Cluster Formation
创建集群的方式有很多种：
- 在配置文件中声明
- 基于DNS发现
- 各种插件
- 通过rabbitmqctl手动创建
所有的RabbitMQ消息代理在启动以后都是作为单个结点运行的。这些结点可以被加到集群中。
Failure Handling
RabbitMQ运行个别节点失败。必要的话，结点可以被启动和停止。
推荐运行在LAN（局域网）中
Disk and RAM Nodes
A node can be a disk node or a RAM node
90%的情况下你需要的的是disk node；而RAM node是为了提升集群的性能而使用的一种特殊情况。
由于RAM node只在内存中存储其内部数据库，因此它启动的时候必须从一个对等的节点那里同步这些信息，这也就意味着一个集群中至少要包含一个disk node。
结点之间如何相互认证：the Erlang Cookie
RabbitMQ结点用cookie来决定是否它们之间允许互相通信。两个结点之间要想相互通信，它们必须拥有相同的secret，这个secret被称为Erlang Cookie。这个cookie仅仅只是一个字符串，通常它被存储在本例文件中，这个文件只能被其所有者访问。集群中的每个结点必须有相同的cookie。如果这个文件不存在，那么当RabbitMQ服务器启动的时候Erlang VM将自动创建一个文件，其值是随机生成的。
Connecting to Clusters from Clients
一个客户端可以正常连接到集群中的任意结点。如果那个结点失败的话，集群中的剩余结点仍然可以提供服务，当然客户端应该也注意到连接以及关闭，并且能够重新连接到集群中的其它成员。一般而言，不建议将结点的主机名或者IP地址引入到应用程序中，因为这样会导致程序不够灵活，并且万一集群的结点配置变了的话应用程序也必须随之修改。代替的，推荐用一种更加抽象的方式：这种方式可能是一个动态的DNS服务。
参考 http://www.rabbitmq.com/clustering.html