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 普通模式
- 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 的区别和联系
- 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 节点都可以看到所有的队列 |