第五章、RabbitMQ管理、集群 笔记
一、管理RabbitMQ
******1、**日志一般存放位置
Linux********上：
/var/log/rabbitmq/rabbit@XXX.log
/var/log/rabbitmq/rabbit@XXX-sasl.log
Windows********上：
C:\Users\Administrator\AppData\Roaming\RabbitMQ\log\ rabbit@XXX.log
C:\Users\Administrator\AppData\Roaming\RabbitMQ\log\ rabbit@ XXX-sasl.log
第一个是用于追踪MQ启动和连接日志的信息收集模块；第二个则是saal这个工具库专门用于存储与Erlang相关的各种详细分析结果。
******2、**管理虚拟主机
rabbitmqctl add_vhost [vhost_name]
rabbitmqctl list_vhosts
******3、**启动和关闭rabbitmq
****1）****以服务方式
service rabbitmq-server stop
service rabbitmq-server start
service rabbitmq-server status
****2）****以应用程序方式
rabbitmq-server会启动Erlang节点和Rabbitmq应用
rabbitmqctl stop会关闭Erlang节点和Rabbitmq应用
rabbitmqctl status可以检查消息节点是否正常
RabbitMQ配置文件应放置于/etc/rabbitmq目录中，默认情况下无需自行创建配置文件。如果有必要，则可以根据需求自行修改rabbitmq.config参数设置。
3）单独关闭RabbitMQ********应用
rabbitmqctl stop_app 关闭Rabbitmq应用
rabbitmqctl start_app 启动Rabbitmq应用
******4、**用户管理
rabbitmqctl add_user [username] [pwd]
rabbitmqctl delete_user [username]
rabbitmqctl change_password Username Newpassword
rabbitmqctl list_users
******5、**用户权限控制
guest用户****：****
default user guest拥有default virtual host '/'的所有权限，并且仅限于localhost能够访问RabbitMQ及其插件。为了便于管理，请考虑删除或修改密码设置。在配置文件中设置loopback_users可以在一定程度上解除该用户的本地访问限制
用户权限****：****
用户仅限于对可访问其 virtual hosts 中的资源执行操作。这些资源包括 virtual hosts 中的 exchanges 和 queues 等。操作涵盖配置、写入以及读取这三个方面。配置权限允许创建新项目，并删除现有项目；同时支持修改现有项目的属性。发送消息的能力属于 write 权限；接收消息的能力属于 read 权限。例如：
exchange和queue的定义与删除分别需要：exchange和queue上的配置权限
queue的bind与unbind 需要：queue写权限，exchange的读权限。
发消息(publish)需exchange的写权限。
获取或清除(get、consume、purge)消息需queue的读权限。
对何种资源具有配置、写、读的权限通过正则表达式来匹配，具体命令如下：
rabbitmqctl set_permissions [-p
如用户chj在虚拟主机logHost上的所有权限：
rabbitmqctl set_permissions –p logHost chj '.' '.' '.*'
******6、**设置用户角色：
rabbitmqctl set_user_tags指定用户名和角色名为User TagUser(管理员、监控员、政策制定者、管理者、无)
RabbitMQ中的用户角色类型包括none、管理层、政策制定者、监控人员和管理员。
None****：**** 不能访问management plugin，通常就是普通的生产者和消费者。
Management****：**** 普通的生产者和消费者加：
列出自己可以通过AMQP登入的virtual hosts；
查看自己的virtual hosts中的 queues, exchanges和bindings；
查看和关闭自己的channels和connections；
访问本机virtual hosts的总体数据统计，并包括了所有通过这些虚拟主机参与的各种活动。
Policymaker****：**** management可以做的任何事加：
查看、创建和删除自己的virtual hosts所属的policies和parameters。
Monitoring****：**** management可以做的任何事加：
列出所有virtual hosts，包括他们不能登录的virtual hosts；
查看其他用户的connections和channels；
查看节点级别的数据如clustering和memory使用情况；
查看真正的关于所有virtual hosts的全局的统计信息administrator；
policymaker和monitoring可以做的任何事加:
创建和删除virtual hosts；
查看、创建和删除users；
查看创建和删除permissions；
关闭其他用户的connections。
******7、**查看
查看队列：
rabbitmqctl list_queues
查看交换器：
rabbitmqctl list_exchanges
查看绑定：
rabbitmqctl list_bindings：
如果命令不太懂，可以直接rabbitmqctl命令进行查询
******二、**RabbitMQ集群
******1、**RabbitMQ內建集群
******1.1、**內建集群的设计目标
1、允许消费者和生产者在节点崩溃的情况下继续运行；
2、通过添加节点线性扩展消息通信的吞吐量。
******1.2、**可以保证消息的万无一失吗？
无法在某个节点发生崩溃的情况下确保对应的队列消息也会随之消失。rabbitmq默认情况下不会复制该队列的消息到整个集群中。
******2、**集群中的队列和交换器
******2.1、**队列
在集群中各队列的信息仅限于其所有者节点来存储全部相关信息；而其余各节点仅了解辅助数据以及带有指向所有者节点的指针；当某个设备发生故障时，则会导致该设备相关的队列及其绑定信息丢失。
为什么集群不复制队列内容和状态到所有节点？
1）存储空间。
2）性能，在以下情况下：当消息必须复制到集群中的每一个节点时，必然会产生网络开销；存储过程还必须进行磁盘操作。
因此，在接收到非自己所属的队列消息时，这些节点会将消息传递给对应队列的所有管理节点。
******2.2、**交换器
它涉及的是该交换器名称与队列之间的绑定关系
******2.3、**元数据
队列元数据：队列名称和属性（是否可持久化，是否自动删除）
交换器元数据：交换器名称、类型和属性
绑定元数据：交换器和队列的绑定列表
vhost元数据：vhost内的相关属性，如安全属性等等
******2.4、**集群中的节点
如果是内存类型的网络设备或者是磁盘类型的设备？也就是说，在存储这些关键信息的时候它们会选择不同的存储位置？单一的网络设备必定属于磁盘类型而集群架构中可能会包含内存类型的设备出于性能优化的需求所有的其他网络设备都是以磁盘类型为主任何集群系统都会保证当声明队列和交换器等时RabbitMQ必须将相关数据复制并存储在每个参与处理该队列的所有服务器上才能完整记录操作过程。
从设计角度来看,RabbitMQ最低要求集群中仅需配备一个磁盘节点。然而,为了提升系统的容错能力,建议每个集群配置至少两个独立的磁盘节点。在单个磁盘冗余设计下,当该唯一的存储设备发生故障时,系统仍能正常运转;然而,任何操作性的变更都无法完成——例如新增或移除队列/交换机/集群成员。
******3、**构建我们自己的集群
******3.1、**集群常用命令
rabbitmqctl join_cluster [rabbit@node1]将节点加入集群
使用rabbitmqctl命令获取集群运行状态；然而实际上，在某些情况下（例如），调用reset命令会被认为属于集群管理的一部分；其主要作用是将单个node从当前环境中完全重置回空的状态；包括但不限于用户的登录信息、虚拟主机配置参数以及所有持久化的消息内容；通过调用该命令，在正常操作流程中会迫使单个node从当前的环境中脱离出去。
******3.2、**集群下的注意事项
元数据变更时，我们了解这些消息必须记录在磁盘节点上。当集群中的一个磁盘节点退出时，在所有剩余的磁盘节点中都需要记录这一信息。如果不使用reset命令使得一个磁盘节点退出，则会导致集群系统错误地认为该设备出现故障并持续等待其恢复才能允许新成员加入系统。因此，在某些极端情况下（例如一个被强行从集群中移除的磁盘分区），可能导致整个系统的不可变性问题（不仅限于无法添加新成员和无法重新配置队列交换器等操作）。
****3.3、本机集群(建议不要随意尝试)：
RABBITMQ_NODE_PORT=5672 RABBITMQ_NODENAME=rabbit rabbitmq-server -detached
RABBITMQ_NODE_PORT=5673 RABBITMQ_NODENAME=rabbit_1 rabbitmq-server -detached
RABBITMQ_NODE_PORT=5674 RABBITMQ_NODENAME=rabbit_2 rabbitmq-server -detached
rabbitmqctl -n rabbit_1@centosvm stop_app
rabbitmqctl -n rabbit_1@centosvm reset
rabbitmqctl -n rabbit_1@centosvm join_cluster rabbit@centosvm
rabbitmqctl -n rabbit_1@centosvm start_app
rabbitmqctl cluster_status
rabbitmqctl -n rabbit_2@centosvm stop_app
rabbitmqctl -n rabbit_2@centosvm reset
rabbitmqctl -n rabbit_2@centosvm join_cluster rabbit@centosvm --ram
rabbitmqctl -n rabbit_2@centosvm start_app
使用rabbitmqctl命令获取cluster_status信息时，请确保在防火墙设置里开放该端口以允许虚拟机内的MQ相关配置连接。
firewall-cmd --add-port=5673/tcp --permanent
firewall-cmd --add-port=5674/tcp --permanent
rabbitmqctl add_user mq mq
rabbitmqctl set_permissions mq ".""."".*"
rabbitmqctl set_user_tags mq administrator
rabbitmq-plugins -n rabbit_1@centosvmenable rabbitmq_management
******3.4、**多机下的集群
Rabbitmq集群对延迟非常敏感，只能在本地局域网内使用。
1、修改 /etc/hosts
192.168.1.1 node1
192.168.1.2 node2
192.168.1.3 node3
Erlang Cookie 文件位于 /var/lib/rabbitmq/.erlang.cookie。
为了实现目标，在 node1 服务器上复制该 Erlang Cookie 文件至 node2 和 node3 服务器。
由于该文件当前的安全属性配置为 400，默认读取权限仅限于 RabbitMQ 管理员。
因此必须首先将 node2 和 node3 服务器上的该 Erlang Cookie 文件的安全属性调整为 755（即 rw-rw-r--），以便于其他节点执行读取操作。
完成操作后需重新设置相应的安全权限，并归还给原属用户或组别。
3、运行各节点
4、在node2、node3上分别运行
[root@node2 ~]# rabbitmqctl stop_app
[root@node2 ~]./rabbitmqctl reset
[root@node2 ~]# rabbitmqctl join_cluster rabbit@node1[root@node2 ~]# rabbitmqctl start_app
rabbitmqctl cluster_status
内存节点则是：rabbitmqctl join_cluster rabbit@node1 --ram
******3.5、**移除集群中的节点
[root@node2 ~]# rabbitmqctl stop_app
[root@node2 ~]./rabbitmqctl reset
[root@node2 ~]# rabbitmqctl start_app
******三、**RabbitMQ集群高可用
******1、**镜像队列
******1.1、**什么是镜像队列
若RabbitMQ集群由多台broker节点组成，则就服务整体可用性而言该集群对单一节点故障具有容错能力；但也需要注意的是尽管在单一节点故障情况下交换机和绑定机制能够正常运行然而队列及其携带的消息在这种情况却无法得到有效处理因为队列及其相关数据仅存放在单一节点中因此当某个节点故障时会导致相应的队列无法访问
采用RabbitMQ实现镜像队列机制后将队列实例分配至集群中的其他节点完成映射操作在此方案下当集群中的某台设备出现故障时系统能够自动地切换至其他镜像队列以维持服务可用性
除了tx外的所有操作都只会将数据发送至Master节点，并由其广播至Slave节点完成处理流程。由此可见，在实际运行中镜像队列中的消费操作最终都会映射至Master节点的操作。 RabbitMQ支持的镜像队列机制包括Publisher Confirmation和Transaction两种模式。对于采用Transaction模式的镜像队列而言,只有当所有参与方均完成Transaction提交流程后,客户端才会收到txCommitOk的状态反馈消息。同样地,在Publisher Confirmation模式下,只有当当前消息被全部Mirror实例接收确认后,才会向Publisher发起Current Message Confirmation的操作请求
******1.2、**镜像队列的配置
代码****：****
Map<String, Object> args = new HashMap<String, Object>();
args.put("x-ha-policy", "all");
当配置队列时，使用 channel.queueDeclare(queueName, 无效参数, 无效参数, 无效参数, args);
控制台****：****
镜像队列的配置通过添加policy完成，policy添加的命令为：
rabbitmqctl set_policy [-p Vhost] Name Pattern Definition [Priority]
-p Vhost：可选参数，针对指定vhost下的queue进行设置；
Name: policy的名称；
Pattern: queue的匹配模式(正则表达式)；
Definition：镜像定义，包括三个部分ha-mode, ha-params, ha-sync-mode；
ha-mode:指明镜像队列的模式，有效值为all/exactly/nodes；
all：表示在集群中所有的节点上进行镜像；
exactly：定义其在对应节点数量上的镜像操作；其中节点的数量由ha-params参数确定。
mirror nodes：在特定节点上实施镜像操作，并由ha-params参数配置其相关属性；该模式所需的参数配置存储于ha-params字段中
ha-sync-mode：进行队列中消息的同步方式，有效值为automatic和manual；
priority：可选参数，policy的优先级；
例如将所有以'queue_'命名的队列镜像复制同时在集群的两个节点上部署配置命令如下policy的设置命令为：
rabbitmqctl set_policy ha-queue-two"^queue_"
'{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}'
在Windows系统中设置为使用双引号代替单引号以避免潜在的问题，并确保所有相关消息队列都被正确配置
补充：
可通过如下命令确认哪些salve在同步：
rabbitmqctl list_queues name slave_pids synchronised_slave_pids
手动同步queue：
rabbitmqctl sync_queue name
取消queue同步：
rabbitmqctl cancel_sync_queue name
******2、**使用HAProxy
节点配置策略中涉及的处理节点选择、服务器故障检测以及负载均衡策略的实施均可采用HAProxy工具进行配置与管理。在具体的操作流程中，请按照附录中的《安装HAProxy》详细指导文档完成相关设置工作，并将完整配置文件保存为文件名为"安装HAProxy.txt"的本地磁盘文件。
2.1**、**下载并解压
cd /usr/local/src/
Obtain the package version 1.7.9.tar.gz from the Fedora Project's repository at http://pkgs.fedoraproject.org/repo/pkgs/haproxy/haproxy-1.7.9.tar.gz.
tar zxvf haproxy-1.7.9.tar.gz
2.2、安装
cd haproxy-1.7.9
uname -r
3.10.0-514.el7.x86_64
make TARGET=linux310 ARCH=x86_64 PREFIX=/usr/local/haproxy
make install PREFIX=/usr/local/haproxy
******2.3、**参数说明：
基于用户提供的文本进行同义改写
ARCH=x86_64，系统位数；
PREFIX=/usr/local/haprpxy #/usr/local/haprpxy，为haprpxy安装路径。
2.4、添加配置文件
cd /usr/local/haproxy
mkdir conf
cd conf/
vim haproxy.cfg
global
log 127.0.0.1 local0
maxconn 1000
daemon
defaults
log global
mode http
option httplog
option dontlognull
retries 3
timeout connect 5000
timeout client 50000
timeout server 50000
listen admin_stats
bind 0.0.0.0:1080
mode http
option httplog
maxconn 10
stats refresh 30s
stats uri /stats
stats realm XingCloud\ Haproxy
stats auth admin:admin
stats auth Frank:Frank
stats hide-version
stats admin if TRUE
listen rabbitmq_cluster
bind 0.0.0.0:5670
mode tcp
balance roundrobin
server rabbit01 127.0.0.1:5672 check inter 5000 rise 2 fall 3
server rabbit02 node2:5672 check inter 5000 rise 2 fall 3
2.5、启动haproxy
/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg
验证lsof -i :1080
2.6、访问统计页面
3、RabbitMQ的Web控制台
运行rabbitmq-plugins enable rabbitmq_management
重启RabbitMQ
在浏览中打开 http://localhost:15672