RabbitMQ面试那点事儿

最新推荐文章于 2024-09-08 10:58:26 发布

Amos zhu

最新推荐文章于 2024-09-08 10:58:26 发布

阅读量408

点赞数 1

分类专栏： RabbitMQ 文章标签： rabbitMQ

本文链接：https://blog.csdn.net/wdcl2468/article/details/96449029

版权

RabbitMQ 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

简单的整理RabbitMQ的相关的知识，我们初步了解了RabbitMQ的相关知识，那么我们怎么在我们的工作中使用RabbitMQ呢，使用RabbitMQ应该需要注意哪些问题。我们以面试题的方法来展示，不过本次的题目不包括集群和高可用方便的，这个等我梳理集群和高可用的相关知识后再整理对应的面试题

本博文参考网上很多关于RabbitMQ的经典面试题，整理归纳并加上自己的理解，意在梳理自己对RabbitMQ的理解以及更好地帮助广大的码友们，如有错误，敬请指正

1. RabbitMQ的实用优点

总得来说，有三大确实的好处

应用解耦

举例说明：有这样一个业务场景：我们在网上购买一件商品，支付成功之后库存要减少一，如果是传统的软件架构中，必须是先支付，然后再减少库存，这两个操作必须是在同一事务中，即操作原子性，但是这样做的话效率是极其低下的，如果使用RabbitMQ的话，我们需要将消息发送给各自的队列来进行消息处理，支付和库存的操作之间没有了关联性，这样支付系统和库存系统之间就进行了解耦。

流量削峰

rabbitMQ可以使用缓冲队列的方式，在访问量急剧增大的时候，减少并发访问的压力，比较常见的业务场景就是秒杀和签到系统，一般来说流量的削峰有两个处理方式：

上游队列缓冲，限速发送
下游队列缓冲，限速执行

当然，常见的场景是采用第二种方式，不影响客户使用的响应速度和使用体验等，

我们知道RabbitMQ中消息是通过信道Channel来传给对应的队列的，而消费端监听这个队列处理其中的消息也是有处理时间的，这时我们需要解决的就是如果队列上有一定数量的消息未被确认，则不进行新的消息的消费

rabbitMQ提供channel.basicQos方法来限制信道上的消费者所能保持的最大未确认消息的数量，说到未确认，我们需要先知道RabbitMQ为了保证消息可靠的到达消费者那里，提供了消息确认机制，通过autoAck参数来控制，如果autoAck为true，默认消息消费者自动确认消息，此时消息可能未被处理结束，如果autoAck为false的话，则需要消费者手动来确认消息

结合上面两点，我们可以利用rabbitMQ在服务的下游来限速执行达到流量削峰的目的

异步处理

很多的业务场景中，需要发出一个指示，但是并不要求立即执行，可能对什么时候执行，或者只要执行就可以了有不同的需求，而对象这样的RabbitMQ提供不同的解决方法，用户发送发送的消息储存在RabbitMQ中，由rabbitMQ传递给消费者来进行消费，也可以通过死信队列来实现延迟队列的效果，让消息定时被消费等等。

当然RabbitMQ还有很多其他的好处，比如：很容易实现集群环境的搭建，能定制路由设置消息传递的规则以及消息分发和消息缓冲等优点

2. 消息基于什么传输，这样做有什么优点？

RabbitMQ是基于信道Channel的方式来传输数据，排除了使用TCP链接来进行数据的传输，因为TCP链接创建和销毁对于系统性能的开销比较大，且并发能力受系统资源的限制，这样很容易造成rabbitMQ的性能瓶颈。

消费者链接RabbitMQ其实就是一个TCP链接，一旦链接创建成功之后，就会基于链接创建Channel，每个线程把持一个Channel,Channel复用TCP链接，减少了系统创建和销毁链接的消耗，提高了性能

3. 如何确保消息正确的发送到RabbitMQ

发送方发送消息到RabbitMQ，有可能发送失败，失败的原因有如下的可能:

交换器无法根据自身的类型和路由键匹配到队列（mandatory）
当与路由键匹配的所有队列都没有消费者时（延时队列和死信队列）

