面经：消息队列

1. RabbitMQ特点

• 可靠性: RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认及发布确认等。
• 灵活的路由 : 在消息进入队列之前，通过交换器来路由消息。对于典型的路由功能， RabbitMQ己经提供了一些内置的交换器来实现。针对更复杂的路由功能，可以将多个交换器绑定在一起， 也可以通过插件机制来实现自己的交换器。
• 扩展性: 多个 RabbitMQ 节点可以组成一个集群，也可以根据实际业务情况动态地扩展集群中节点。
• 高可用性: 队列可以在集群中的机器上设置镜像，使得在部分节点出现问题的情况下队 列仍然可用。
• 多种协议: RabbitMQ 除了原生支持 AMQP 协议，还支持 STOMP， MQTT 等多种消息 中间件协议。
• 多语言客户端： RabbitMQ 几乎支持所有常用语言，比如 Java、 Python、 Ruby、 PHP、 C#、JavaScript 等。
• 管理界面 : RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息、集 群中的节点等。
• 插件机制 : RabbitMQ 提供了许多插件 ， 以实现从多方面进行扩展，当然也可以编写自 己的插件。

2. 如何保证消息的可靠性(防止消息丢失) ***

1. 消息到 MQ 的过程中搞丢（生产者到 RabbitMQ）
   事务机制和 Confirm 机制，注意：事务机制和 Confirm 机制是互斥的，两者不能共存，会导致 RabbitMQ 报错。
2. MQ 自己搞丢（RabbitMQ 自身）
   持久化、集群、普通模式、镜像模式
3. MQ 到消费过程中搞丢（RabbitMQ 到消费者）
   basicAck 机制、死信队列、消息补偿机制。

3. RabbitMQ消息的顺序性 ***

添加链接描述

• 出现顺序性问题的原因
  1个queue多个消息者
  
  消费者里面多线程操作
  

• 解决方案
  拆分多个 queue(消息队列)，每个 queue(消息队列) 一个 consumer(消费者)，就是多一些 queue (消息队列)而已，确实是麻烦点
  

或者就一个 queue (消息队列)但是对应一个 consumer(消费者)，然后这个 consumer(消费者)内部用内存队列做排队，然后分发给底层不同的 worker 来处理。

4. 实现RabbitMQ的高可用性

RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。

• 单机模式

• 普通集群模式
  多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你创建的 queue，只会放在一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据(元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例)。
  你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。

• 镜像集群模式
  在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。这样的好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！RabbitMQ 一个 queue 的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个 queue 的完整数据。

5. 如何解决消息队列的延时以及过期失效问题？

RabbtiMQ 是可以设置过期时间的，也就是 TTL。如果消息在 queue 中积压超过一定的时间就会被 RabbitMQ 给清理掉，这个数据就没了。这就不是说数据会大量积压在 mq 里，而是大量的数据会直接搞丢。
我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上 12 点以后，用户都睡觉了。这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入 mq 里面去，把白天丢的数据给他补回来。也只能是这样了。假设 1 万个订单积压在 mq 里面，没有处理，其中 1000 个订单都丢了，你只能手动写程序把那 1000 个订单给查出来，手动发到 mq 里去再补一次。

6. RabbitMQ死信队列

• 定义
  DLX，全称为 Dead-Letter-Exchange，死信交换器，死信邮箱。当消息在一个队列中变成死信(顾名思义就是无法被消费的消息)之后，它能被重新被发送到另一个交换器中，这个交换器就是 DLX，绑定 DLX 的队列就称之为死信队列。
• 导致死信的原因
  消息 TTL 过期
  队列达到最大长度(队列满了，无法再添加数据到 mq 中)
  消息被拒绝(basic.reject 或 basic.nack)并且 requeue=false.
• 应用
  为了保证订单业务的消息数据不丢失，需要使用到 RabbitMQ 的死信队列机制，当消息消费发生异常时，将消息投入死信队列中.还有比如说: 用户在商城下单成功并点击去支付后在指定时间未支付时自动失效

7. RabbitMQ延迟队列

• 定义
  延迟队列指的是存储对应的延迟消息，消息被发送以后，并不想让消费者立刻拿到消息，而是等待特定时间后，消费者才能拿到这个消息进行消费。

• 实现方式

• 死信队列 + TTL过期时间
  
  优化，避免新增一个时间就新增一个队列，在生产端设置TTL
  

• 插件实现

8.RabbitMQ的工作模式 ***

• 简单模式
  只有一个队列
• work 工作模式
  生产者->多个队列->消费者，没有交换机
• pub/sub 发布订阅模式
  生产者->交换机->（多个）队列->消费者
• Routing 路由模式
  1、每个消费者监听自己的队列，并且设置routingkey。
  2、生产者将消息发给交换机，由交换机根据routingkey来转发消息到指定的队列。
• Topic 主题模式
  1、每个消费者监听自己的队列，并且设置带统配符的routingkey。
  2、生产者将消息发给broker，由交换机根据routingkey来转发消息到指定的队列。
  

9. RabbitMQ消息如何传输

由于 TCP 链接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈，所以 RabbitMQ 使用信道的方式来传输数据。信道（Channel）是生产者、消费者与 RabbitMQ 通信的渠道，信道是建立在 TCP 链接上的虚拟链接，且每条 TCP 链接上的信道数量没有限制。就是说 RabbitMQ 在一条 TCP 链接上建立成百上千个信道来达到多个线程处理，这个 TCP 被多个线程共享，每个信道在 RabbitMQ 都有唯一的 ID，保证了信道私有性，每个信道对应一个线程使用。

