- 可靠性: RabbitMQ使用一些机制来保证可靠性， 如持久化、传输确认及发布确认等。扩展性: 多个RabbitMQ节点可以组成一个集群，也可以根据实际业务情况动态地扩展 集群中节点。管理界面 : RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息、集 群中的节点等。插件机制 : RabbitMQ 提供了许多插件 ， 以实现从多方面进行扩展，当然也可以编写自己的插件。
RabbitMQ就是 AMQP 协议的 Erlang 的实现(当然 RabbitMQ 还支持 STOMP2、 MQTT3 等协议 ) AMQP 的模型架构 和 RabbitMQ 的模型架构是一样的，生产者将消息发送给交换机，交换机和队列进行绑定 。
3.AMQP模型的几大组件？交换器 (Exchange)：消息代理服务器中用于把消息路由到队列的组件。
队列 (Queue)：用来存储消息的数据结构，位于硬盘或内存中。
绑定 (Binding)：一套规则，告知交换器消息应该将消息投递给哪个队列。
- 生产者
消息生产者，就是投递消息的一方。消息一般包含两个部分：消息体（payload)和标签(Label)。
- 消费者
消费消息，也就是接收消息的一方。消费者连接到RabbitMQ服务器，并订阅到队列上。消费消息时只消费消息体，丢弃标签。 5.为什么使用MQ？MQ的优点
异步处理 - 相比于传统的串行、并行方式，提高了系统的吞吐量。
应用解耦 - 系统间通过消息通信，不用关心其他系统的处理。
流量削锋 - 可以通过消息队列长度控制请求量，可以缓解短时间内的高并发请求。
消息通讯 - 消息队列一般都内置了高效的通信机制，因此也可以用在纯消息通讯上。比如实现点对点消息队列，或者聊天室等。
日志处理 - 解决大量日志传输。
- Broker可以看做RabbitMQ的服务节点。一般请下一个Broker可以看做一个RabbitMQ服务器。Queue:RabbitMQ的内部对象，用于存储消息。多个消费者可以订阅同一队列，这时队列中的消息会被平摊（轮询）给多个消费者进行处理。Exchange:生产者将消息发送到交换器，由交换器将消息路由到一个或者多个队列中。当路由不到时，或返回给生产者或直接丢弃。
对不同MQ中间件技术的选型分析。
- 比如说ActiveMQ是老牌的消息中间件，国内很多公司过去运用的还是非常广泛的，功能很强大。
但是问题在于ActiveMQ没法支撑互联网公司的高并发、高负载以及高吞吐的复杂场景，现在在国内互联网公司落地较少。RabbitMQ，
他的好处在于可以支撑高并发、高吞吐量、性能很高，同时有非常完善便捷的后台管理界面可以使用。另外，他还支持集群化、高可用部署架构、消息高可靠支持，功能较为完善。而且经过调研，国内各大互联网公司落地RabbitMQ集群支撑自身业务的case较多，国内各种中小型互联网公司使用RabbitMQ的实践也比较多。除此之外，RabbitMQ的开源社区很活跃，较高频率的版本迭代，来修复发现的bug以及进行各种优化，因此综合考虑过后，公司采取了RabbitMQ。
- 然后可以聊聊RocketMQ
是阿里开源的，经过阿里生产环境的超高并发、高吞吐的考验，性能卓越，同时还支持分布式事务等特殊场景。而且RocketMQ是基于Java语言开发的，适合深入阅读源码，有需要可以站在源码层面解决线上问题，包括源码的二次开发和改造。
- 另外就是Kafka。
Kafka提供的消息中间件的功能明显较少一些，相对上述几款MQ中间件要少很多。但是Kafka的优势在于专为超高吞吐量的实时日志采集、实时数据同步、实时数据计算等场景。 8.Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？
| 项目 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 比RabbitMQ低 | 2.6w/s（消息做持久化） | 11.6w/s | 17.3w/s |
| 开发语言 | Java | Erlang | Java | Scala/Java |
| 主要维护者 | Apache | Mozilla/Spring | Alibaba | Apache |
| 成熟度 | 成熟 | 成熟 | 开源版本不够成熟 | 比较成熟 |
| 订阅形式 | 点对点(p2p)、广播（发布-订阅） | 提供了4种：direct, topic ,Headers和fanout。fanout就是广播模式 | 基于topic/messageTag以及按照消息类型、属性进行正则匹配的发布订阅模式 | 基于topic以及按照topic进行正则匹配的发布订阅模式 |
| 持久化 | 支持少量堆积 | 支持少量堆积 | 支持大量堆积 | 支持大量堆积 |
| 顺序消息 | 不支持 | 不支持 | 支持 | 支持 |
| 性能稳定性 | 好 | 好 | 一般 | 较差 |
| 集群方式 | 支持简单集群模式，比如’主-备’，对高级集群模式支持不好。 | 支持简单集群，'复制’模式，对高级集群模式支持不好。 | 常用 多对’Master-Slave’ 模式，开源版本需手动切换Slave变成Maste | 天然的‘Leader-Slave’无状态集群，每台服务器既是Master也是Slave |
| 管理界面 | 一般 | 较好 | 一般 | 无 |
消息积压的直接原因，一定是系统中某个部分出现了性能问题，来不及处理上游发送的消息，才会导致消息积压。
- 从两个方面开始考虑：
一个是生产者生产的消息过快，导致消费者消费不及时二是消费者出现异常，导致一直无法接收新的消息
- 设置消息过期时间，过期后转入死信队列，写一个程序处理死信消息（重新如队列或者即使处理或记录到数据库延后处理）考虑使用队列最大长度限制
丢失又分为：生产者丢失消息、消息列表丢失消息、消费者丢失消息；
- 生产者的解决策略
开启事务（同步操作，影响性能，吞吐量下降），发送消息前，开启事务（channel.txSelect()），然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()），如果发送成功则提交事务（channel.txCommit()）生产者确认模式，所有在该信道上发布的消息都将会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后，rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就代表成功将消息发送到队列中了；如果rabbitMQ没能处理该消息，则会发送一个Nack消息给你，生产者可以进行重试操作。
- 队列的解决策略
处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。
这个持久化配置可以和/confirm/i机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。
这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。消费者的解决策略
消费者在收到消息之后，处理消息之前，会自动回复RabbitMQ已收到消息；
如果这时处理消息失败，就会丢失该消息；
解决方案：处理消息成功后，手动回复确认消息。最终
11.2 工作模式一个生产者，一个消费者。生产者将消息发送到队列，消费者监听消息队列，如果队列中有消息，就进行消费，消费后消息从队列中删除
11.3 发布订阅模式原理：一个生产者，多个消费者，一条消息只能被一个消费者消费。生产者将消息发送到消息队列，多个消费者同时监听一个队列，谁先抢到消息谁负责消费。这样就形成了资源竞争，谁的资源空闲大，争抢到的可能性就大。
11.4 路由模式一个生产者，多个消费者，每个消费者都可以收到相同的消息。生产者将消息发送到交换机，交换机类型是fanout，不同的队列注册到交换机上，不同的消费者监听不同的队列，所有消费者都会收到消息。
11.5 主题模式生产者将消息发送给交换机，消息携带具体的routingkey。交换机类型是direct，交换机匹配与之绑定的队列的routingkey，分发到不同的队列上。
路由模式的一种，交换机类型是topic，路由功能添加了模糊匹配。星号（*）代表1个单词，#号（#）代表一个或多个单词。