对于上面的情况，RabbitMQ提供发送方确认机制来去报消息正确发送到RabbitMQ服务

发送方确认机制是指消息生产者将信道设置成confirm模式，一旦信道进入confirm模式，所有在该信道上发布的消息都会指派一个唯一的id，一旦消息被投递到RabbitMQ服务中国，RabbitMQ就会发送一个确认给生产者。

发送方确认模式是异步的，不影响生成者继续发送消息，可扩展性也就增大了

其实还有另外一种解决方法，发送方如果觉得异步确认对于代码而言变的复杂了，那么可以不设置mandatory

额外补充下，发送方确认其实还有事务机制，主要有如下的方法进行设置：

channel.txSelect: 将当前的Channel设置为事务模式
channel.txCommit: 提交当前的事务
channel.txRollback: 事务回滚
跟数据库的事务比较像，也的确能解决发送方能确认消息是否发送到RabbitMQ中，但是事务机制很耗费性能，所以不提倡使用事务，仅供了解即可

4. 如何确保消息接收方消费消息

消费方通过监听队列，从Channel中获取队列中存储的数据并进行消费——即为消费者订阅队列，可以执行autoAck参数，当autoAck为false时，RabbitMQ会等待消费者显示的回复确认信号之后，才会从内存（或者硬盘）中删除消息。

所以确保消费者消费消息，只需要设置autoAck参数为false即可，这样就确保RabbitMQ会等待消息消费完成之后才删除消息。但是这个特性却衍生出新的问题，如果消费端处理消息失败，没有手动显示回复确认信号，则RabbitMQ不会在内存或硬盘中删除该消息，导致该消息会阻塞在队列中，后续的消息也会被阻塞住导致消息无法消费。

对于上面出现的问题，我们可以使用RabbitMQ提供的补偿机制和死信队列来实现消费失败的消息保存。

rabbitMQ提供配置参数来开启消费者重试机制，也能配置配置最大重试次数和重试间隔时间，rabbitMQ对于消息消费失败达到一定次数后，就会放弃该消息，我们可以手动实现，如果消费失败达到最大重试次数后，将数据转发到死信队列上，由死信队列的消费者来实现消息的持久化到数据库或者日志文件中，一般重试次数我们设置为3此，间隔时间为5s。

也可以消费者手动实现业务层判断，如果同一消息消费了多次，则可以手动拒绝该消息，然后该消息自动进入死信队列，这样基于rabbitMQ的死信队列的特性来自动实现消息的保存，优点是rabbitMQ的封装框架不需要进行额外的代码，性能方面有了保障，缺点是这个工作交给了消费者手动实现。具体的还得看实际业务的需求。

5. 如何避免消息的重复消费和重复投递

在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重和幂等的依据（消息投递失败并重传），避免重复的消息进入队列；在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重和幂等的依据，避免同一条消息被重复消费

6. 消息如何分发（路由）

个人觉的消息分发和消息路由属于同一问题，生产者将消息发送到Exchange上，然后Exchange将消息路由到一个或者多个队列上，如果路由不到，将消息根据发送者确认机制回传给生产者，或者直接丢弃；消费者订阅队列上的消息，以上就是消息的流经的整个流程

生产者链接到RabbitMQ，建立一个Connection，然后基于该Connection开启Channel
生产者声明一个Exchange，并设置相关属性（Exchange类型fanout、direct、topic和headers、是否持久化）
生产者声明一个Queue，并设置相关属性（是否持久化）
生产者将消息发送给Exchange,一般会指定一个RoutingKey，用来指定这个消息的路由规则，而这个RoutingKey需要与Exchange类型和BindingKey联合作用才能最终生效
相应的Exchange根据接收到的消息的路由键查找匹配的队列，如果匹配上将消息发送到队列上，如果查询不到根据发送者确认模式，是否返回给发送者或者丢掉
消费者链接到RabbitMQ，建立一个Connection，然后基于该Connection开启 Channel
消费者订阅队列，根据autoAck是否为false来决定是否手动确认消息
RabbitMQ服务接收到消息确认，删除队列中该消息