RabbitMQ详细介绍及面试高频问题

RabbitMQ

RabbitMQ是基于AMQP的一款消息管理系统

AMQP和JMS两者间的区别和联系：

• JMS是定义了统一的接口，来对消息操作进行统一；AMQP是通过规定协议来统一数据交互的格式
• JMS限定了必须使用Java语言；AMQP只是协议，不规定实现方式，因此是跨语言的。
• JMS规定了两种消息模型；而AMQP的消息模型更加丰富

常见MQ产品 :

• ActiveMQ：基于JMS， Apache
• RabbitMQ：基于AMQP协议，erlang语言开发，稳定性好
• RocketMQ：基于JMS，阿里巴巴产品，目前交由Apache基金会
• Kafka：分布式消息系统，高吞吐量

五种消息模型

基本消息模型

在上图的模型中，有以下概念：

• P：生产者，也就是要发送消息的程序
• C：消费者：消息的接受者，会一直等待消息到来。
• queue：消息队列，图中红色部分。类似一个邮箱，可以缓存消息；生产者向其中投递消息，消费者从其中取出消息。

work消息模型(任务模型)

• P：生产者：任务的发布者
• C1：消费者，领取任务并且完成任务，假设完成速度较慢
• C2：消费者2：领取任务并完成任务，假设完成速度快

当消息处理比较耗时的时候，可能生产消息的速度会远远大于消息的消费速度。长此以往，消息就会堆积越来越多，无法及时处理。此时就可以使用work 模型：让多个消费者绑定到一个队列，共同消费队列中的消息。队列中的消息一旦消费，就会消失，因此任务是不会被重复执行的

能者多劳: 处理消息快的多,多消费消息,在代码中设置basicQos(1),每个消费者只能消费一条

订阅模型分类

Exchange（交换机）只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑定，或者没有符合路由规则的队列，那么消息会丢失！

Fanout：广播 将消息交给所有绑定到交换机的队列

在广播模式下，消息发送流程是这样的：

• 1） 可以有多个消费者
• 2） 每个消费者有自己的queue（队列）
• 3） 每个队列都要绑定到Exchange（交换机）
• 4） 生产者发送的消息，只能发送到交换机，交换机来决定要发给哪个队列，生产者无法决定。
• 5） 交换机把消息发送给绑定过的所有队列
• 6） 队列的消费者都能拿到消息。实现一条消息被多个消费者消费

Direct：定向，把消息交给符合指定routing key 的队列

在Fanout模式中，一条消息，会被所有订阅的队列都消费。但是，在某些场景下，我们希望不同的消息被不同的队列消费。这时就要用到Direct类型的Exchange。

在Direct模型下：

• 队列与交换机的绑定，不能是任意绑定了，而是要指定一个RoutingKey（路由key）

• 消息的发送方在 向 Exchange发送消息时，也必须指定消息的 RoutingKey。

• Exchange不再把消息交给每一个绑定的队列，而是根据消息的Routing Key进行判断，只有队列的Routingkey与消息的 Routing key完全一致，才会接收到消息
  
  图解：

• P：生产者，向Exchange发送消息，发送消息时，会指定一个routing key。

• X：Exchange（交换机），接收生产者的消息，然后把消息递交给 与routing key完全匹配的队列

• C1：消费者，其所在队列指定了需要routing key 为 error 的消息

• C2：消费者，其所在队列指定了需要routing key 为 info、error、warning 的消息

Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列

Topic类型的Exchange与Direct相比，都是可以根据RoutingKey把消息路由到不同的队列。只不过Topic类型Exchange可以让队列在绑定Routing key 的时候使用通配符！

Routingkey 一般都是有一个或多个单词组成，多个单词之间以”.”分割，例如： item.insert

 通配符规则：

#：匹配一个或多个词

*：匹配不多不少恰好1个词



举例：

audit.#：能够匹配audit.irs.corporate 或者 audit.irs

audit.*：只能匹配audit.irs

解释：

• 红色Queue：绑定的是usa.# ，因此凡是以 usa.开头的routing key 都会被匹配到
• 黄色Queue：绑定的是#.news ，因此凡是以 .news结尾的 routing key 都会被匹配

面试总结：

面试题1：如何解决消息丢失？

• ack（消费者确认）
• 持久化
• 生产者确认（publisher confirm）：生产者发送消息后，等待mq的ACK，如果没有收到或者收到失败信息，则重试。如果收到成功消息则业务结束。
• 可靠消息服务（可选）：对于部分不支持生产者确认的消息队列，可以发送消息前，将消息持久化到数据库，并记录消息状态，后续消息发送、消费等过程都依赖于数据库中消息状态的判断和修改。

面试题2：如何避免消息堆积

• 通过同一个队列多消费者监听，实现消息的争抢，加快消息消费速度。

面试题3：如何保证消息的有序性？

答：大部分业务对消息的有序性要求不高，如果遇到对有序要求较高的业务，分两种情况来处理：

• 业务同时对并发要求不高：
  • 保证消息发送的时候有序性并且同步
  • 保证消息发送被同一个队列接收
  • 保证一个队列只有一个消费者，可以有从机（待机状态），实现高可用。
  • 实现主从: zookeeper实现集群选主
• 业务同时对并发要求较高：
  • 满足上述第一个场景的条件
  • 可以有多个队列
  • 有时序要求的一组消息，通过hash方式分派到一个固定队列

面试题4：如何避免消息重复消费？

• 保证接口幂等即可，那么如何保证接口幂等呢？
  • 某些接口天生幂等，例如查询请求
  • 某些接口天生不幂等，比如新增，还有某些接口的修改功能
    • 能根据具体的业务或状态来确定的，在消费端通过业务判断是否执行过