消息队列中间件面试笔记总结RabbitMQ，Kafka，RocketMQ

文章目录

[(一) Rabbit MQ](#(一) Rabbit MQ)
- [RabbitMQ 核心概念](#RabbitMQ 核心概念)
- 消息队列的作用
- Exchange(交换器)
- Broker（消息中间件的服务节点）
- 如何保证消息的可靠性
- [如何保证 RabbitMQ 消息的顺序性](#如何保证 RabbitMQ 消息的顺序性)
- [如何保证 RabbitMQ 高可用的？](#如何保证 RabbitMQ 高可用的？)
- 如何解决消息队列的延时以及过期失效问题
- 消息堆积问题怎么解决
[(二) kafka](#(二) kafka)
- Kafka的数据时存储是磁盘中的，为什么可以满足每秒百万级别消息的生产和消费？
- 组件介绍：
[(三) RocketMQ](#(三) RocketMQ)

(一) Rabbit MQ

RabbitMQ 核心概念

消息队列的作用

异步
解耦
削峰

Exchange(交换器)

在 RabbitMQ 中，消息并不是直接被投递到 Queue(消息队列) 中的，中间还必须经过 Exchange(交换器) 这一层，Exchange(交换器) 会把我们的消息分配到对应的 Queue(消息队列) 中。

Exchange(交换器) 用来接收生产者发送的消息并将这些消息路由给服务器中的队列中，如果路由不到，或许会返回给 Producer(生产者) ，或许会被直接丢弃掉。这里可以将 RabbitMQ 中的交换器看作一个简单的实体。

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

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

对于 RabbitMQ 来说，一个 RabbitMQ Broker 可以简单地看作一个 RabbitMQ 服务节点，或者 RabbitMQ 服务实例。大多数情况下也可以将一个 RabbitMQ Broker 看作一台 RabbitMQ 服务器。

下图展示了生产者将消息存入 RabbitMQ Broker,以及消费者从 Broker 中消费数据的整个流程。

这样图 1 中的一些关于 RabbitMQ 的基本概念我们就介绍完毕了，下面再来介绍一下 Exchange Types(交换器类型) 。

如何保证消息的可靠性

消息到 MQ 的过程中搞丢，MQ 自己搞丢，MQ 到消费过程中搞丢。

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

如何保证 RabbitMQ 消息的顺序性

拆分多个 queue(消息队列)，每个 queue(消息队列) 一个 consumer(消费者)，就是多一些 queue (消息队列)而已，确实是麻烦点；
或者就一个 queue (消息队列)但是对应一个 consumer(消费者)，然后这个 consumer(消费者)内部用内存队列做排队，然后分发给底层不同的 worker 来处理。

如何保证 RabbitMQ 高可用的？

RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用性的，我们就以 RabbitMQ 为例子讲解第一种 MQ 的高可用性怎么实现。RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。

普通集群模式

意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你创建的 queue，只会放在一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。

你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。

镜像集群模式

在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。

好处

你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它节点上去消费数据。

坏处

第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！RabbitMQ 一个 queue 的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个 queue 的完整数据。

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

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

消息堆积问题怎么解决

我在实际的开发中，没遇到过这种情况，不过，如果发生了堆积的问题，解决方案也所有很多的

第一:提高消费者的消费能力 ,可以使用多线程消费任务

第二：增加更多消费者，提高消费速度，使用工作队列模式, 设置多个消费者消费消费同一个队列中的消息

第三：扩大队列容积，提高堆积上限，可以使用RabbitMQ惰性队列，惰性队列的好处主要是

①接收到消息后直接存入磁盘而非内存

②消费者要消费消息时才会从磁盘中读取并加载到内存

③支持数百万条的消息存储

(二) kafka

Kafka 是一个高吞吐量的、持久性的、分布式发布订阅消息系统

高吞吐量：可以满足每秒百万级别消息的生产和消费。
Kafka的数据还是放在磁盘里面的，主要是Kafka利用了磁盘顺序读写速度超过内存随机读写速度这个特性。
所以说它的吞吐量才这么高
持久性：有一套完善的消息存储机制，确保数据高效安全的持久化。
分布式：它是基于分布式的扩展、和容错机制；Kafka的数据都会复制到几台服务器上。当某一台机器故障失效时，生产者和消费者切换使用其它的机器。

Kafka的数据时存储是磁盘中的，为什么可以满足每秒百万级别消息的生产和消费？

kafka利用了磁盘顺序读写速度超过内存随机读写速度这个特性。

Kafka主要应用在实时计算领域，可以和Flume、Spark、Flink等框架结合在一块使用

组件介绍：

这个Kafka集群内有两个节点，这些节点在这里我们称之为Broker

Broker：消息的代理，Kafka集群中的一个节点称为一个broker
在Kafka中有Topic的概念
Topic：称为主题，Kafka处理的消息的不同分类(是一个逻辑概念)。
如果把Kafka认为是一个数据库的话，那么Kafka中的Topic就可以认为是一张表，不同的topic中存储不同业务类型的数据，方便使用在Topic内部有partition的概念
Partition：是Topic物理上的分组，一个Topic会被分为1个或者多个partition(分区)，分区个数是在创建topic的时候指定。每个topic都是有分区的，至少1个。
注意：这里面针对partition其实还有副本的概念，主要是为了提供数据的容错性，我们可以在创建Topic的时候指定partition的副本因子是几个。在这里面副本因子其实就是2了，其中一个是Leader，另一个是真正的副本Leader中的这个partition负责接收用户的读写请求，副本partition负责从Leader里面的partiton中同步数据，这样的话，如果后期leader对应的节点宕机了，副本可以切换为leader顶上来。在partition内部还有一个message的概念
Message：我们称之为消息，代表的就是一条数据，它是通信的基本单位，每个消息都属于一个
partition。

(三) RocketMQ

核心概念

NameServer：可以理解为是一个注册中心，主要是用来保存topic路由信息，管理Broker。在NameServer的集群中，NameServer与NameServer之间是没有任何通信的。
Broker：核心的一个角色，主要是用来保存topic的信息，接受生产者产生的消息，持久化消息。在一个Broker集群中，相同的BrokerName可以称为一个Broker组，一个Broker组中,BrokerId为0的为主节点，其它的为从节点。BrokerName和BrokerId是可以在Broker启动时通过配置文件配置的。每个Broker组只存放一部分消息。
生产者：生产消息的一方就是生产者
生产者组：一个生产者组可以有很多生产者，只需要在创建生产者的时候指定生产者组，那么这个生产者就在那个生产者组
消费者：用来消费生产者消息的一方
消费者组：跟生产者一样，每个消费者都有所在的消费者组，一个消费者组可以有很多的消费者，不同的消费者组消费消息是互不影响的。
topic（主题） ：可以理解为一个消息的集合的名字，生产者在发送消息的时候需要指定发到哪个topic下，消费者消费消息的时候也需要知道自己消费的是哪些topic底下的消息。
Tag（子主题） ：比topic低一级，可以用来区分同一topic下的不同业务类型的消息，发送消息的时候也需要指定。

其实对于主题模型的实现来说每个消息中间件的底层设计都是不一样的，就比如 Kafka 中的分区，RocketMQ 中的队列，RabbitMQ 中的 Exchange 。我们可以理解为 主题模型/发布订阅模型 就是一个标准，那些中间件只不过照着这个标准去实现而已。

所以，RocketMQ 中的 主题模型 到底是如何实现的呢？首先我画一张图，大家尝试着去理解一下。

我们可以看到在整个图中有 Producer Group、Topic、Consumer Group 三个角色，我来分别介绍一下他们。

Producer Group 生产者组：代表某一类的生产者，比如我们有多个秒杀系统作为生产者，这多个合在一起就是一个 Producer Group 生产者组，它们一般生产相同的消息。
Consumer Group 消费者组：代表某一类的消费者，比如我们有多个短信系统作为消费者，这多个合在一起就是一个 Consumer Group 消费者组，它们一般消费相同的消息。
Topic 主题：代表一类消息，比如订单消息，物流消息等等。

你可以看到图中生产者组中的生产者会向主题发送消息，而 主题中存在多个队列，生产者每次生产消息之后是指定主题中的某个队列发送消息的。

RocketMQ的架构图

工作流程

Broker启动的时候，会往每台NameServer（因为NameServer之间不通信，所以每台都得注册）注册自己的信息，这些信息包括自己的ip和端口号，自己这台Broker有哪些topic等信息。
Producer在启动之后会跟会NameServer建立连接，定期从NameServer中获取Broker的信息，当发送消息的时候，会根据消息需要发送到哪个topic去找对应的Broker地址，如果有的话，就向这台Broker发送请求；没有找到的话，就看根据是否允许自动创建topic来决定是否发送消息。
Broker在接收到Producer的消息之后，会将消息存起来，持久化，如果有从节点的话，也会主动同步给从节点，实现数据的备份
Consumer启动之后也会跟会NameServer建立连接，定期从NameServer中获取Broker和对应topic的信息，然后根据自己需要订阅的topic信息找到对应的Broker的地址，然后跟Broker建立连接，获取消息，进行消费.