RabbitMQ 的4种集群架构

    也称为 Warren (兔子窝) 模式。实现 rabbitMQ 的高可用集群，一般在并发和数据量不高的情况下，这种模式非常的好用且简单。

    也就是一个主/备方案，主节点提供读写，备用节点不提供读写。如果主节点挂了，就切换到备用节点，原来的备用节点升级为主节点提供读写服务，当原来的主节点恢复运行后，原来的主节点就变成备用节点，和 activeMQ 利用 zookeeper 做主/备一样，也可以一主多备。
HaProxy 配置:

listen rabbitmq_cluster

bind 0000:567  # 配置 tcp 模式

mode tcp  # 简单的轮询

balance roundrobin  # 主节点 roundrobin  随机

server 你的76机器 hostname  1921681176:5672 check inter 5000 rise 2 fall 2

server 你的77机器 hostname  1921681177:5672 backup check inter 5000 rise 2 fall 2  # 备用节点

    注意了，上面的 rabbitMQ 集群节点配置 # inter 每隔 5 秒对 mq 集群做健康检查， 2 次正确证明服务可用，2 次失败证明服务器不可用，并且配置主备机制

    远程模式可以实现双活的一种模式，简称 shovel 模式，所谓的 shovel 就是把消息进行不同数据中心的复制工作，可以跨地域的让两个 MQ 集群互联，远距离通信和复制。

    Shovel 就是我们可以把消息进行数据中心的复制工作，我们可以跨地域的让两个 MQ 集群互联。

如图所示，有两个异地的 MQ 集群（可以是更多的集群），当用户在地区 1 这里下单了，系统发消息到 1 区的 MQ 服务器，发现 MQ 服务已超过设定的阈值，负载过高，这条消息就会被转到 地区 2 的 MQ 服务器上，由 2 区的去执行后面的业务逻辑，相当于分摊我们的服务压力。

    在使用了 shovel 插件后，模型变成了近端同步确认，远端异步确认的方式，大大提高了订单确认速度，并且还能保证可靠性。

    如上图所示，当我们的消息到达 exchange，它会判断当前的负载情况以及设定的阈值，如果负载不高就把消息放到我们正常的 warehouse_goleta 队列中，如果负载过高了，就会放到 backup_orders 队列中。backup_orders 队列通过 shovel 插件与另外的 MQ 集群进行同步数据，把消息发到第二个 MQ 集群上。

    这是 rabbitMQ 比较早期的架构模型了，现在很少使用了。

shovel 集群的配置，首先启动 rabbitmq 插件，命令如下:

    rabbitmq-plugins enable amqp_client

    rabbitmq-plugins enable  rabbitmq_shovel

    在 /etc/rabbitmq/ 目录下创建 rabbitmqconfig 文件。注意，我们源服务器和目的地服务器都使用这个相同的配置文件。

    具体配置如下

    非常经典的 mirror 镜像模式，保证 100% 数据不丢失。在实际工作中也是用得最多的，并且实现非常的简单，一般互联网大厂都会构建这种镜像集群模式。

    mirror 镜像队列，目的是为了保证 rabbitMQ 数据的高可靠性解决方案，主要就是实现数据的同步，一般来讲是 2 - 3 个节点实现数据同步。对于 100% 数据可靠性解决方案，一般是采用 3 个节点。

    集群架构如下

    如上图所示，用 KeepAlived 做了 HA-Proxy 的高可用，然后有 3 个节点的 MQ 服务，消息发送到主节点上，主节点通过 mirror 队列把数据同步到其他的 MQ 节点，这样来实现其高可靠。

    也是实现异地数据复制的主流模式，因为 shovel 模式配置比较复杂，所以一般来说，实现异地集群的都是采用这种双活 或者 多活模型来实现的。这种模式需要依赖 rabbitMQ 的 federation 插件，可以实现持续的，可靠的 AMQP 数据通信，多活模式在实际配置与应用非常的简单。

    rabbitMQ 部署架构采用双中心模式(多中心)，那么在两套(或多套)数据中心各部署一套 rabbitMQ 集群，各中心的rabbitMQ 服务除了需要为业务提供正常的消息服务外，中心之间还需要实现部分队列消息共享。

