时间：   |   分类：     | 字数： 6954 字 | 阅读约： 14分钟 | 阅读次数：

集群与运维

1. 集群方案原理

常见方式:

主备模式, 主从模式, 主主模式, 分片集群, 异地多活

常见负载均衡算法:

随机, 轮询, 加权轮询, 最少活跃, 一致性hash…..

集群中的经典问题:

脑裂(可以通过协调器选举算法,仲裁节点等方式来解决), 网络分区, 致性, 可用性(cap)……….

相关节点的技术和工具：LVS、HAProxy、Nginx、KeepAlived、Heartbeat、DRBD、Corosync、Pacemaker、MMM/MHA、Galera

RabiitMq分布式架构模式:

  • 主备模式

    也叫Warren（兔子窝）模式，同一时刻只有一个节点在工作（备份节点不能读写），当主节点发生故障后会将请求切换到备份节点上（主恢复后成为备份节点）。需要借助HAProxy之类的（VIP模式）负载均衡器来做健康检查和主备切换，底层需要借助共享存储（如SAN设备）。

    这不是RabbitMQ官方或者开源社区推荐方案，适用于访问压力不是特别大但是又有高可用架构需求（故障切换）的中小规模的系统来使用。首先有一个节点闲置，本身就是资源浪费，其次共享存储往往需要借助硬件存储，或者分布式文件系统

  • shovel铲子模式

    Shovel是一个插件，用于实现跨机房数据复制，或者数据迁移，故障转移与恢复等。

    如下图，用户下单的消费先是投递在Goleta Broker实例中，当Goleta实例达到触发条件后（例如：消息堆积数达到阈值）会将消息放到Goleta实例的backup_orders备份队列中，并通过Shovel插件从Goleta的backup_orders队列中将消息拉取到Carpinteria实例存储。

    使用Shovel插件后，模型变成了近端同步确认，远端异步确认的方式。此模式支持WAN传输，并且broker实例的RabbitMQ、Erlang版本不要求完全一致。Shovel的配置分静态模式（修改RabbitMQ配置）和动态模式（在控制台直接部署，重启后失效）

  • rabbitmq集群

    RabbitMQ集群允许消费者和生产者在RabbitMQ单个节点崩溃的情况下继续运行，并可以通过添加更多的节点来线性扩展消息通信的吞吐量。当失去一个RabbitMQ节点时，客户端能够重新连接到集群中的任何其他节点并继续生产和消费。

    RabbitMQ集群中的所有节点都会备份所有的元数据信息，包括：

    1. 队列元数据：队列的名称及属性；
