《消息队列》常问面试题

1、为什么要使用消息队列？（消息队列的应用场景）

这个问题主要考察为什么使用消息队列？在项目中为了解决什么问题？

消息队列的本质

• 消息队列是一种“先进先出”的数据结构

• 常见应用场景：解耦、异步、削峰

解耦

订单系统强依赖“支付系统”、“库存系统”、“物流系统”的返回结果。图一为强耦合关系，图二为消息队列解耦后。

异步

 流量削峰

 

 2、各种消息队列产品的比较？

MQ选型总结

• activeMQ：早期使用较多，没经过大规模吞吐量场景验证，社区不是很活跃，现在使用的不多，不推荐

• RabbitMQ：开发语言使用erlang，对于java开发工程师二次开发门槛较高，但rabbitMQ是开源的，社区活跃度较高，追求性能和稳定性的话，推荐使用。

• 开发语言是java，在阿里内部经受过高并发的考验，稳定性和性能军不错，若考虑二次开发，推荐使用。

• kafka：大数据领域的实时计算、日志采集等场景。用kafka业内的标准，社区活跃，推荐使用。大数据领域、日志采集等业务推荐使用。

3、消息队列的优点和缺点？

优点：解耦、异步、流量削峰

缺点：系统可用性降低、系统复杂性提高、一致性问题

4、如何保证消息队列的高可用性？

rabbitMQ的高可用性

普通集群模式

消息只存贮在mq某个实例上，其他节点从通过queue的元数据从该实例的queue取数据

特点：没有做到真正的高可用；数据拉取开销和单实例的瓶颈问题。

 镜像集群模式

 rocketMQ的高可用性-双主双从

5、如何保证消息不丢失？

消息丢失的原因

• 消息生产者没有成功发送到MQ broker

• 消息发送到mq broker后，broker宕机导致内存中的消息数据丢失

• 消费者消费了消息，但是没有处理完毕就发生异常导致消息丢失。

 

 

确保消息不丢失方案

• 发送方可靠发送

• mq进行消息持久化

• 消费放完成消费后进行ack确认，mq收到ack确认再删除本地消息

 

6、如何保证消息不被重复消费？（即保证消息的幂等性）

重复消息产生的根本原因：网络不可达

发送时消息重复

 

 消费时消息重复

 

 

解决消息重复发送问题–消息密等性

• 消息发送者发送消息时携带一个全局唯一的消息id

• 消费者获取消费后先根据id再db/redis查询消息是否成功消费

• 如果没有消费过直接消费，消费完成后写入db/redis

• 如果消费过则不予处理

7、如何保证消息的顺序性？

全局顺序消费：生产者：MQ：消费者=1：1：1

局部顺序消费

• 生产者根据消息id将同意组消息发送到一个queue中

• 多个消费者同时获取queue中的消息进行消费

• mq使用分段锁保证单个queue中的有序消费

 

8、大量消息推挤处理怎么办？

堆积消息的原因：

• 网络故障

• 消费方处理消息后没有给mq broker正常应答

 

消息堆积的处理方案

• 检查并修复消费方的正常消费速度

• 将堆积的消息转存到容量更大的mq集群

• 增加多个消费者节点并行消费堆积消息

• 消费完毕后，回复原始架构

 

9、消息过期怎么处理？

消息过期的原因

给消息设置了过期时间，如果超时还未被消费，则视为消息过期。过期消息可以转存到死信队列。

 

 

消息过期的处理方案

• 过期消息进入到死信队列

• 启动专门的消费者消费死信队列消息，并写入数据库记录日志

• 查询数据库消息日志，重新发送消息到mq