MQ面试知识点

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

子主题

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

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

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

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

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

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

 

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

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

如何保证消息的顺序性？

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

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

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

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

span style=\"font-size: inherit;\

区别

消息模式

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

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

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

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

基本结构

获取连接工厂

使用连接工厂创建连接

从链接创建会话

获取destination

创建producer或者创建producer创建message

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

发送或接收message

关闭资源

基本使用步骤

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

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

注意点

activeMq入门

ActiveMQ

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

异步处理

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

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

应用场景

broker：RabitMq server 消息服务器

producer 与consumer 生产者与消费者

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

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

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

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

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

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

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

消息工作模式

单机模式

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

普通集群模式

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

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

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

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

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

三个模式

RabbitMQ

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

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

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

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

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

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

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

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

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

主要组成模块

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

基本组成

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

助于保持代码整洁一致

简化MQ提供的查询系统

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

一个topic可以有多个queue

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

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

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

消息结构

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

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

事务消息

顺序消息

延迟消息

消息类型

RocketMQ

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

消息

批次

主题

分区partition

生产者

消费者

消费者群组

偏移量

broker

broker集群

副本fllower

重平衡

基本术语

高吞吐，低延时

高伸缩性

持久性，可靠性

高并发

特性

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

传递消息

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

日志记录

限流削峰

使用场景

点对对模式

发布订阅模式

工作模式

Kafka

。。。。左边哪些点思考

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

解耦，各服务之间不在偶合，可以专门处理自己的业务，无须顾及其他系统

异步，主系统处理完毕即可返回，提高性能，提高用户体验

削峰，比如一定时间内系统有大量请求需要处理，而本身系统比如数据库只能处理一定数量的请求，这时候MQ可以杠住上千万的并发，而系统后台依然可以按照自己能力范围的指标进行处理请求，等待流量高峰过去，系统依然在处理，并不会导致系统短时间崩掉

优点

高可用被限制，一旦MQ出问题，整个系统将不可用

系统复杂都变高，定位问题困难

缺点

MQ消息队列