RabbitMQ就是 AMQP 协议的 Erlang 的实现(当然 RabbitMQ 还支持 STOMP2、 MQTT3 等协议 ) AMQP 的模型架构 和 RabbitMQ 的模型架构是一样的，生产者将消息发送给交换器，交换器和队列绑定 。RabbitMQ 中的交换器、交换器类型、队列、绑定、路由键等都是遵循的 AMQP 协议中相应的概念。
采用AMQP高级消息队列协议的一种消息队列技术,最大的特点就是消费并不需要确保提供方存在,实现了服务之间的高度解耦。
1.在分布式系统下具备异步,削峰,负载均衡等一系列高级功能；
2.拥有持久化的机制，进程消息，队列中的信息也可以保存下来。
3.实现消费者和生产者之间的解耦。
4.对于高并发场景下，利用消息队列可以使得同步访问变为串行访问达到一定量的限，利于数据库的操作。
5.可以使用消息队列达到异步下单的效果，排队中，后台进行逻辑下单。
1.服务间异步通信
2.顺序消费
3.定时任务
4.请求削峰
Broker：简单来说就是消息队列服务器实体
Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列
Queue：消息队列载体，每个消息都会被投入到一个或多个队列
Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来
Routing Key： 路由关键字，exchange根据这个关键字进行消息投递
VHost：vhost可以理解为虚拟broker ，即mini-RabbitMQ server。其内部均含有独立的queue、exchange和binding等，但最最重要的是，其拥有独立的权限系统，可以做到vhost范围的用户控制。当然，从RabbitMQ的全局角度，vhost可以作为不同权限隔离的手段（一个典型的例子就是不同的应用可以跑在不同的 vhost 中）。
Producer： 消息生产者，就是投递消息的程序
Consumer：消息消费者，就是接受消息的程序
Channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务由Exchange、Queue、RoutingKey三个才能决定一个从Exchange到Queue的唯一的线路。
消息的发送方有个确认模式，具体的流程如下：
1.将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。
2.一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一 ID）。
3.如果 RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（notacknowledged，未确认）消息。发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。
消息的接收方消息确认机制，具体的流程如下：
消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性；
如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。
在消息生产时，RabbitMQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列；
在消息消费时，要求消息体中必须要有一个 bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID 等）作为去重的依据，避免同一条消息被重复消费。
消息不丢失需要堆消息进行持久化。
确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件，当发布一条持久性消息到持久交换器上时，Rabbit会在消息提交到日志文件后才发送响应。一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ会在持久化日志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前RabbitMQ重启，那么Rabbit会自动重建交换器和队列（以及绑定），并重新发布持久化日志文件中的消息到合适的队列。
由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。
若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会分发给一个订阅的消费者（前提是消费者能够正常处理消息并进行确认）。
主要有3种：
1.fanout：如果交换器收到消息，将会广播到所有绑定的队列上
2.direct：如果路由键完全匹配，消息就被投递到相应的队列
3.topic：可以使来自不同源头的消息能够到达同一个队列。 使用topic交换器时，可以使用通配符
1.简单模式，用的默认交换机，1个生产者，1个消费者，一个消息只能被一个消费者消息
2.工作模，多个消费者监听同一个队列，如果任务数据比较多，可以多几个消费者，可以加快消费的速度
3.订阅发布模式，引入了交换机的类型fanout，广播模式 ，每个消费者单独监听自己的对列都可以取消费自己队列的消息。
4.routing，是direct的的交换机类型，指定路由
5.topic,是topic的交换机类型，比路由多了通配符的更加的灵活
完成RabbitMQ消息路由的核心组件是 Exchange。而消息的路由是由Exchange类型 和 Binding 来决定的。Binding 表示建立 Queue 和 Exchange 之间的绑定关系，每一个绑定关系会存在一个 BindingKey。通过这种方式相当于在 Exchange 中建立了一个路由关系表。生产者发送消息的时候，需要声明一个 RoutingKey（路由键），Exchange 拿到RoutingKey 之后，根据 RoutingKey 和路由表里面的 BindingKey 进行匹配，而匹配的规则是通过 Exchange类型来决定的。在 RabbitMQ 中，默认有四种类型的 Exchange：Direct ，Fanout、Topic和Header。
Direct，叫直连，也就是完整匹配方式，需要Routing Key 和 Binding Key 完全一致，相当于点对点的发送。
Topic： 叫主题，这种方式是通过设置通配符来动态匹配，相当于正则。就是用Routing Key 去匹配Binging Key。BingingKey支持两个通配符。
Fanout：叫广播，这种方式不需要设置Routing Key，而是把消息广播给绑定到当前 Exchange 上的所有队列上。
1)拆分多个queue(消息队列)，每个queue(消息队列) 一个consumer(消费者)，就是多一些queue(消息队列)而已，这种方式会比较麻烦；
2)一个queue (消息队列)但是对应一个consumer(消费者)，然后这个consumer(消费者)内部用内存队列做排队，然后分发给底层不同的worker来处理。
首先，必然导致性能的下降，因为写磁盘比写RAM慢的多，message的吞吐量可能有10倍的差距。
其次，message的持久化机制用在RabbitMQ的内置cluster方案时会出现“坑爹”问题。矛盾点在于，若message设置了persistent属性，但queue未设置durable属性，那么当该queue的owner node出现异常后，在未重建该queue前，发往该queue 的message将被 blackholed；若 message 设置了 persistent属性，同时queue也设置了durable属性，那么当queue的owner node异常且无法重启的情况下，则该queue无法在其他node上重建，只能等待其owner node重启后，才能恢复该 queue的使用，而在这段时间内发送给该queue的message将被 blackholed 。
所以，是否要对message进行持久化，需要综合考虑性能需要，以及可能遇到的问题。若想达到100,000 条/秒以上的消息吞吐量（单RabbitMQ服务器），则要么使用其他的方式来确保message的可靠delivery ，要么使用非常快速的存储系统以支持全持久化（例如使用SSD）。
另外一种处理原则是：仅对关键消息作持久化处理（根据业务重要程度），且应该保证关键消息的量不会导致性能瓶颈。
RabbitMQ有三种模式：单机模式、普通集群模式、镜像集群模式。
单机模式就是Demo级别的，一般就是你本地启动了玩玩儿的?，没人生产用单机模式
普通集群模式就是在多台机器上启动多个RabbitMQ实例，每个机器启动一个。你创建的queue，只会放在一个RabbitMQ实例上，但是每个实例都同步queue的元数据。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。
镜像集群模式才是所谓的RabbitMQ的高可用模式。这种模式下，每个RabbitMQ节点都有这个queue的一个完整镜像，包含queue的全部数据的意思。然后每次你写消息到queue的时候，都会自动把消息同步到多个实例的queue上。RabbitMQ有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。这样的好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个queue的完整数据，别的consumer都可以到其它节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！RabbitMQ一个queue的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个queue的完整数据。
官方微信
官方抖音
