首页  思维导图  详情

MQ面试知识点

2023-08-08 19:44:10   0  举报





AI智能生成

消息队列知识汇总

Java面试

MQ消息队列

作者其他创作

大纲/内容

如何保证消息不被重复消费？

kafka而言，他有存在一个offset,代表整个消息顺序的序号，按照数据进入kafka的顺序分配一个offset,代表这个数据的序号，每当消费者去消费时，是按照这份顺序去消费的，消费者会去提交offset，就告诉kafka已经消费到了哪条数据了，假如消费者系统被重启，Kafka就会直接根据offset提取下一条消息给消费者，从而保证消息不会被重复消费；但是缺点在于offset不是实时提交的，而是定时定期提交一次offset，所以一旦宕机，就存在offset没有被提交从而也会有数据重复问题，

MQ如何体现高可用的？见左侧

子主题

如何保证消息队列消费的幂等性？

在写库时，同时往内存set种记录一条或者redis中，当拿到重复数据时，先去判断set中是否有该条数据，没有则继续操作

基于数据库表的唯一主键，重复插入则会报错，不会出现脏数据

如何保证消息的可靠性传输（不丢失问题）？

对于rabbitmq而言，写消息时候它支持事务功能，属于同步阻塞等待返回结果，导致生产者发消息吞吐量降下来；施行confirm机制，若rabbitmq收到消息就会回调生产者本地的一个接口，通知消息已经被收到，报错的话，也会回调接口，提示再次重复，吞吐量会高一些

rabbitmq收到消息如何保证不丢在，可以开启rabbitmq持久化到磁盘，但是也会存在丢的可能不是百分百可靠

消费者收到消息就没来得及处理就以已经挂了，就返回autoAck,mq会发送下一条消息，此时保证消息完全被消费要将手动设置autoAck开启关闭，保证消费者消费当前消息

如何保证消息的顺序性？

对于rabbitmq而言，只要保证一个消费者每次消费一个queue即可

如何解决大量消息积压的问题？

基本思想是积压的消息不从原有的消费者进行消费，可以通过改写代码，让消费者的消息重写到新的MQ中，扩大机器规模，比如拥有30各parition的topic中，让他以原有倍数的消费速度重新消费处理写库；如果大量消息设置了过期时间，且无法从消息中拿到，那就只能写代码从数据中获取到丢失的订单消息手动发到mq，让他消费入库了；若消息MQ内存满了，那只有消息不入库可以新建新的MQ写进去的。

ActiveMQ

定义：Apache出品的开源的消息总线，支持JMS规范的实现，容易和spring整合，万级别吞吐量，比rocketMQ和kafaka低一个数量级

消息模式

P2P模式：点对点进行消息生产与消费，通过队列queue作为detination消息载体，一个消息只能被一个consumer消费

Pub/Sub模式：一对多模式，topic作为destination消息载体，多对多的消息通信模式，多个provider发布消息进入topic,只有订阅的consumer才能进行消费，且消息不会被存储，只有订阅者持久化设置才能保存一个消息的副本

区别

点对点模式，消息域使用queue作为destination，消息可以使用同步或者异步方式发送和接收，每个消息只会给一个consumer传递一次。consumer可以使用message Consumer,reciver()同步接收消息也可以使用MessageConsumer.setMessageListener() 注册一个 MessageListener 实现异步接收。多个consumer可以注册到同一个queue上，但是一个消息只能被一个consumer接收，然后由该consumer来确认该消息，并且在这种情况下，provider对所有注册的consumer以轮询的方式发送消息。

发布/订阅模式，消息域使用topic作为destinaiton,发布者向topic发送消息，订阅者来注册接收来自topic的消息。发送到topic的任何消息都将自动传递给所有订阅者，接收方式和P2P相同，同步异步都可以。除非显式指定，否则topic不会为订阅者保留消息。当然，也可以使用持久化duraable订阅来实现消息的保存，这种情况下即使与provider断开，provider会为之存储消息。当持久化订阅者重新连接时候，将会收到所有断联期间未消费的消息

基本结构

provider:纯java语言编写的JMS接口实现

destination：消息被寻址，发送以及接收的对象

domains：消息传递方式，包括点对点，发布订阅模式

conection factory：客户端使用连接工厂来创建与JMS provider的连接

基本使用步骤