2. 交换器：交换器的名称及属性；
3. 绑定关系元数据：交换器与队列或者交换器与交换器之间的绑定关系；
4. vhost元数据：为vhost内的队列、交换器和绑定提供命名空间及安全属性。

    基于存储空间和性能的考虑，RabbitMQ集群中的各节点存储的消息是不同的（有点儿类似分片集群，各节点数据并不是全量对等的），各节点之间同步备份的仅仅是上述元数据以及QueueOwner（队列所有者，就是实际创建Queue并保存消息数据的节点）的指针。当集群中某个节点崩溃后，该节点的队列进程和关联的绑定都会消失，关联的消费者也会丢失订阅信息，节点恢复后（前提是消息有持久化）消息可以重新被消费。虽然消息本身也会持久化，但如果节点磁盘存储设备发生故障那同样会导致消息丢失。

    总的来说，该集群模式只能保证集群中的某个Node挂掉后应用程序还可以切换到其他Node上继续地发送和消费消息，但并无法保证原有的消息不丢失，所以并不是一个真正意义的高可用集群

    这是RabbitMQ内置的集群模式，Erlang语言天生具备分布式特性，所以不需要借助类似Zookeeper之类的组件来实现集群（集群节点间使用cookie来进行通信验证，所有节点都必须使用相同的 .erlang.cookie 文件内容），不同节点的Erlang、RabbitMQ版本必须一致。

  • 镜像队列模式

    前面我们讲了，RabbitMQ内置的集群模式有丢失消息的风险，“镜像队列”可以看成是对内置默认集群模式的一种高可用架构的补充。可以将队列镜像（同步）到集群中的其他broker上，相当于是多副本冗余。如果集群中的一个节点失效，队列能自动地切换到集群中的另一个镜像节点上以保证服务的可用性，而且消息不丢失。

    在RabbitMQ镜像队列中所谓的master和slave都仅仅是针对某个queue而言的，而不是node。一个queue第一次创建所在的节点是它的master节点，其他节点为slave节点。如果master由于某种原因失效，最先加入的slave会被提升为新的master。

    无论客户端请求到达master还是slave，最终数据都是从master节点获取。当请求到达master节点时，master节点直接将消息返回给client，同时master节点会通过GM（Guaranteed Multicast）协议将queue的最新状态广播到slave节点。GM保证了广播消息的原子性，即要么都更新要么都不更新。当请求到达slave节点时，slave节点需要将请求先重定向到master节点，master节点将消息返回给client，同时master节点会通过GM协议将queue的最新状态广播到slave节点。

    很多人可能就会疑惑，这样设计太傻叉了，slave完全是闲置的啊！干嘛不学习MySQL主从复制，起码可以搞个读写分离啊！其实业界很多HA架构实践中冗余资源都是闲置的。前面我们讲了RabbitMQ镜像队列中的master、slave是Queue维度而并非Node维度，所以我们可以交叉减少资源限制，如下图所示：

  • Federation联邦模式

    Federation和Shovel类似，也是一个实现跨集群、节点消息同步的插件。支持联邦交换器、联邦队列（作用在不同级别）。

    Federation插件允许你配置一个exchanges federation或者queues federation。

    一个exchange/queues federation允许你从一个或者多个upstream接收信息，就是远程的exchange/queues。

    无论是Federation还是Shovel都只是解决消息数据传输的问题（当然插件自身可能会一些应用层的优化），跨机房跨城市的这种网络延迟问题是客观存在的，不是简单的通过什么插件可以解决的，一般需要借助昂贵的专线。

    很多书籍和文章中存在误导大家的，可能会说Federation/Shovel可以解决延迟的问题，可以实现异地多活等等，其实这都是错误的。而且我可以负责人的告诉大家，他们所谓的“异地多活”并非大厂最佳实践。

    例如：使用Shovel构建集群，RabbitMQ和应用程序都选择双机房部署时，当杭州机房发生了消息积压后超出阈值部分的消息就会被转发到上海机房中，此时上海机房的应用程序直接消费掉上海机房RabbitMQ的消息，这样看起来上海机房是可以分摊负载，而且一定程度上实现“双机房多活”的。但是数据库呢？选择两边都部署还是仅部署在某个机房呢？两边同时写入是很容易造成冲突的，如果数据库仅仅部署在杭州机房，那么数据库也可能成为瓶颈导致消费速度依然上不去，只不过是多了上海机房中的消费者实例节点而已。

    而使用Federation模式呢？如果要真正要实现“双机房多活”那么应用程序也是多机房的，那某些Exchange/Queue中的消息会在两边机房都有，两边机房的应用程序都会同时消费，那必然会造成重复消费！

    异地多活架构:

2. 单机多实例部署

  • 多个RabbitMQ使用的端口号不能冲突

  • 多个RabbitMQ使用的磁盘存储路径不能冲突

  • 多个RabbitMQ的配置文件也不能冲突

这种情况一般几乎用不到, 这里不再做演示, 略过…………….

3. 集群管理

这节结合 Rabbit集群+镜像队列+HAProxy实现负载均衡的集群

  • 找三台机器, 安装rabbitmq,举例: node1, node2, node3

    需要在/etc/hosts文件里配置 node name , 保证能相互ping通

  • 从node1拷贝.erlang.cookie到node2, node3

    如果没有该文件，手动创建 /var/lib/rabbitmq/.erlang.cookie ，生成Cookie字符串，或者启动一次RabbitMQ自动生成该文件。生产中推荐使用第三方工具生成

    首先启动node1生成cookie文件:

    systemctl start rabbitmq-server

    再远程传输给node2, node3

    scp /var/lib/rabbitmq/.erlang.cookie root@node2:/var/lib/rabbitmq/ 
scp /var/lib/rabbitmq/.erlang.cookie root@node3:/var/lib/rabbitmq/

    修改node2, node3上该文件 的所有都 为rabbitmq:rabbitmq

    chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie

  • 启动node2, node3上的rabbitmq, 使用以下命令

    systemctl start rabbitmq-server
或
rabbitmq-server -detached

  • 将node2, node3两个节点加入到集群中

    # 停止Erlang VM上运行的RabbitMQ应用，保持Erlang VM的运行 
rabbitmqctl stop_app 

# 移除当前RabbitMQ虚拟主机中的所有数据：重置 
rabbitmqctl reset 

# 将当前RabbitMQ的主机加入到rabbit@node1这个虚拟主机的集群中。一个节点也是集群。 
rabbitmqctl join_cluster rabbit@node1 

