RabbitMQ集群

RabbitMQ集群

集群搭建

• 注意

All data/state required for the operation of a RabbitMQ broker is replicated across all nodes. An exception to this are message queues, which by default reside on one node, though they are visible and reachable from all nodes. To replicate queues across nodes in a cluster, see the documentation on high availability (note that you will need a working cluster first).

RabbitMQ代理的操作所需的所有数据/状态都可以跨所有节点复制。例外的情况是消息队列，默认情况下驻留在一个节点上，尽管它们是可见的，并且可以从所有节点访问。为了在集群中跨节点复制队列，请参阅关于高可用性的文档（注意，首先需要一个工作集群）。

这种是普通集群的方式exchange，buindling再所有的节点上都会保存一份，但是queue只会存储在其中的一个节点上，但是所有的节点都会存储一份queue的meta信息。因为这样有两个好处：

• 存储空间。如果每一个节点上都有全部的消息，有多少个节点就会有多少个消息总量的copy。加入一个队列的消息占用的空间是1G，那么三个节点就是3G

• 性能。消息需要在节点之间传输会有很大的网络开销。如果消息设置了durable即持久化，还会增加很大的磁盘负载

队列存储的节点取决于，创建队列的客户端当时所连接的节点。如果生产者连接的是另外一个节点，将会把消息转发到存储该队列的节点上。如果消费者连接了非存储队列的节点取数据，者从存储消息的节点拉去数据。所以：

• 创建队列都连到了一个节点上，所有的队列都存储在一个节点上。

• 存消息的节点挂掉了，consumer只能等到节点恢复后才能读到消息。

• 设A,B节点，queue数据在A上：可以向A或B生产或消费消息。但是一旦往B生产消息时A挂了，client是不会收到任何错误信息的并可以继续发送，而实际上消息是被丢弃了。一旦此时client挂了后在连接B会报节点A不存在而失败。在B读也是类似的，在client批量取到的数据读完之前是不会感知A有没有挂掉，等到读取下一批数据时一旦A挂掉会报错。 所以这种集群方法的特点是：

  1. 高吞吐量

  2. 非高可用

要实现RabbitMQ的高可用都是要在普通集群的基础上，所以就安心的先安装普通集群吧！

• RabbitMQ的集群方式有多种.我们选择相对较简单的一种Manually with rabbitmqctl

  A RabbitMQ cluster can formed in a number of ways:

  ​

  • Declaratively by listing cluster nodes in config file

  • Declaratively using DNS-based discovery

  • Declaratively using AWS (EC2) instance discovery (via a plugin)

  • Declaratively using Kubernetes discovery (via a plugin)

  • Declaratively using Consul-based discovery (via a plugin)

  • Declaratively using etcd-based discovery (via a plugin)

  • Manually with rabbitmqctl

在集群搭建前首先需要在两台或者两台机器以上搭建RabbitMQ，保证每台机器的RabbitMQ都可以运行!

• 修改HOST文件，Centos的Host文件在/etc/hosts。当然你也可以选择不修改Host文件，具体操作步骤请参见http://erlang.org/doc/apps/erts/inet_cfg.html

    
    vi /etc/hostsvi /etc/hosts

  添加每个节点的ip和主机名(在这几台机器分别添加)

    
    eg: 
    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    ​
    RabbitMQ节点一的ip  RabbitMQ节点一的主机name
    RabbitMQ节点二的ip  RabbitMQ节点二的主机name
    RabbitMQ节点N的ip  RabbitMQ节点N的主机name
    ​eg: 
    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    ​
    RabbitMQ节点一的ip  RabbitMQ节点一的主机name
    RabbitMQ节点二的ip  RabbitMQ节点二的主机name
    RabbitMQ节点N的ip  RabbitMQ节点N的主机name
    ​

RabbitMQ nodes address each other using domain names, either short or fully-qualified (FQDNs). Therefore hostnames of all cluster members must be resolvable from all cluster nodes, as well as machines on which command line tools such as rabbitmqctl might be used.

RabbitMQ节点使用域名（简称或完全限定（FQDN））相互地址。因此，所有群集成员的主机名必须可以从所有群集节点以及 可能使用命令行工具（如rabbitmqctl）的机器解析。

Hostname Changes

RabbitMQ nodes use hostnames to communicate with each other. Therefore, all node names must be able to resolve names of all cluster peers. This is also true for tools such as rabbitmqctl.