获取连接工厂

使用连接工厂创建连接

从链接创建会话

获取destination

创建producer或者创建producer创建message

创建consumer或发送或接收message或创建消息监听器（可选）

发送或接收message

关闭资源

注意点

activeMq在队列存储message时，采用FIFO存储，同一时间一个消息被分派给单个消费者，且只有消息被确认时，才会从队列中删除

对于持久化订阅专来说，每个消费者获得message的副本，为了节省空间，provider仅存储i罅隙的一个副本，持久化订阅者维护了指向下一个消息的指针，并将其副本分派给消费者。

RabbitMQ

定义：是基于erlang语言开发的实现了AMQP协议的消息队列服务器，特点在于保证客观的单机吞吐量,非分布式的普通集群式MQ

应用场景

消息通讯：点对点的聊天系统，或者广播系统，用于将消息传播给大量接收者

异步处理

服务解耦：A调用B的接口，B处于不可用状态，也不会影响A的使用

流量削峰：高并发系统，访问高峰时候，突发的流量如洪水般请求系统，会导致数据库瘫痪，无法继续提供服务

基本结构

broker：RabitMq server 消息服务器

producer 与consumer 生产者与消费者

connection：用于管理Mq的TCP网络连接

channel:是程序与mq打交道的一个接口，大部分业务操作都在channel上完成，包括queue，定义exchange，绑定queue和Exchange,发布消息

Exchange：消息交换机，作用是接受来自生产者的i西澳西，并根据路由键转发到消息绑定的队列

queue：用于存储消息的对象，在生产段，生产者的消息最终发送到指定队列，而消费者也可以订阅某队列来获取消息（元数据《存储的是一些相关的配置信息》和实际数据）

bingding:一种操作，作用于建立消息从Exchange转发到queue的规则，在进行绑定时，需要指定一个bindingKey,binding操作一般用于rabbitMq的路由工作模式和主题工作模式

virtual host :虚拟主机，一个主机下有一组不同的Exchange和queue，不同的虚拟主机的交换器和队列不影响；应用隔离和权限划分，是最小的权限单位划分

消息工作模式

简单（simple）模式：只有一个生产者，一个消费者和一个队列，生产者和消费者发送和接收消息时只需要指定队列名，而不需要指定发送到哪个exchange，MQ会自动使用virtual host的默认exchange，type类型为direct。

工作（work）模式：在simple模式下增加消费者的模式，称为work模式，一对多，发送到队列的消息由服务器平均分配给不同的消费者消费。

发布订阅模式：生产者发送消息时候，不需要指定队列名，Exchange会将收到的消息转发给绑定的队列，type类型为fanout，消息被exchange转到多个队列，一个消息可以被多个消费者获取

路由（routing）模式：type同简单模式，为direct,消息的目标队列由生产者按照routingKey规则指定，消费者通过BindingKey绑定自己所关心的队列；一个消息可以被多个消费者获取；只有routingkey与bindingkey相匹配的队列才收到消息

主题(topic)模式:type为topic,一条消息被多个消费者获取。在路由的基础上，将路由键和某模式进行匹配，其中#表示匹配多词，*表示匹配一个词，消费者可以通过某种模式的bindingkey来达到订阅某个主题消息的目的。

三个模式

单机模式

普通集群模式

缺点：可能会存在大量数据传输；因为只有一台机器有实际数据，而其他只包含元数据，待消费时候，在进行传输

镜像集群模式（高可用支持）

每个节点都会有queue的完整镜像，就是包含queue的全部数据，所以这种集群模式叫做镜像~

高可用体现：任何节点宕机，没问题，其他节点包含了这个queue的完整数据，别的consumer都可以到其他节点上去消费消费数据，都是可行的

缺点：不是分布式的，若queue的数据量超过机器容量，无法解决

开启：只要在后台管理新增一个策略，决定是否启用同步数据来实现高可用与否

RocketMQ

定义：阿里旗下分布式队列模式的消息中间件，前身为MetaQ,开源给了apache，具有高性能，高可靠，高实时，分布式特点

基本组成

nameserver（名称服务器）：提供轻量级的服务发现和路由，nameserver接受来自broker集群的注册，并且提供信号机制以检查broker是否还存在；每个server记录完整的路由信息（borker相关的topic等元信息，并且给producer提供consumer查找broker信息），提供读写服务