# 启动当前Erlang VM上的RabbitMQ应用 
rabbitmqctl start_app

    注意:

    • rabbit@node1 表示RabbitMQ节点名称，默认前缀就是 rabbit ， @ 之后是当前虚拟主机所在的物理主机 hostname 。

    • 注意检查下hostname要可以相互ping通

    • join_cluster默认是使用disk模式，后面可以加入参数–ram启用内存模式

  • 通过 rabbitmqctl cluster_status命令查看集群信息

    成功后即可看到如下节点信息

  • 移除节点使用

    # 将虚拟主机（RabbitMQ的节点）rabbit@node3从集群中移除，但是rabbit@node3还保留集群信息
# 还是会尝试加入集群，但是会被拒绝。可以重置rabbit@node3节点。 
rabbitmqctl forget_cluster_node rabbit@node3

#修改集群名称（任意节点执行都可以） 
rabbitmqctl set_cluster_name 

#查看集群状态（任意节点执行都可以） 
rabbitmqctl cluster_status

  • 可以到web控制台查看集群信息，如果要看到所有RabbitMQ节点上的运行情况，都需要启用rabbitmq_management 插件。

4. 镜像集群配置

RabbitMQ中队列的内容是保存在单个节点本地的（声明队列的节点）。跟交换器和绑定不同，它们是对于集群中所有节点的。如此，则队列内容存在单点故障，解决方式之一就是使用镜像队列。在多个节点上拷贝队列的副本.

每个镜像队列包含一个master，若干个镜像。master存在于称为master的节点上。所有的操作都是首先对master执行，之后广播到镜像。这涉及排队发布，向消费者传递消息，跟踪来自消费者的确认等。

镜像意味着集群，不应该WAN使用。

发布到队列的消息会拷贝到该队列所有的镜像。消费者连接到master，当消费者对消息确认之后，镜像删除master确认的消息。

队列的镜像提供了高可用，但是没有负载均衡。HTTP API和CLI工具中队列对象的字段原来使用的是slave代表secondaries，现在盖字段的存在仅是为了向后兼容，后续版本会移除。

可以使用策略随时更改队列的类型，可以首先创建一个非镜像队列，然后使用策略将其配置为镜像队列或者反过来。非镜像队列没有额外的基础设施，因此可以提供更高的吞吐率。

master选举策略：

  • 最长的运行镜像升级为主镜像，前提是假定它与主镜像完全同步。如果没有与主服务器同步的镜像，则仅存在于主服务器上的消息将丢失。
  • 镜像认为所有以前的消费者都已突然断开连接。它重新排队已传递给客户端但正在等待确认的所有消息。这包括客户端已为其发出确认的消息，例如，确认是在到达节点托管队列主节点之前在线路上丢失了，还是在从主节点广播到镜像时丢失了。在这两种情况下，新的主服务器都别无选择，只能重新排队它尚未收到确认的所有消息。
  • 队列故障转移时请求通知的消费者将收到取消通知。当镜像队列发生了master的故障转移, 系统就不知道向哪些消费者发送了哪些消息。已经发送的等待确认的消息会重新排队
  • 重新排队的结果是，从队列重新使用的客户端必须意识到，他们很可能随后会收到已经收到的消息。
  • 当所选镜像成为主镜像时，在此期间发布到镜像队列的消息将不会丢失（除非在提升的节点上发生后续故障）。发布到承载队列镜像的节点的消息将路由到队列主服务器，然后复制到所有镜像。如果主服务器发生故障，则消息将继续发送到镜像，并在完成向主服务器的镜像升级后将其添加到队列中。
  • 即使主服务器（或任何镜像）在正在发布的消息与发布者收到的确认之间失败，由客户端使用发布者确认发布的消息仍将得到确认。从发布者的角度来看，发布到镜像队列与发布到非镜像队列没有什么不同。

给队列添加镜像要慎重。

ha-mode ha-params 结果
exactle count 设置集群中队列副本的个数（镜像+master）。1表示一个副本；也就是master。如果master不可用，行为依赖于队列的持久化机制。2表示1个master和1个镜像。如果master不可用，则根据镜像推举策略从镜像中选出一个做master。如果节点数量比镜像副本个数少，则镜像覆盖到所有节点。如果count个数少于集群节点个数，则在一个镜像宕机
后，会在其他节点创建出来一个镜像。将“exactly”模式与“ha-promote-on-shutdown”:“always”一起使用可能很危险，因为队列可以在整个集群中迁移并在关闭时变得不同步。
all none 镜像覆盖到集群中的所有节点。当添加一个新的节点，队列就会复制过去。这个配置很保守。一般推荐N/2+1个节点。在集群所有节点拷贝镜像会给集群所有节点施加额外的负载，包括网络IO，磁盘IO和磁盘空间使用。
nodes node names 在指定nodename的节点上复制镜像。nodename就是在rabbitmqctl cluster_status命令输出中的nodename。如果有不属于集群的节点名称，它不报错。如果指定的节点都不在线，则仅在客户端连接到的声明镜像的节点上创建镜像。

