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 | 队列镜像到集群内指定数量的节点。如果集群内节点数少于此值，
队列将会镜像到所有节点。如果大于此值，而且一个包含镜像的节
点停止，则新的镜像不会再其他节点创建。 | | nodes | nodename | 队列镜像到指定节点，指定的节点不在集群中不会报错。当队列申明时，
如果指定的节点不在线，则队列会被创建在客户端所链接的节点上。 |- 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 的区别和联系
- https://www.rabbitmq.com/distributed.html | 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 节点都可以看到所有的队列 |
若有收获，就点个赞吧
0 人点赞