broker（消息服务器）：消息存储中心，接收来自producer的消息并存储，consumer从这里取得信息

producer（生产者）：负责产生消息，生产者向消息服务器发送由业务应用系统程序生成的消息；支持分布式部署，分布式生产者通过多种负载平衡将消息发送到broker集群，发送过程支持快速失败并且延迟低；发送方式3种，同步，异步，单向

consumer（消费者）：负责消费消息，消费者从消息服务器拉取消息；也支持推拉模式中的分布式部署，还支持集群使用和消息广播，他提供了实时消息订阅机制，可以满足大多消费者的需求

broker server:负责消息的存储和传递，消息查询和HA高可用

主要组成模块

remoteing module 远程模块：broker入口，处理来自客户端的请求

client manager客户端管理：管理client（生产者、消费者）并且维护消费者的主题订阅

store service 存储服务：提供简单的API中数据库存储或查询消息

HA service 高可用服务：提供master broker 和slave broker之间的数据同步

Index service索引服务：将message建立索引来提供快速查询功能

整体流程

启动nameserver,启动后进行端口监听，等待broker，producer，consumer连上来，相当于一个路由控制中心

broker启动，跟所有nameserver保持长连接，定时发送心跳包，包中包括当前的broker信息（IP+端口）以及存储所有topic信息，注册成功后，naneserver集群中就有topic和broker的映射关系

收发消息前，创建topic。创建topic需要指定topic要存储在哪些broker上，也可在发送消息时候自动创建topic

producer发送消息启动时，先跟nameserver机器中的其中一台建立长连接，并从nameserver中获取当前发送的topic存在于哪些broker上，然后跟对应的broker建立长连接，直接向broker发消息

consumer消费消息，跟其中一台nameserver建立长连接，获取当前订阅topic存在于哪些broker上，然后直接与broker建立连接通道，开始消费i西澳西

消息结构

topic 主题：表示消息的第一级类型，是最细粒度的订阅单位（生产者传递消息和消费者提取消息的标识）

一条消息必须有一个topic

topic一般是领域范围，比如交易消息，积分消息

Tag 标签：表示消息的第二级类型，可以根据使用相同的topic不同的tag来表示同一个业务模块的不同任务的消息，比如交易消息又可分为交易创建消息和交易完成消息

助于保持代码整洁一致

简化MQ提供的查询系统

Message 消息体：消息是要传递的信息，必须包含一个topic,可选Tag和key-vaule键值对

Message queue 消息队列：所有消息队列都是持久化

一个topic可以有多个queue

queue的引入使得消息存储可以分布式集群化，具有水平扩展能力

Group 组：分为producer Group 和consumer Group，具有相同角色组成Group

消息模式

集群式：使用集群模式时，MQ认为任意一条消息只需要被集群内任意一个消费者处理即可

广播模式：使用广播模式时，MQ的每一条消息都会推送给集群内所有注册过的客户端，保证消息至少被每台机器消费一次

消息类型

事务消息

顺序消息

延迟消息

Kafka

定义：分布式，支持多分区，多副本基于zookeeper的分布式消息平台，同时也是一款基于发布订阅模式的消息引擎系统

基本术语

消息

批次

主题

分区partition

生产者

消费者

消费者群组

偏移量

broker

broker集群

副本fllower

重平衡

特性

高吞吐，低延时

高伸缩性

持久性，可靠性

高并发

高可用：体现在分布式下，一个topic下的消息被分区存储在不同的机器上，并且会产生多个副本，通过某种算法会区分出leader和follower产生，当假设有一台机器宕机了，但是此时别的机器上还有follower,此时kafka会给那只到leader的死亡，会选举其他的一个follower作为leaderl来提供消息消费服务

使用场景

活动追踪：比如用来跟踪用户行为，登陆行为，浏览次数，搜索指数

传递消息

度量指标：记录运营监控数据

日志记录

限流削峰

工作模式

点对对模式

发布订阅模式

如何开发一个消息队列中间件，你会怎么设计？

首先MQ需要支持扩容，可有伸缩性，那就可以参照kafka的分布式设计理念，多个partition,保存消息

再其次要考虑ma的可用性，保障高可用则参议类似于kafka设置选举模式，一旦有机器宕机可以重新选择leader,保证消息消费