启用镜像队列: 例如下面的queueA

# 对/节点配置镜像队列，使用全局复制 
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}' 

# 配置过半（N/2 + 1）复制镜像队列 
rabbitmqctl set_policy ha-halfmore "queueA" '{"ha-mode":"exactly", "ha-params":2}' 

# 指定优先级，数字越大，优先级越高 
rabbitmqctl set_policy --priority 1 ha-all "^" '{"ha-mode":"all"}'

通过管理平台查看:

5. 负载均衡-HAProxy

将客户端的连接和操作的压力分散到集群中的不同节点，防止单个或几台服务器压力过大成为访问的瓶颈，甚至宕机。

HAProxy是一款开源免费，并提供高可用性、负载均衡以及基于TCP和HTTP协议的代理软件，可以支持四层、七层负载均衡，经过测试单节点可以支持10W左右并发连接。

LVS是工作在内核模式（IPVS），支持四层负载均衡，实测可以支撑百万并发连接。

Nginx支持七层的负载均衡（后期的版本也支持四层了），是一款高性能的反向代理软件和Web服务器，可以支持单机3W以上的并发连接。

这里我们使用HAProxy来做RabbitMQ的负载均衡，通过暴露VIP给上游的应用程序直接连接，上游应用程序不感知底层的RabbitMQ的实例节点信息。

yum install gcc -y 
# 下载并解压
tar -zxf haproxy-2.1.0.tar.gz 
cd haproxy-2.1.0 
make TARGET=linux-glibc
make install 
mkdir /etc/haproxy

#赋权 
groupadd -r -g 149 haproxy 
# 添加用户 
useradd -g haproxy -r -s /sbin/nologin -u 149 haproxy 
#创建haproxy配置文件 
touch /etc/haproxy/haproxy.cfg

也可以通过下列命令直接安装

yum -y install haproxy
#haproxy默认在/usr/sbin/haproxy，且会自动创建配置文件/etc/haproxy/haproxy.cfg

配置HAProxy, 修改/etc/haproxy/haproxy.cfg

vim /etc/haproxy/haproxy.cfg

# 添加以下配置
listen rabbitmq_cluster
    # VIP,反向代理到自定义3台node
    bind localhost:6000
    # 此处要用tcp模式, 要不然在项目中连接不上
    mode tcp
    balance roundrobin
    # rabbitmq 集群节点配置, 此处用node name是因为我在/etc/hosts里映射了名称
    # inter 每隔5s对mq集群进行健康检查,2次正确证明服务器可用,2次失败证明服务器不可用
    server hecs-206962 hecs-206962:5672 check inter 5000 rise 2 fall 2
    server hecs-221700-0001 hecs-221700-0001:5672 check inter 5000 rise 2 fall 2
    server hecs-221700-0002 hecs-221700-0002:5672 check inter 5000 rise 2 fall 2
listen stats
		# 此处不要用localhost, 用内网地址,这样就可以通过外网访问了
    bind 192.168.0.237:9000
    mode http
    option httplog
    #启用基于程序编译时默认设置的统计报告 
    stats enable
    #设置proxy 监控地址为http://ip:9000/rabbitmq-stats
    stats uri /rabbitmq-stats
    #每5s刷新一次页面
    stats refresh 5s

启动HAProxy

haproxy -f /etc/haproxy/haproxy.cfg

#关闭
kill -9 <pid>

检查进程状态，还可以通过访问http://ip:9000/rabbitmq-stats查看状态

示例代码: demo16_haproxy

6. 监控

RabbitMQ自带的（Management插件）管理控制台功能比较丰富，不仅提供了WebUI界面，还暴露了很多HTTPAPI的能力。其中也具备基本的监控能力。此外，自带的命令行工具（例如：rabbitmqctl）也比较强大。

不过这些工具都不具备告警的能力。在实际的生产环境中，我们需要知道负载情况和运行监控状态（例如：系统资源、消息积压情况、节点健康状态等），而且当发生问题后需要触发告警。像传统的监控平台Nagios、Zabbix等均提供了RabbitMQ相关的插件支持。

另外，当前云原生时代最热门的Prometheus监控平台也提供了rabbitmq_exporter，结合Grafana 漂亮美观的dashboard（可以自定义，也可以在仓库选择一些现有的），可以使用Prometheus+Grafana来监控RabbitMQ的并实现了水位告警通知。

感兴趣的同学可以自己研究。https://www.rabbitmq.com/prometheus.html

0%