RabbitMQ

Broken1(rabbitMQ Server)

queue

5.republish

Consumer

RabbitMQ保证顺序消费

type=direct

Exchange

lazy.#

Producer

多机集群HA方案

数据库

QueueSlave

延迟队列

集群机房2

channel

路由模式增加一个路由配置，direct类型的exchange会根据routingkey，将消息转发到该exchange上绑定了该routingkey的所有queue。在消费过程中，若没有答复过的消息，服务器会一直不停转发。例如：系统需要针对日志做分析，首先所有的日志级别的日志都需要保存，其次error日志级别的日志需要单独做处理。就可以用该模式去实现日志区分。注意：先运行两个消费者，在运行生产者。如果没有提前将队列绑定到交换机，那么直接运行生产者的话，消息是不会发到任何队列里的。

QueueMaster

Broken(rabbitMQ Server)

Virtual Host

Publisher Confirms机制作为解决事务机制性能开销大（导致吞吐量下降）而提出的另外一种保证消息不会丢失的方式。首先client 首先要发送 confirm.select 方法帧。broker 会相应的判定是否以 confirm.select-ok 进行应答。一旦在 channel 上使用 confirm.select 方法，channel 就将处于 confirm 模式。处于 transactional 模式的 channel 不能再被设置成 confirm 模式，反之亦然。在发生异常情况发生时，broker 将无法成功处理相应的消息，此时 broker 将发送 basic.nack 来代替 basic.ack 。这种模式只能保证Producer和Broken的原子性。

①delete②insert③update

RabbitMQ 基础架构

Death-Letter-Exchange

死信队列

*.orange.*

②insert

镜像集群

HAProxy

Broken2(rabbitMQ Server)

远程数据分发

RabbitMQ 的几种传输模式

*.*.rabbit

...

操作系统

x

Work queues 工作序列

RabbitMQ消息零丢失方案

RabbitMQ高可用方案

4.basic.ack/basic.nack

warn

FederatedExchange

Publisher/Confirms机制

④

type=header

font color=\"#0d47a1\

Topics 话题

Federation

Federation Plugin如果我们需要在多个RabbitMQ服务之间进行消息同步，那么，首选的方案自然是通过RabbitMQ集群来进行。但是，在某些网络状况比较差的场景下，搭建集群会不太方便。例如：某大型企业，可能在北京机房和长沙机房分别搭建RabbitMQ服务，然后希望长沙机房需要同步北京机房的消息，这样可以让长沙的消费者服务可以直接连接长沙本地的RabbitMQ，而不用费尽周折去连接北京机房的RabbitMQ服务。这时要如何进行数据同步呢？搭建一个网络跨度这么大的集群显然就不太划算。这时就可以考虑使用RabbitMQ的Federation插件，搭建联邦队列Federation。通过Federation可以搭建一个单向的数据同步通道(当然，要搭建双相同步也是可以的)。

slave

master

镜像集群将多台Rabbit MQ服务器连接组成一个集群，在连接过程中需要正确的Erlang Cookie和节点名称才能保证机器之间相互进行连接访问，并且集群需要要局域网内进行部署。font color=\"#0d47a1\

error

①insert②update③delete

ttl=15min

Connection

集群机房1

3.publish

type=topic

1.confirm.select

死信队列死信队列是RabbitMQ对于未能正常消费的消息进行的一种补救机制。死信队列也是一个普通的队列，同样可以在队列上声明消费者，继续对消息进行消费处理。何时会产生死信?1.消息被消费者确认拒绝。消费者把requeue参数设置为true(false)，并且在消费后，向RabbitMQ返回拒绝。2.消息达到预设的TTL时限还一直没有被消费。3.消息由于队列已经达到最长长度限制而被丢掉。如何确定一个消息是不是死信？消息被作为死信转移到死信队列后，会在Header当中增加一些消息。比如时间、原因、队列等。然后header中还会加上第一次成为死信的三个属性，并且这三个属性在以后的传递过程中都不会更改。1.x-first-death-reason2.x-first-death-queue3.x-first-death-exchange延时队列RabbitMQ本身并没有延时队列的功能，但是我们可以通过死信队列+ ttl去实现这个功能。例如订单场景，把订单放入队列当中，并且队列的ttl设置为15min，15min后无消费者消费，则转发至死信交换机，然后在死信消费者中查询订单的最终状态。注意：死信在转移到死信队列的过程中，是没有经过消息发送者确认的，所以并不能保证消息的安全性。

infoheader(level=2)

①delete

① 生产者保证消息正确发送到RibbitMQRabbitMQ的生产者确认机制分为同步确认和异步确认。同步确认主要是通过在生产者端使用Channel.waitForConfirmsOrDie()指定一个等待确认的完成时间。（Publisher/Confirms的方式，可以保证消息正确发送。）②span style=\

广播模式fanout类型的exchange会往其上绑定的所有queue转发消息。这个机制是对上面的一种补充。也就是把preducer与Consumer进行进一步的解耦。producer只负责发送消息，至于消息进入哪个queue，由exchange来分配。

Binding

Routing 基于内容的路由

info

type=fanout

RabbitMQ 中的相关概念Broker：接收和分发消息的应用，RabbitMQ Server就是 Message BrokerVirtual host：出于多租户和安全因素设计的，把 AMQP 的基本组件划分到一个虚拟的分组中，类似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时，可以划分出多个vhost，每个用户在自己的 vhost 创建 exchange／queue 等Connection：publisher／consumer 和 broker 之间的 TCP 连接Channel：如果每一次访问 RabbitMQ 都建立一个 Connection，在消息量大的时候建立 TCP Connection的开销将是巨大的，效率也较低。Channel 是在 connection 内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的 channel 进行通讯，AMQP method 包含了channel id 帮助客户端和message broker 识别 channel，所以 channel 之间是完全隔离的。Channel 作为轻量级的 Connection 极大减少了操作系统建立 TCP connection 的开销 

Broken3(rabbitMQ Server)

2.confirm.select-ok

Header 话题

Publish/Subscribe 订阅 发布 机制

③

①

infoheader(level=1)

这个模式应该是最常用的模式RabbitMQ默认是采用消息轮询的方式。也可以向服务器声明一个prefetchCount，表示当前这个consumer可以同时处理几个message。如果出现一个consumer宕机的情况，消息会重新入队并发像其他可用consumer。优点：实现简单，方便。缺点：消息有可能全部阻塞，所有consumer节点都超过了能力值，那消息就阻塞在服务器上。

③update

②