RabbitMQ集群架构模式

主备模式 （Warren)

主备模式又被称为Warren模式,实现RabbitMQ的高可用集群,一般再并发和数据量不高的情况下使用,这种模型较为简单。
主备模式和主从不一样的地方在于,从机不停供任何读写操作,只是一个备用服务在主机挂了后继续提供服务,主机再连上时变为从机,数据由主机单向同步到从机。一般再并发和数据量不高时使用

主备模式HaProxy配置

镜像模式 （Mirror)

镜像模式：集群模式非常经典的就是Mirror镜像模式，保证100%数据不丢失，在实际工作中也是用的最多的，而且实现集群也非常简单，一般互联网大厂都会构建这种镜像集群模式，原理主要是在主备的基础上进行了扩展，集群中所有的节点设备都是同步的，每一个队列，交换机里面的配置信息和我们的数据都是同步的，对于这些镜像在底层同时进行工作，前面的话采用一个负载均衡器，采用nginx或者haproxy也好，进行负载均衡。

远程模式 (Shovel)

远程模式可以实现双活的一种模式，简称Shovel模式，所谓Shovel就是我们可以把消息进行不同数据中心的复制工作，我们可以跨地域的让两个MQ集群互联，比如说一个集群，我们都会放在一个机房里面，那么如果北京的机房出现了一些事故停电，或者自然灾害，那么这个集群都会宕机了，那么在我们对数据要求极高的大型应用我们需要设置多活或者双活的模式，也就是要搭建多个数据中心，或者多套集群，那么这些集群可以一个会放在上海，一个放在北京，还有应放在广州，三个集群数据都是同步的，中间有任何一个集群出现了问题，马上灵活的切换，那么这三个集群都是可以访问的话，我们可能会按照距离，或者访问速度来进行优先选择哪组集群，或者数据中心进行访问，所有多活模式，在银行开发的时候一般也叫做容灾的机制，至少构建两套集群放在不同的地域，一个有问题了，立马进行切换，不至于整个系统宕机，这就是多活模式，在多活模式中MQ也提供了相应的实现方式，早期使用的Shovel模式，这个模式是mq自带的一种模式，主要就是可以把消息在不同的数据中心进行负载分发，主要就是可以实现跨地域的让两个mq集群进行互联。

设置MQ集群的阈值,当并发到达指定阈值时可以通过Shovel将消息转发给其他MQ集群,并且可以实现多个集群的数据同步

那么这个shovel模式需要统一的版本，网络达到一个什么样的水平，配置的话也是有些复杂，这种的话目前已经淘汰了，在真正的数据复制的情况下，会使用多活模式。

Shovel集群配置

启动rabbitmq插件

#shell
rabbitmq-plugins enable amqp_client
rabbitmq-plugins enable rabbitmq_client

在源服务器和目标服务器都创建rabbitmq.conf文件,使用相同配置

#shell
touch /etc/rabbitmq/rabbitmq.config

官网rabbitmq.conf配置说明

{rabbitmq_shovel,
   [{shovels,
     [%% A named shovel worker.
      {my_test_shovel,
       [

    %  List the source broker(s) from which to consume.
     
        {sources,
         [%% URI(s) and pre-declarations for all source broker(s).
         {brokers, ["amqp://shovel_user:123456@45.32.250.47:5672"]},
          {declarations, [
              {'exchange.declare',
                 [ {exchange, <<"shovel_exchange">>},
                 {type, <<"direct">>},
                 durable
                 ]},
             {'queue.declare',
                 [{queue,    <<"shovel_outcome_queue">>},durable]},
             {'queue.bind',
                 [ {exchange, <<"shovel_exchange">>},
                 {queue,    <<"shovel_outcome_queue">>},
                 {routing_key, <<"shovel_key">>}
                 ]}
          ]}
         ]},

    %  List the destination broker(s) to publish to.
        {destinations,
         [%% A singular version of the 'brokers' element.
         {broker, "amqp://shovel_user:123456@47.106.179.208:5672"},
          {declarations, [{'exchange.declare',
                             [ {exchange, <<"shovel_exchange">>},
                             {type, <<"direct">>},
                             durable
                             ]},
                         {'queue.declare',
                             [{queue,    <<"shovel_income_queue">>},durable]},
                         {'queue.bind',
                             [ {exchange, <<"shovel_exchange">>},
                             {queue,    <<"shovel_income_queue">>},
                             {routing_key, <<"shovel_key">>}
                             ]}]}
         ]},

    %  Name of the queue to shovel messages from.
     
      {queue, <<"shovel_outcome_queue">>},

    %  Optional prefetch count.
     
      {prefetch_count, 10},

    %  when to acknowledge messages:
     %  - no_ack: never (auto)
     %  - on_publish: after each message is republished
     %  - on_confirm: when the destination broker confirms receipt
     
      {ack_mode, no_ack},

    %  Overwrite fields of the outbound basic.publish.
     
      {publish_fields, [{exchange,    <<"shovel_exchange">>},
                        {routing_key, <<"shovel_key">>}]},

    %  Static list of basic.properties to set on re-publication.
     
      {publish_properties, [{delivery_mode, 2}]},

    %  The number of seconds to wait before attempting to
     %  reconnect in the event of a connection failure.
     
      {reconnect_delay, 2.5}

     ]} %% End of my_first_shovel
     ]}
    %% Rather than specifying some values per-shovel, you can specify
    %% them for all shovels here.
    %%
    %% {defaults, [{prefetch_count,     0},
    %%             {ack_mode,           on_confirm},
    %%             {publish_fields,     []},
    %%             {publish_properties, [{delivery_mode, 2}]},
    %%             {reconnect_delay,    2.5}]}
   ]}

链接:配置文件方式参考.
链接:图形化配置参考.

多活模式 （Federation)

这种模式也是实现异地数据复制的主流模式,这种模式是依赖rabbimq的fedrtation插件的模式
本身不是mq自带的东西，是在mq上进行了扩展，而这种扩展是实现的可靠的AMQP的数据通信，因此配置起来也比较容易，相当于配置简单化之后的shovel。