RabbitMQ节点使用主机名进行通信。因此，所有节点名必须能够解析所有集群对等点的名称。对于rabbitmqctl等工具来说也是如此。

In addition to that, by default RabbitMQ names the database directory using the current hostname of the system. If the hostname changes, a new empty database is created. To avoid data loss it's crucial to set up a fixed and resolvable hostname. Whenever the hostname changes you should restart RabbitMQ！

除此之外，在默认情况下，RabbitMQ使用系统的当前主机名来命名数据库目录。如果主机名发生变化，就会创建一个新的空数据库。为了避免数据丢失，设置一个固定的、可解析的主机名是至关重要的。每当主机名更改时，应该重新启动RabbitMQ！

 

• 使用第一台机器的Erlang cookie。他的位置一般在/etc/lib/rabbitmq/.erlang.chooking

  修改Chooking文件时，此文件为隐藏文件，可使用 ll -a命令。

  注意:此文件的权限应为 600 使用chmod 600 修改文件的权限，修改文件所在用户群组的权限都为rabbitmq

  How Nodes (and CLI tools) Authenticate to Each Other: the Erlang Cookie

  RabbitMQ nodes and CLI tools (e.g. rabbitmqctl) use a cookie to determine whether they are allowed to communicate with each other. For two nodes to be able to communicate they must have the same shared secret called the Erlang cookie. The cookie is just a string of alphanumeric characters up to 255 characters in size. It is usually stored in a local file. The file must be only accessible to the owner (e.g. have UNIX permissions of 600 or similar). Every cluster node must have the same cookie.

  ​

  RabbitMQ节点和CLI工具（如rabbitmqctl）使用cookie来确定它们是否被允许相互通信。对于两个节点来说，它们必须有相同的共享密钥，称为Erlang cookie。cookie只是一串数字字符，大小为255个字符。它通常存储在一个本地文件中。该文件必须只有拥有者才能访问（例如，拥有600个或类似的UNIX权限）。每个集群节点必须拥有相同的cookie。

• 停止实例 rabbitmqctl stop_app

• 重置 rabbitmqctl reset

• rabbitmqctl join_cluster rabbit@node1这里为RabbitMQ其他节点的节点名@主机名

  NOTE:这里涉及到一个 jion_cluster的命令，请注意查看下文的集群说明,节点启动默认节点名是Rabbit 当然你也可以修改，自己参考官方手册吧

命令可参考http://www.rabbitmq.com/rabbitmqctl.8.html#Cluster_Management

集群配置可在 RabbitMQ 的web管理端看到

  
  登陆WEB-UI(也就是可视化操作页面)
  Overview> Nodes 可以看到有两个节点登陆WEB-UI(也就是可视化操作页面)
  Overview> Nodes 可以看到有两个节点

集群搭建(单机多实例)

http://www.rabbitmq.com/clustering.html#single-machine 官方说明文档

ps： 下面命令中node1 代表本机的hostname

1. 节点一 启动

RABBITMQ_NODE_PORT=5672 RABBITMQ_NODENAME=rabbit@node1 rabbitmq-server

1. 节点二 启动

RABBITMQ_NODE_PORT=5673 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15673}] -rabbitmq_stomp tcp_listeners [61614] -rabbitmq_mqtt tcp_listeners [1884]" RABBITMQ_NODENAME=rabbit1@node1 rabbitmq-server -detached

想要增加更多节点，需设置端口不冲突！

1. 将节点二 加入节点一

rabbitmqctl -n rabbit1@node1 join_cluster rabbit@node1

然后登陆管理扩展查看Node的信息就可以看到集群配置成功了！.

集群说明

RabbitMQ 的集群节点包括内存节点、磁盘节点。顾名思义内存节点就是将所有数据放在内存，磁盘节点将数据放在磁盘。不过，如前文所述，如果在投递消息时，打开了消息的持久化，那即使是内存节点，数据还是安全的放在磁盘。

　　一个 RabbitMQ 集群中可以共享 user、vhost、queue、exchange 等，所有的数据和状态都是必须在所有节点上复制的，一个例外是那些当前只属于创建它的节点的消息队列，尽管它们可见且可被所有节点读取。 RabbitMQ 节点可以动态地加入到集群中，一个节点它可以加入到集群中，也可以从集群环集群进行一个基本的负载均衡。

Disk and RAM Nodes

A node can be a disk node or a RAM node. (Note: disk and disc are used interchangeably). RAM nodes store internal database tables in RAM. This does not include messages, message store indices, queue indices and other node state.