10. 核心概念

10.1 生产者和消费者

10.2 交换器和消息队列

RabbitMQ 的 Exchange(交换器) 有 4 种类型，不同的类型对应着不同的路由策略：direct(默认)，fanout, topic, 和 headers，

10.3 Broker（消息中间件的服务节点）

• Broker：可以看做 RabbitMQ 的服务节点。一般请下一个 Broker 可以看做一个 RabbitMQ 服务器。
• Queue :RabbitMQ的内部对象，用于存储消息。多个消费者可以订阅同一队列，这时队列中的消息会被平摊（轮询）给多个消费者进行处理。
• Exchange : 生产者将消息发送到交换器，由交换器将消息路由到一个或者多个队列中。当路由不到时，或返回给生产者或直接丢弃。

10.4 AMQP协议

RabbitMQ 就是 AMQP 协议的 Erlang 的实现(当然 RabbitMQ 还支持 STOMP2、 MQTT3 等协议 ) AMQP 的模型架构 和 RabbitMQ 的模型架构是一样的，生产者将消息发送给交换器，交换器和队列绑定 。

• AMQP 协议的三层
  Module Layer:协议最高层，主要定义了一些客户端调用的命令，客户端可以用这些命令实现自己的业务逻辑。
  Session Layer:中间层，主要负责客户端命令发送给服务器，再将服务端应答返回客户端，提供可靠性同步机制和错误处理。TransportLayer:最底层，主要传输二进制数据流，提供帧的处理、信道服用、错误检测和数据表示等

• AMQP 模型的三大组件
  交换器 (Exchange)：消息代理服务器中用于把消息路由到队列的组件。
  队列 (Queue)：用来存储消息的数据结构，位于硬盘或内存中。
  绑定 (Binding)：一套规则，告知交换器消息应该将消息投递给哪个队列。

11. RabbitMQ如何解决消息堆积 ***

• 提高消费者处理速度
  消费者处理速度是由业务代码决定的，所以我们能做的事情包括：尽可能优化业务代码，提高业务性能。接收到消息后，开启线程池，并发处理多个消息。
  优点：成本低，改改代码即可；
  缺点：开启线程池会带来额外的性能开销，对于高频、低时延的任务不合适。推荐任务执行周期较长的业务。
• 增加更多消费者
  一个队列绑定多个消费者，共同争抢任务，自然可以提供消息处理的速度。
  优点：能用钱解决的问题都不是问题。实现简单粗暴；
  缺点：问题是没有钱。成本太高。
• 增加队列消息存储上限
  在RabbitMQ的1.8版本后，加入了新的队列模式：Lazy Queue。
  这种队列不会将消息保存在内存中，而是在收到消息后直接写入磁盘中，理论上没有存储上限。可以解决消息堆积问题。
  优点：磁盘存储更安全；存储无上限；避免内存存储带来的Page Out问题，性能更稳定；
  缺点：磁盘存储受到IO性能的限制，消息时效性不如内存模式，但影响不大。

12. 如何保证消息不被重复消费？或者说，如何保证消息消费的幂等性？ ***

• 重复消费的原因
  正常情况，消费完毕，RabbitMQ会回复一个确认消息给消息队列，消息队列就把这个消息删除了，但是因为宕机或者网络导致确认消息没返回成功，消息队列不知道自己消费过该消息，会将消息再次分发。
• 解决方案
  让每个消息携带一个全局的唯一ID，即可保证消息的幂等性，具体消费过程为：
  消费者获取到消息后先根据id去查询redis/db是否存在该消息
  如果不存在，则正常消费，消费完毕后写入redis/db
  如果存在，则证明消息被消费过，直接丢弃。

13. RabbitMQ RocketMQ Kaffa对比

• RabbitMQ
  是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
  

• Kaffa
  

• RocketMQ
  RocketMQ出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进。
  
  RabbitMQ适用于需要可靠消息传递和灵活消息模型的场景，具有丰富的插件和社区支持。
  Kafka适用于高吞吐量、低延迟的实时数据处理和事件驱动架构场景，具有良好的可伸缩性和持久性。
  RocketMQ适用于高性能、高可用性的消息传递场景，具有丰富的消息过滤和分布式事务特性。

14. MQ有什么用？

• 解耦
  使用消息队列避免模块间的直接调用。将所需共享的数据放在消息队列中，对于新增的业务模块，只要对该类消息感兴趣就可以订阅该消息，对原有系统无影响，降低各个模块的耦合度，提高系统可扩展性
• 异步
  消息队列提供了异步处理机制，在很多时候应用不需要立即处理消息，允许应用把一些消息放入中间件中，不立即处理，而是在之后需要的时候慢慢处理。
• 削峰
  访问量骤增的场景下，为了保证系统的平稳性，使用消息队列可以使关键组件支撑突发访问压力，不会因为超负荷而请求完全崩溃。高峰期的消息可以被积压起来，在随后的时间内进行平滑处理完成，不至于让系统短时间内无法承载而导致崩溃。在电商网站的秒杀抢购这种突发性流量很强的业务中，消息队列的强大缓冲能力可以起到削峰的作用。