1.MQ实现了什么,解耦,异步,削峰
解耦：以接口模式给其他系统发送数据,配置麻烦,系统变动,相关配置就要改变,队列这是生产消费模式,只需要生产,其他系统要消费就自己拿
异步：用户>系统>队列>多个其他系统, 系统只要把请求给了队列,就可以返回给用户，没队列则每个系统都要去请求
削峰：大量并发请求,可以插入队列，让队列平滑请求,减少服务器压力
2.队列的优缺点
可用性降低：加了一层队列,那么多一层风险,
复杂度提高：一致性,不被重复消费,消息可靠传输
一致性：用户>系统>队列>多个其他系统。请求从队列到多个系统,假如其中一个写入失败,数据就不一致
3.如何保证RabbitMQ消息的顺序性?
将原来的一个queue拆分成多个queue，每个queue都有一个自己的consumer。该种方案的核心
是生产者在投递消息的时候根据业务数据关键值（例如订单ID哈希值对订单队列数取模）来将需要
保证先后顺序的同一类数据 发送到同一个queue当中。
4.消息怎么路由
消息提供方->路由->一至多个队列消息发布到交换器时，消息将拥有一个路由键（routing key），
在消息创建时设定。通过队列路由键，可以把队列绑定到交换器上。消息到达交换器后，
RabbitMQ 会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）；
常用的交换器主要分为一下三种：
1. fanout：如果交换器收到消息，将会广播到所有绑定的队列上
2. direct：如果路由键完全匹配，消息就被投递到相应的队列
3. topic：可以使来自不同源头的消息能够到达同一个队列。 使用 topic 交换器时，可以使用通
配符
5.如何保证消息不被重复消费 1..生产时消息重复，2.消费时消息重复。
1.生产消息重复： 生产》mq,mq确认的时候出现网络波动,生产没有收到确认,实际mq已经接收到了消息。
这时候生产就会重发一遍。生产如果消息未被确认,或确认失败,可以使用定时任务+redis/db,来进行消息重试
2.消费成功后,给mq确认出现网络波动,mq没有接收到确认。mq就会继续给消费投递之前的消息,这时候消息着就接收到了两条一样的消息
解决：
1.每个消息带1个全局唯一ID,
2.消费者get到消息后根据id去redis查是否存在 不存在则消费,并写入redis，存在则直接丢弃
6.如何确保消息接收方消费了消息
1.将信道设置成confirm模式,信道会发送1个消息唯一id,
发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到
达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。
接收方确认也是异步的,只有消费者确认了mq才会把消息从队列删除
7.如何保证mq消息丢失
生产者丢失消息
confirm模式：一旦channel进入confirm模式，所有在该信道上发布的消息都将会被指派一个唯一
的ID（从1开始），一旦消息被投递到所有匹配的队列之后；rabbitMQ就会发送一个ACK给生产者
（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了；如果rabbitMQ没能
处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。
消息队列丢数据：
处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。这个持久化配置可以和confirm机制
配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。这样，如果消息持久化磁
盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。
8.mq为什么不应该对所有message使用持久化？
1.必然导致性能下载,持久化是写磁盘的,和写内存相差10倍
所以，是否要对 message 进行持久化，需要综合考虑性能需要，以及可能遇到的问题。若想达到
100,000 条/秒以上的消息吞吐量（单 RabbitMQ 服务器），则要么使用其他的方式来确保
message 的可靠 delivery ，要么使用非常快速的存储系统以支持全持久化（例如使用 SSD）。另
外一种处理原则是：仅对关键消息作持久化处理（根据业务重要程度），且应该保证关键消息的量
不会导致性能瓶颈。
9.如何保证mq的高可用？
mq基于主从模式做高可用,有三种模式：单机,集群,镜像集群
单机一般就是demo，生产基本不会用
普通集群：多台机器多个mq实例(每个机器启动1个mq)。队列只会放在1个mq上,但是每个mq都会同步队列的元数据(队列的一些配置,通过元数据定位到队列所在的实例)。
消费的时候,连接到了另外的mq，那么这个mq就会从队列所在的mq上拉数据过来
提高吞吐量,集群中多个节点服务某个队列的读写操作。
镜像集群模式：
这种模式，才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是，在镜像集群
模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是
说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意
思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。
RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次
创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
这样的好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue
的完整数据，别的 consumer 都可以到其它节点上去消费数据。坏处在于，第一，这个性能
开销也太大了吧，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！RabbitMQ 一
个 queue 的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个 queue 的完整
数据。
10.mq队列满了,消息积压怎么处理？
例：每次消费都写mysql，mysql挂了,消费就不动了,或者消费慢,生产极快
1.修复consumer慢的问题,停掉现有的consumer
2.新建topic放10倍的quenue和10倍的消费者去消费原先的挤压数据,之后回归正常的架构
11.mq设置过期时间,消息过期了怎么办？
1.增加数据库中间表,让它丢失,然后再晚上的时候从中间表找出来重新写进去
12.死信队列
消息被拒（Basic.Reject /Basic.Nack) 且 requeue = false。
消息TTL过期。
队列满了，无法再添加。
1.死信队列的数据,看业务处理
3.rabbitMQ的角色
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代表一个会话
任务
4.RabbitMQ 5种工作模式
1.simple(最简单的收发模式) 消费监听消费队列,有消息就被队列拿走
缺点：消费没被正确取来,消息就消费了造成消息丢失。这里可以设置成 手动的ack,但如果设置成手动ack,处理完后要及时发送ack消息给队列，否则会造成内存溢出
2.work工作模式（资源的竞争）C1 C2共同争抢当前的消息队列内容，谁先拿到谁负责消费消息
缺点：高并发情况下，默认会产生某 一个消息被多个消费者共同使用，可以设置一个开关（syncronize）保证f消息只能被一个消费者使 用）。
3.publish/subscribe发布订阅（共享资源）每个消费者监听自己的队列
生产者将消息发给队列，由交换机将消息转发到绑定此交换机的每个队列，每个绑定交换机的队
列都将接收到消息。
4.routing路由模式 只能匹配上路由key对应的消息队列,对应的消费者才能消费消息
消息生产者将消息发送给交换机按照路由判断,路由是字符串(info) 当前产生的消息携带路由字符(对
象的方法),交换机根据路由的key,只能匹配上路由key对应的消息队列,对应的消费者才能消费消息;
根据业务功能定义路由字符串
从系统的代码逻辑中获取对应的功能字符串,将消息任务扔到对应的队列中。
业务场景:error 通知;EXCEPTION;错误通知的功能;传统意义的错误通知;客户通知;利用key路由,可
以将程序中的错误封装成消息传入到消息队列中,开发者可以自定义消费者,实时接收错误;
5.topic 主题模式(路由模式的一种) 增加匹配功能
* , # 代表通配符* 代表多个单词, # 代表一个单词
路由功能添加模糊匹配
消息产生者产生消息,把消息交给交换机
交换机根据key的规则模糊匹配到对应的队列,由队列的监听消费者接收消息消费
mq选择
1.中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；
2.大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。
3.大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃
度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
|
Active MQ |
RabbitMQ |
RocketMQ |
Kafka |
|
|
单机 吞吐 星 |
万级，比 RocketMQ、 Kafka低一个 数量级 |
同 ActiveMQ |
10万级,支撞高吞吐 |
10万级,高吞吐，一般配合大数据类的 系统来进行实时数据计算、日志采集等场 景 |
|
topic 数星 对吞 吐的影 响 |
|
|
topic可以达到几百/几千的级 另U,吞吐量会有较小幅度的下 降，这是RocketMQ的一大优 势,在同等机器下.可以支撑大 是的topic |
topic从几十到几百个时候，吞吐星会大 幅度下降,在同等机器下，Kafka尽量保 证topic数量不要过多,如果要支撑大规 模的topic ,需要増加更多的机器资源 |
|
时效 性 |
ms级 |
钢级忑 是 RabbitMQ 的一大特 点，延迟最 低 |
ms级 |
延退在ms级以内 |
|
可用 性 |
高,基于主 从给实现 高B用 |
同 ActiveMQ |
非常高,分布式架构 |
非常高，分布式，一个数据多个副本，少 数机器宕机r不会丢失数据，不会导致不 可用 |
|
消息 可靠 性 |
有较低的概 率丢失数据 |
球不丢 |
经过参数优化配置,可以做到0 丢失 |
同 RocketMQ |
|
功能 支持 |
MQ领域的 功能极其完 备 |
基于erlang 开发，并发 能力很强， 性 延时很低 |
MQ功能较为完善，还是分布式 的,扩展性好 |
功能较为简单，主要支持简单的MQ功 能，在大数据领域的实时计算以及日志采 集?Ml模使用 |