太原网站优化教程,建设厅科技中心网站首页,阿里模板网站建设,适合做网页的主题在本篇文章中#xff0c;主要是介绍RabbitMQ一些常见的面试题。对于前几篇文章的代码#xff0c;都已经在码云中给出#xff0c;链接是mq-test: 学习RabbitMQ的一些简单案例 (gitee.com)#xff0c;如果存在问题的话欢迎各位提出#xff0c;望共同进步。 MQ的作用以及应用… 在本篇文章中主要是介绍RabbitMQ一些常见的面试题。对于前几篇文章的代码都已经在码云中给出链接是mq-test: 学习RabbitMQ的一些简单案例 (gitee.com)如果存在问题的话欢迎各位提出望共同进步。 MQ的作用以及应用场景
简单来说MQ的全称是Message Queue消息队列因此MQ的作用就是接收消息和发送消息。具体来说MQ就是一种应用程序间的通信方法它允许组件以异步的方式进行交互在不同的应用场景下发挥着不同的作用。
常见的应用场景有异步解耦、削谷削峰、消息分发、延迟通知、异步通信等。
具体介绍见【RabbitMQ】概述一文。
不同MQ的区别
业界也有许多MQ的产品例如Kafka、RabbitMQ、RocketMQ等。
Kafka一开始是作为日志收集和传输追求高吞吐量性能卓越。单机吞吐量一般可达十万级在日志领域较为成熟。但是功能比较简单只支持简单的MQ功能。适合大数据处理、实时分析、日志聚合等应用场景。
RabbitMQ是采用Erlang语言开发功能较为完善几乎支持所有的主流语言开源提供的界面非常友好性能较好单机吞吐量一般可达万级社区活跃度较高文档更新频繁。比较适合中小型公司数据量没那么大、并且并发没那么高的场景。
RocketMQ是阿里巴巴开源的一款消息队列后来捐赠给Apache公司采用Java语言开发。在可用性、可靠性以及稳定性方面都非常出色吞吐量可达十万级在阿里巴巴内部广泛使用。但是支持的语言并不多产品较新文档较少并且社区活跃度一般。适合于大规模分布式系统而且可靠性要求较高的场景比如互联网金融。
具体介绍见【RabbitMQ】概述一文。
RabbitMQ的核心概念 核心概念这一问题可以大概构建上述图形来简单进行介绍我习惯先介绍生产者、消费者然后再介绍连接、信道最后介绍Broker以及其中的内容VirtualHost、Exchange、Queue。
Producer生产者是RabbitMQ Server的客户端向RabbitMQ Server发送消息。Consumer消费者是RabbitMQ Server的客户端从RabbitMQ Server接收消息。Connection连接是RabbitMQ Server和客户端之间的一个TCP连接该连接是客户端和服务端之间发送消息的基础他负责传输客户端和服务端之间的所有数据和控制信息。Channel信道、通道信道是连接之上的一个抽象层。在一个连接中有多个信道每个信道都是独立的虚拟连接消息的发送和接收就是基于信道的。信道的主要作用是将消息的读写操作复用到同一个TCP连接上这样就可以减少建立连接和关闭连接的开销提高性能。Broker本质上就是RabbitMQ Server这个服务端实例主要用来接收和发送消息。VirtualHost虚拟主机虚拟主机是一个虚拟概念他为消息队列提供了一种逻辑上的隔离机制。对于一个RabbitMQ Server而言可以存在多个虚拟主机。当多个不同的用户需要同一个Rabbit Server提供的服务时可以划分出多个虚拟主机。每个用户在自己的虚拟主机上创建交换机、队列即可。Exchange交换机消息到达Broker的第一站她负责接收消息并且根据路由规则把消息路由到对应的消息队列中。交换机起到了消息路由的作用她根据交换机的规则和类型来确认如何转发接收到的消息。Queue队列用于存储消息。
具体介绍见【RabbitMQ】概述一文。
RabbitMQ的工作流程
发送消息生产者生成了一条消息。创建连接生产者和RabbitMQ Server之间创建连接并且开启一个信道。声明交换机、队列以及绑定关系生产者声明一个队列用来存放消息生产者声明一个交换机用来路由消息生产者指定一个绑定规则使得消息从交换机成功路由到队列中。发送消息生产者将消息发送给RabbitMQ Server。消息存储RabbitMQ Server接收到消息之后根据路由规则存入相应的队列中。如果未找到相应的队列根据生产者的配置选择丢弃或者回退给生产者。消费消息消费者监听队列当消息到达时从队列中获取消息。处理后向Rabbit Server发送消息确认。删除消息RabbitMQ Server接收到消费者的确认ACK之后从队列中把消息删除。
具体介绍见【RabbitMQ】概述一文。
RabbitMQ如何保证消息的可靠性
如何保证消息的可靠性就要看消息在传输过程中哪里出现了问题。大致分为三个方面第一个是从生产者到交换机、再到队列的过程第二个是RabbitMQ Server内部第三个是从RabbitMQ Server内部到消费者的过程。RabbitMQ对这三种情况分别推出了三种解决方案发送方确认、持久化以及消息确认。
发送方确认有两种模式第一个是confirm模式保证的是从生产者到交换机过程中的消息可靠性。第二个是return模式保证的是从交换机到队列的消息可靠性。
持久化有三种方式分别是交换机持久化、队列持久化以及消息持久化。在三个持久化中主要注意的是队列持久化和消息持久化如果消息持久化了但是队列没持久化是没有作用的比较队列都没有消息也没地方放自然持久化也就没有用。
消息确认有两种模式手动确认和自动确认在SpringAMPQ中则是有三种策略可以选择NONE、AUTO、MANUAL。在MANUAL中又有三种机制可供选择分别是接收、拒绝以及批量拒绝。
具体介绍见【RabbitMQ】可靠性传输一文。
RabbitMQ如何保证消息的顺序性
RabbitMQ中顺序性指的是生产者生产消息的顺序为msg1、msg2、msg3那么消费者消费消息的顺序也应该依次为msg1、msg2、msg3。顺序性保障分为局部顺序性保障和全局顺序性保障。存在的解决方案有单队列单消费者、分区消费、消息确认、业务逻辑控制例如消费端内部实现消息排序逻辑等。
具体介绍见【RabbitMQ】幂等性、顺序性一文。
RabbitMQ如何保证消息的幂等性
RabbitMQ中幂等性指的是一条消息多次消费对系统产生的影响是相同的。
在消息传递过程中消息传输保证被分为最少一次、恰好一次、最多一次。RabbitMQ并不支持恰好一次在业务场景比较重要的情况下建议使用最少一次但是在一些特殊场景下例如消息从生产者发送出去之后出现网络故障导致服务端没有及时返回确认机制或者消息从服务端到消费者消费之后并没有返回确认通知会导致消息重复发送从而出现一些比较严重的问题对于最多一次来说则会因为网络宕机等故障导致消息丢失。
一般在比较重要的业务下我们都是以最少一次这种方式但是如果出现消息重复传输的话就会导致消息多次消费因此我们为了保证幂等性就需要一些解决方案。常见的解决方案有
使用唯一标识符来标识每一条消息使用业务逻辑判断来确认消息是否消费
具体介绍见【RabbitMQ】幂等性、顺序性一文。
RabbitMQ有哪些特性
消息可靠性传输 发送方确认持久化消息确认死信队列延迟队列重试机制TTL
具体介绍见【RabbitMQ】系列。
介绍下RabbitMQ的死信队列
死信表示一系列无法被消费的消息。存在死信就存在死信队列。当一个消息在队列中变成死信之后就会通过死信交换机进入死信队列这就是死信队列的由来。
例如队列中的消息超过最大长度、消息的TTL超时、手动确认机制下拒绝并且不予重新入队等等都会被路由到死信队列中。
死信队列的应用场景有消息重试将错误的消息放入死信队列中进行重试、日志分析将死信队列中的消息进行收集用户日志分析、消息丢弃将死信队列中的消息丢弃避免占用资源。
具体介绍见【RabbitMQ】死信队列、延迟队列一文。
介绍下RabbitMQ的延迟队列
延迟队列表示消息从生产者到达RabbitMQ Server之后并不是立即到达消费者进行消费而是经过一段时间之后再推送到消费者。
延迟队列的实现方式有两种
TTL 死信队列注意这里的TTL必须要设置队列的而不是消息的。使用延迟队列插件。
延迟队列的应用场景有
十五分钟未支付订单取消预定会议开始前十五分钟进行通知手机遥控两个小时之后家电开始工作用户注册成功之后三天后发送通知提供用户活跃度用户发起退款24小时之后商家没有行动自动退款
具体介绍见【RabbitMQ】死信队列、延迟队列一文。
介绍下RabbitMQ的工作模式
RabbitMQ有七种工作模式分别是
简单模式Simple工作队列模式Work Queue发布订阅模式Publish / Subscribe路由模式Routing通配符模式TopicsRPC模式RPC发布确认模式Publisher Confirms
具体介绍见【RabbitMQ】工作模式一文。
消息积压
消息积压指的是生产者生产消息的速度已经远远超过了消费者消费消息的速度从而导致了消息在队列中发生了积压。
导致消息积压的原因无非就是软件和硬件的原因。对于软件来说就是生产者生产速度太快、而消费者消费速度太慢对于硬件来说就是网络延迟、RabbitMQ服务器配置太低等原因。
想要解决消息积压就是针对产生的问题进行分别解决。对于软件来说就是提高消费者消费速率、降低生产者生产速率对于硬件来说就是增加服务器配置、优化参数等方案。
具体介绍见【RabbitMQ】消息积压、推拉模式一文。
推拉模式
推拉模式是RabbitMQ中向消费者发送消息的两种模式。推模式表示的是消息到达服务器之后根据消费者监听的队列将消息推送给消费者进行消费。拉模式表示的是消息到达服务器之后消费者主动去服务器拉取消息进行消费。
对于一般的业务来说采取的都是推模式进行工作其适合数据实时性要求较高的场景。拉模式则是适合消费消息时需要大量资源的的任务拉模式允许消费者准备好之后再去进行消费可以减少资源的浪费。
具体介绍见【RabbitMQ】消息积压、推拉模式一文。 到这里RabbitMQ的介绍就基本结束了其中缺的一个内容就是分布式部署有机会的话后续进行介绍。 总的来说在RabbitMQ这个系列中先进行了一个概述然后对工作模式简单介绍后续是对高级特性可靠性保证、TTL、重试机制、延迟队列、死信队列、事务、消息分发、幂等性、顺序性、消息积压以及推拉模式进行了介绍最后对一些场景面试题进行了概述。 下一个系列文章是微服务组件欢迎大家给出修改意见共同进步。