多活集群架构如下:
    federation 插件是一个不需要构建 cluster ，而在 brokers 之间传输消息的高性能插件，federation 插件可以在 brokers 或者 cluster 之间传输消息，连接的双方可以使用不同的 users 和 virtual hosts，双方也可以使用不同版本的 rabbitMQ 和 erlang。federation 插件使用 AMQP 协议通信，可以接受不连续的传输。federation 不是建立在集群上的，而是建立在单个节点上的，如图上的 rabbit node 3 可以与绿色的 node1、node2、node3 中的任意一个利用 federation 插件进行数据同步。
    如上图所示，federation exchanges 可以看成 downstream 从 upstream 主动拉取消息，但是并不是拉取所有消息，必须是在 downstream 上已经明确定义 Bingdings 关系的 exchange，也就是有实际的物理 queue 来接收消息，才会从 upstream 拉取消息到 downstream 。

    它使用 AMQP 协议实现代理间通信，downstream 会将绑定关系组合在一起，绑定/解绑命令将发送到 upstream 交换机。因此，federation exchange 只接收具有订阅的消息。

虽然在以往的项目开发过程中已经使用过RabbitMQ与Kafka，但还是不能准确并全面的总结出它们俩之间的差异。

在这之前很长一段时间一直都是把这两种技术当做等价的来看待，突然想到如果是我在某种特定业务下来做选型的话，我要怎么选呢？万一选错了，对于软件开发和后期的维护都会造成严重的影响。

所谓学而时习之，不亦说乎。温故而知新，可以为师矣。所以通过官网和参考了一些博客，做了以下整理：

RabbitMQ是消息中间件，Kafka是分布式流式系统。

RabbitMQ

被概括为“开源分布式消息代理”，用Erlang编写，有助于在复杂的路由方案中有效地传递消息，可以通过服务器上启用的插件进行扩展，高可用（队列可以在集群中的机器上进行镜像）

有队列

RabbitMQ的发布/订阅模式

Apache Kafka

被描述为“分布式事件流平台”，用Scala和Java编写，促进了原始吞吐量，基于“分布式仅追加日志”的思想，该消息将消息写入持久化到磁盘的日志末尾，客户端可以选择从该日志开始读取的位置，高可用（Kafka群集可以在多个服务器之间分布和群集）

无队列，按主题存储

Kafka的发布/订阅模式

Kafka支持消息有序性，RabbitMQ不保证消息的顺序

RabbitMQ

Kafka

在消息路由和过滤方面，RabbitMQ提供了更好的支持

RabbitMQ

Kafka

消息时序

RabbitMQ

Kafka

Kafka支持消息留存，RabbitMQ不支持

RabbitMQ

Kafka

RabbitMQ的容错处理优于Kafka

RabbitMQ

Kafka

Kafka在伸缩方面更优并且能够获得比RabbitMQ更高的吞吐量

RabbitMQ

Kafka

RabbitMQ的消费者复杂度低于Kafka

RabbitMQ

Kafka

首先是在不考虑一些非功能性限制（如运营成本，开发人员对两个平台的了解等）的情况下：

优先选择RabbitMQ的条件

优先选择Kafka的条件

问题原因: 由于服务器异常宕机导致RabbitMQ挂掉，服务器恢复之后尝试启动MQ发现启动失败。报错信息如下

查看状态:

报错如下:

解决:

系统日志如下:

删除/var/lib/rabbitmq/mnesia 目录下的rabbit@iZbp128yw4rvtfbytgv4y7Zpid、rabbit@iZbp128yw4rvtfbytgv4y7Z、rabbit@iZbp128yw4rvtfbytgv4y7Z-plugins-expand后，再使用 systemctl start rabbitmq-server 启动，成功启动MQ。
注意 : 文件中包含交换机队列及用户等信息,删除等于重置MQ(队列会被清空),请谨慎 *** 作

---