【消息队列】关于消息队列的一些面试问题

消息队列MQ

面试题：介绍一下消息队列

消息队列

关于这个问题主要从三个方面回答。

第一，消息队列是应用之间异步通信的方式，主要由三个部分组成。

生产者，消息所承载业务信息的一个实例化，整个消息的发起方。

中间的broker是消息的服务端，主要是处理消息单元，负责消息的存储、投递等功能，是核心部分。

消费者，主要负责消息的消费，具体是根据消息承载的信息处理各种逻辑。

第二，应用场景。主要分为三种

1.异步处理，在实时性要求不严格的一些场景，比如用户注册发送验证码，下单通知发送优惠券等。服务方只需要把协商好的消息发送到消息队列，剩下的由消费者的消息服务去处理，不需要等待消费者的返回结果就可以返回给客户端，返回业务层面。

2.应用解耦。把一些相关但耦合性不高的系统关联起来，增加整个系统的灵活度。

3.流量削峰。为了权衡高可用，把大量并行任务发送到mq，根据mq的存储、分发功能平稳处理后续业务。起到大流量缓冲的作用。

第三，目前市面上主要低吞吐量通常使用activemq，高吞吐量通常使用kafka和rocketmq。

应用场景

• 异步发送优惠券
• 异步发送网站通知
• 异步扣库存
• 贷款系统异步计算额度

为什么需要使用MQ

• 异步:将用户的请求数据存储到消息队列之后就立即返回结果。随后，系统再对消息进行消费。
• 解耦：生产者（客户端）发送消息到消息队列中去，接受者（服务端）处理消息，需要消费的系统直接去消息队列取消息进行消费即可而不需要和其他系统有耦合，这显然也提高了系统的扩展性。
• 削峰：先将短时间高并发产生的事务消息存储在消息队列中，然后后端服务再慢慢根据自己的能力去消费这些消息，这样就避免直接把后端服务打垮掉。

MQ 与多线程实现异步的区别

1.多线程方式实现异步可能会消耗到我们的 cpu 资源，可能会影响到我们业务线程执行会发生 cpu 竞争的问题；

2.MQ 方式实现异步是完全解耦，适合于大型互联网项目；

3.小项目可以使用多线程实现异步，大项目建议使用 MQ 实现异步；

MQ如何避免消息堆积的问题

背景： 生产者投递消息的速率与我们消费者消费的速率完全不匹配。

生产者投递消息的速率>消费者消费的速率，导致我们消息会堆积在我们 mq 服务器端中，没有及时的被消费者消费，所以就会产生消息堆积的问题 。

注意：

• rabbitmq 消费者我们的消息消费如果成功，消息会被立即删除。

• kafka 或者 rocketmq 消息消费如果成功的话，消息不会立即被删除。

解决办法：

A.提高消费者消费的速率；（对我们的消费者实现集群）

B.消费者应该批量形式获取消息 减少网络传输的次数；

MQ如何保证消息顺序一致性问题

背景：mq服务器集群或者mq采用分区模型架构存放消息，每个分区对于一个消费者消费消息。

解决消息顺序一致性问题核心办法：消息一定投递到同一个mq、同一个分区模型，最终被同一个消费者消费。

根据消息key%分区模型总数

MQ如何保证消息幂等问题

消费者获取消息，如果消费消息失败， mq 服务器则会间隔的形式 实现重试策略；

重试过程中，需要保证业务幂等性问题，保证业务不能够重复执行。

我们可以通过全局的消息 id，提前查询如果该业务逻辑已经执行过，则不会重复执行。

我们也需要在数据库的 db 层面需要保证幂等性问题，唯一主键约束、乐观锁等。

MQ保证消息幂等性

幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

方案 1：直接删除 Redis 缓存；

方案 2：基于 MQ 异步同步更新

方案 3：基于 canal 订阅 binlog 同步