MQ面试知识点
2023-08-08 19:44:10 0 举报
AI智能生成
消息队列知识汇总
作者其他创作
大纲/内容
如何保证消息不被重复消费?
子主题
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消息队列
0 条评论
回复 删除
下一页