RabbitMQ理论

一般的消息中间件两种模式

消息队列中间件，也可以称为消息队列。有两种传递模式:点对点(P2P, Point-to-Point) 模式和发布/订阅 (Pub/Sub) 模式。

• 点对点模式
  基于队列的，先进先出，消息的生产和消费是异步的。许多个生产者往同一个队列发送消息。但是，如果有多个消费者，实际上是竞争的关系，也就是一条消息只能被其中一个消费者接收到，读完即被删除。
  

• 发布订阅模式
  解决需要将一份消息数据发给多个消费者，并且每个消费者都要求收到所有的消息。
  

存放消息的容器变成了 “主题”，订阅者在接收消息之前需要先 “订阅主题”。最终，每个订阅者都可以收到同一个主题的全量消息。与点对点模式的区别在于一份消息数据是否可以被多次消费。

一般的消息中间件作用

解耦（最重要的特性）、异步、流量削峰、保证消息的顺序等

一般的消息中间件基本架构和设计思路

• Producer: 生产者，就是投递消息的一方。
• Consumer: 消费者 就是接收消息的 方。
• Broker: 消息中间件的服务节点
  
  Broker（服务端）是MQ 中最核心的部分，是 MQ 的服务端，核心逻辑几乎全在这里，它为生产者和消费者提供 RPC 接口，负责消息的存储、备份和删除，以及消费关系的维护等。 Producer（生产者）是MQ 的客户端之一，调用 Broker 提供的 RPC 接口发送消息。 Consumer（消费者）是MQ 的另外一个客户端，调用 Broker 提供的 RPC 接口接收消息，同时完成消费确认。
  

参考
消息队列（mq）是什么？

RabbitMQ架构

基于交换器和队列的消息中间件，消息通过不同路由器到不同的队列里，由订阅该队列的消费者消费。

RabbitMQ 的内部对象

• Queue:队列，是 RabbitMQ 的内部对象，用 于存储消息.当多个消费者订阅同一个队列，这时队列中的消息会被平均分摊（即轮询)给多个消费者进行处理，而不是每个消费者都收到所有的消息井处理。
  

• Exchange:交换器
  RabbitMQ中，生产者并不是直接将消息投递到队列中。生产者将消息发送到Exchange (交换器)，由交换器将消息路由到一个或者多个队列中。如果路由不到，或许会返回给生产者，或许直接丢弃。交换器有四种类型，不同的类型有着不 同的路由策略。
  

• RoutingKey: 路由键
  生产者将消息发给交换器的时候， 一般会指定一个 RoutingKey ，用来指定这个消息的路由规则，而这个 RoutingKey 需要与交换器类型和绑定键 (BindingKey)合使用才能最终生效，决定消息流向哪里。

• Binding: 绑定
  RabbitMQ 中通过绑定将交换器与队列关联起来，在绑定的时候一般会指定一绑定键 BindingKey ，这样 RabbitMQ 就知 何正确 将消息路由队列了。
  

RabbitMQ交换器类型

• fanout
  它会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。

• direct
  direct 类型的交换器路由规则很简单，它会把消息路由到那些 BindingKey RoutingKey完全匹配的队列中。
  

• topic
  topic 交换器会将消息路由至匹配路由键的任何队列中 。但是通过采用句点分隔的形式，队列可以通过使用基于通配符的模式匹配的方式来绑定到路由键上。通过使用星号（＊）和井号（＃〉字符，你可以在同一时刻匹配路由键的特定部分，甚至是多个部分。星号将会匹配路由键中下一个句点前的所有字符，而井号键将会匹配接下来所有的字符，包括句点。
  

• headers
  它通过采用消息属性中的 headers 表支持任意的路由策略。

• 使用一致性哈希交换器路由消息
  

参考：
RabbitMQ实战指南.朱忠华

集群

为什么需要集群

• 防止单个节点崩溃造成整个服务崩溃
• 提高系统吞吐量；
• 备份节点元数据信息，防止节点崩溃该节点队列中消息丢失。

集群架构

• 主备模式
  适用于并发和数据量不高的情况下，主节点提供读写，从节点负责备份服务,主节点宕机时，完成自动切换从–>主
  

• 镜像模式
  保证100%数据不丢失，一般来讲是3个节点实现数据同步。在主备的基础上进行了扩展，集群中所有的节点设备都是同步的，每一个队列，交换机里面的配置信息和我们的数据都是同步的，对于这些镜像在底层同时进行工作，前面的话采用一个负载均衡器，采用nginx或者haproxy也好，进行负载均衡。
  

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

引用：
RabbitMQ集群架构模式及搭建Rabbitmq-Mirror镜像集群
详解RabbitMQ的4种集群架构