1. 常用命令
rabbitmqctl status
- 查看节点状态。
rabbitmqctl stop [pid_file]
- 停止运行 RabbitMQ 的 Erlang 虚拟机和 RabbitMQ 服务应用。
- 如果指定了 pid_file，还需要等待指定进程的结束。pid_file 是通过调用 rabbitmq-server 命令启动 RabbitMQ 服务时创建的，默认情况下存放于 Mnesia 目录中。
- 如果使用 rabbitmq-server -detach 这个带有 -detach 后缀的命令来启动 RabbitMQ 服务则不会生成 pid file 文件。
rabbitmqctl stop_app
- 停止 RabbitMQ 服务应用，但是 Erlang 虚拟机还是处于运行状态。
- 此命令的执行优于其他管理操作（这些管理操作需要先停止 RabbitMQ 应用），比如 rabbitmqctl reset。
rabbitmqctl start_app
- 启动 RabbitMQ 应用。此命令典型的用途是在执行了其他管理操作之后，重新启动之前停止的 RabbitMQ 应用，比如 rabbitmqctl reset。
rabbitmqctl reset
- 将 RabbitMQ 节点重置还原到最初状态。
- 包括从原来所在的集群中删除此节点，从管理数据库中删除所有的配置数据，如已配置的用户、vhost 等，以及删除所有的持久化消息。
- 执行 rabbitmqctl reset 命令前必须停止 RabbitMQ 应用(比如先执行 rabbitmqctl stop_app)
rabbitmqctl force_reset
- 强制将 RabbitMQ 节点重置还原到最初状态。此命令不论当前管理数据库的状态和集群配置是什么，都会无条件地重置节点，只能在数据库或集群配置已损坏的情况下使用。
2. 集群管理常用命令
rabbitmqctl [-n nodename] join_cluster {cluster_node} [--ram]
- 将节点加入指定集群中。在这个命令执行前需要停止 RabbitMQ 应用并重置节点。
- -n nodename：指定需要操作的目标节点，例如：rabbit@node1。
- cluster_node：需要加入的集群节点名，格式同上。
- --ram：集群节点类型，有两种类型：ram/disc，默认为 disc
- ram：内存节点，所有的元数据都存储在内存中。
- disc：磁盘节点，所有的元数据都存储在磁盘中。
rabbitmqctl cluster_status
- 查看集群状态。
rabbitmqctl change_cluster_node_type {disc|ram}
- 修改集群节点的类型，使用此命令前要停止 RabbitMQ 应用。
rabbitmqctl forget_cluster_node [--offline]
- 将节点从集群中删除，允许离线执行。
rabbitmqctl update_cluster_nodes {clusternode}
- 在集群中的节点应用启动前咨询 clusternode 节点的最新信息，并更新相应的集群信息。这个和 join_cluster 不同，它不加入集群。
3. RabbitMQ 高可用集群方案
1. Cluster 模式
- 分为两种：普通模式、镜像模式
-
Cluster 普通模式
-
元数据包含以下内容：
- 队列元数据：队列的名称及属性。
- 交换器：交换器的名称及属性。
- 绑定关系元数据：交换器与队列或者交换器与交换器。
- vhost 元数据：为 vhost 内的队列、交换器和绑定提供命名空间及安全属性之间的绑定关系。
-
Cluster 多机多节点部署
- 多机多节点是指在每台机器中部署一个 RabbitMQ 服务节点，进而由多台机器组成一个 RabbitMQ 集群。
-
-
Cluster 镜像模式
-
镜像模式的集群是在普通模式的基础上，通过 policy 实现，使用镜像模式可以实现 RabbitMQ 的高可用方案。
-
配置项
-
Name：policy 的名称。
-
Pattern：匹配表达式。
-
Apply to：规则应用到哪个目标。
-
Priority：优先级。
-
Definition：规则的定义，对于镜像队列的配置来说，只需要包含3个部分：ha-mode、ha-params 和 ha-sync-mode。
ha-mode ha-params 说明 all (empty) 队列镜像到集群类所有节点 exactly count 队列镜像到集群内指定数量的节点。如果集群内节点数少于此值，<br/>队列将会镜像到所有节点。如果大于此值，而且一个包含镜像的节<br/>点停止，则新的镜像不会再其他节点创建。 nodes nodename 队列镜像到指定节点，指定的节点不在集群中不会报错。当队列申明时，<br/>如果指定的节点不在线，则队列会被创建在客户端所链接的节点上。 - ha-sync-mode：队列中消息的同步方式，有效值为 automatic 和 manual，默认是 automatic。
-
-
2. Federation 插件
-
Federation 插件的设计目标是使 RabbitMQ 在不同的 Broker 节点之间进行消息传递而无需建立集群。该功能在以下场景非常有用：
- 各个节点运行在不同版本的 Erlang 和 RabbitMQ 上。
- 网络环境不稳定，比如广域网当中。
3. Shovel 插件
-
Shovel 和 Federation 具备的数据转发功能类似。
-
Shovel 能够可靠、持续地从一个 Broker 中的队列（作为源端，即 source）拉取数据并转发至另一个 Broker 中的交换器（作为目的端，即 destination）。
-
主要优势：
- 松耦合
- 支持广域网
- 高度定制。
4. Federation/Shovel 与 Cluster 的区别和联系
| Federation/Shovel | Cluster |
|---|---|
| 各个 Broker 节点之间逻辑分离 | 一个集群形成单一逻辑 Broker。 |
| 各个 Broker 节点之间可以运行不同版本的 Erlang 和 RabbitMQ | 各个 Broker 节点之间必须运行相同版本的 Erlang 和 RabbitMQ |
| 各个 Broker 节点之间可以在广域网中相连，当然必须要授予适当的用户和权限 | 各个 Broker 节点之间必须在可信赖的局域网中相连，通过 Erlang 内部节点传递消息，节点间需要有相同的 Erlang cookie |
| 各个 Broker 节点之间能以任何拓扑逻辑部署，连接可以是单向的或者是双向的 | 所有 Broker 节点都双向连接所有其他节点 |
| 从 CAP 理论中强调可用性和分区容错性，即 AP | 从 CAP 理论中强调一致性和分区容错性，即 CP |
| 一个 Broker 中的交换器可以是 Federation 生成的或者是本地的 | 集群中所有 Broker 节点中的交换器都是一样的，要么全有要么全无 |
| 客户端能看到它连接的 Broker 节点上的队列 | 客户端连接到集群中的任何 Broker 节点都可以看到所有的队列 |
来源：oschina
链接：https://my.oschina.net/shadowolf/blog/4334076