In well over 90% of cases you want all your nodes to be disk nodes; RAM nodes are a special case that can be used to improve the performance clusters with high queue, exchange, or binding churn. RAM nodes do not provide meaningfully higher message rates. When in doubt, use disk nodes only.

Since RAM nodes store internal database tables in RAM only, they must sync them from a peer node on startup. This means that a cluster must contain at least one disk node. It is therefore not possible to manually remove the last remaining disk node in a cluster.

由于RAM节点仅将内部数据库表存储在RAM中，因此它们必须在启动时从对等节点同步它们。这意味着群集必须至少包含一个磁盘节点。因此无法手动删除集群中剩余的最后一个磁盘节点。

设置集群中的节点是否为磁盘或者内存请参考RabbitMQ官网 join_cluster命令http://www.rabbitmq.com/rabbitmqctl.8.html#Cluster_Management

• 本文引用网站

  • http://www.rabbitmq.com/

  • https://www.cnblogs.com/dreamroute/p/6251180.html

  • https://blog.csdn.net/qq_35246620/article/details/72473098

集群操作命令

• 将node2 加入 node1

  eg： rabbitmqctl join_cluster rabbit@node2 node2将作为Disk 节点加入

  rabbitmqctl join_cluster rabbit@node2 --ram node2将作为RAM node加入

Cluster nodes can be of two types: disc or RAM. Disc nodes replicate data in RAM and on disc, thus providing redundancy in the event of node failure and recovery from global events such as power failure across all nodes. RAM nodes replicate data in RAM only (with the exception of queue contents, which can reside on disc if the queue is persistent or too big to fit in memory) and are mainly used for scalability. RAM nodes are more performant only when managing resources (e.g. adding/removing queues, exchanges, or bindings). A cluster must always have at least one disc node, and usually should have more than one.

集群节点可以有两种类型：磁盘或RAM。磁盘节点在RAM和磁盘上复制数据，从而在节点故障时提供冗余，并从全局事件中恢复，比如跨所有节点的电源故障。RAM节点只在RAM中复制数据（除了队列内容之外，如果队列是持久的或太大而不能装入内存的话），它可以驻留在磁盘上，并且主要用于可伸缩性。RAM节点只有在管理资源时才更具性能（例如添加/删除队列、交换或绑定）。集群必须始终至少有一个磁盘节点，并且通常应该有多个磁盘节点。

要离开集群，请重置节点。您也可以使用forget_cluster_node命令远程删除节点 。

• 显示按节点类型分组的所有节点以及当前正在运行的节点

  rabbitmqctl cluster_status

• 更改群集节点的类型。

  rabbitmqctl change_cluster_node_type disc

The type must be one of the following:

• disc

• ram

The node must be stopped for this operation to succeed, and when turning a node into a RAM node the node must not be the only disc node in the cluster.

必须停止节点才能使此操作成功，并且在将节点转换为RAM节点时，该节点不能是群集中唯一的磁盘节点。

• 远程删除群集节点

  rabbitmqctl -n hare mcnulty forget_cluster_node rabbit@stringer

forget_cluster_node [--offline]

• --offline

  Enables node removal from an offline node. This is only useful in the situation where all the nodes are offline and the last node to go down cannot be brought online, thus preventing the whole cluster from starting. It should not be used in any other circumstances since it can lead to inconsistencies.

  从脱机节点启用节点删除。这仅在所有节点脱机并且最后一个关闭的节点不能联机的情况下才有用，从而阻止整个群集启动。它不应该用于任何其他情况，因为它可能导致不一致。

Removes a cluster node remotely. The node that is being removed must be offline, while the node we are removing from must be online, except when using the --offline flag.

远程删除群集节点。正在删除的节点必须处于脱机状态，而我们从中删除的节点必须处于联机状态，除非使用--offline标志。

When using the --offline flag , rabbitmqctl will not attempt to connect to a node as normal; instead it will temporarily become the node in order to make the change. This is useful if the node cannot be started normally. In this case the node will become the canonical source for cluster metadata (e.g. which queues exist), even if it was not before. Therefore you should use this command on the latest node to shut down if at all possible.

当使用--offline标志时， rabbitmqctl不会像往常一样尝试连接到节点; 相反，它将暂时成为节点以进行更改。如果节点无法正常启动，这很有用。在这种情况下，节点将成为集群元数据的规范来源（例如，哪些队列存在），即使它不是以前。因此，如果可能的话，您应该在最新的节点上使用此命令来关闭。

其他命令请参考Cluster Management