阿里面试：说说你项目里使用的 MQ ，分布式系统中 MQ 作用？

Posted 2023-03-23

参考技术A 在阿里的面试中，面试官问到关于 MQ 的几个问题：

我之前写过一篇关于 rocketMQ 实现分布式锁的文章，主要介绍如何使用 RocketMQ 实现分布式锁，
《Springcloud + RocketMQ 解决分布式事务》
但是这个功能并不是 MQ 基本功能，也不是所有 MQ 都有的功能。

MQ 在系统中到底有哪些作用呢？抛开基本的消息发布订阅不说，还有以下几点：

在分布式系统中，要么是通过 rest 调用，要么是通过 dubbo 等 RPC 调用，但是有些场景需要解耦设计，不能直接调用。
比如消息驱动的系统中，消息发送者完成本地业务，发送消息，多平台的消息消费者服务需要收到推送的消息，然后继续处理其他业务。

看这两个架构图，第一种 BC 都直接依赖 A 服务，那么如果 A 中的接口修改，BC 都要跟着做修改，耦合度高。
第二种，通过 MQ 来作为中间件收发消息，BC 只依赖收到的消息而不是具体的接口，这样即使 A 服务修改或者增加其他服务，都只要订阅MQ就行。

用户注册业务流程为例，

原来的系统设计，这样的服务流程会串行处理，即先 1-2-3 ；但是这里可以思考下，如果单个服务单台机器的情况下，注册用户特别多，系统能不能抗住？

这里假设各个阶段的时间 1 = 50ms ， 2 = 50ms ， 3 = 50ms，那么一个请求下来就是 all = 150ms；
这里再假设，这个服务器 CPU = 1 ， 且只能处理单线程，那么以这种单台服务器单线程的 QPS 来算；QPS = 1000/150 ≈ 7
现在我要让这个 QPS * 3 提升三倍，这个时候引入 MQ 服务作为中间件

如图可见，我在 A 服务用户注册完成后，就直接返回了，这个时候 MQ 用来发送异步处理消息，B，C 服务分别处理。
A 不用等待 B、C 的返回结果 ，这样用户体验就是只有 50ms 等待时间。而在邮件、短信这个阶段，因为网络延迟原因，
用户可以接受一定时间的等待。

一般的服务，我们的请求访问到系统都是直接请求，这样的模式在用户访问量不大的情况下，问题不是很大。
但是如果用户请求达到了一定的瓶颈或者产生了一些问题，我们就需要考虑优化我们的架构设计，MQ 中间件正是解决办法之一。

下面以秒杀系统为例分析问题
秒杀系统瞬间百万并发，怎么处理？一般秒杀系统会进行请求过滤，无效、重复都会被过滤一遍，剩下的才真正进入到秒杀服务、订单服务。
但即使这样并发仍然很高，如果网关把全部请求都转发到下游订单服务，一样会压垮下游系统，造成服务不可用甚至雪崩。

真实的秒杀系统更复杂 ，包含 nginx 、网关、注册中心、redis 缓存、mysql 集群、消息队列集群

解决方式就是将上游处理的较快的任务，加入到队列处理，下游逐一消费队列，直到所有队列消费完成。
假如秒杀服务处理请求数：1000/s，
下游订单服务处理请求书：10/s，
为了不给下游订单服务造成压力，秒杀后的信息发送到队列，订单服务就可以从容淡定的每秒处理十个，而不是直接塞 1000 个请求
也不管人家愿意不愿意。

到这里，可以总结下秒杀系统的过滤方式：

所有服务都将日志发送到 MQ 服务用来作为日志存储。
MQ 作为中间件对日志进行持久化、转发
大数据服务对 MQ 读取和进行日志分析

有人上来就是一通性能比较，然后说 RabbitMQ 是世界上最好的 MQ...
你把挑选 MQ 比作挑老婆吧，上来就要全套，肤白貌美、前凸后翘、性感火辣、勤劳能干。。。
真是缺乏社会的教育啊，兄弟
养得起吗？动不动一套保养套餐，1W/月
守得住吗？隔壁老王经常来你家吃饭吧，疯狂脑补。。。
吃的消吗？红枣+枸杞+肾宝片，怕是心有余力不足吧

言归正传，其实我觉得这是一个思考题，首先我们要看的应该是条件是哪些？

上图的例子日志消息就是使用的 kafka，为什么是kafka？
Kafka是LinkedIn开源的分布式发布-订阅消息系统，属于 Apache 顶级项目，社区活跃。
Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。
后来版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。
但是 kafka 相对来说很重，需要依赖 zookeeper，大公司里使用没问题，也少不了专人维护。

RocketMQ 是阿里开源的一套可靠消息系统，已经捐赠 Apache 成为顶级项目。刚开始定位于非日志的可靠消息传输，其实在日志处理方面性能也不错。
目前支持的客户端包括 java，c++，GO ，社区比较活跃，文档还算全面。但是涉及到核心的要修改还是有难度的，毕竟阿里云靠卖这个服务赚钱呢。
所以如果公司实力不自信还是慎重选择吧，实在不行可以直接购买云服务，省心省力，还是那句话，看实际情况。

下图是来源网络的图片，部分描述已经过时，但是基本不差，仅供参考：

这里简单说说，后面专门针对这个问题进行书写招供。
大致就是一些特殊原因例如网络原因，服务重启造成消息消费未被记录，造成重复消费的可能。
一般的处理方式就是保证接口设计的幂等性，主旨通过唯一标识判断是否存在。

RabbitMQ面试题

1、为什么要引入MQ系统，直接读写数据库不行吗？
其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？

面试官问你这个问题，期望的一个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。

先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个：解耦、异步、削峰。
解耦：多系统多进程的数据交换，用pub/sub
异步：把大数据量的同步处理改为异步
削峰：一般的A 系统使用 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。如果使用 MQ， 每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最 大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉，这又设计请求排队的问题。

2、消息队列有什么优缺点？
优点：解耦、异步、削峰
缺点：
系统可用性降低
系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套
系统崩溃的，你不就完了？

系统复杂度提高
硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。

一致性问题
A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。

3、Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？
https://blog.csdn.net/Dome_/article/details/84990563

4、RabbitMQ 的高可用性如何保证?
RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式
单机模式不存在高可用。
普通集群模式也不存在高可用性，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。但是你创建的 queue，只会放在一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上 拉取数据过来。这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个 queue 所在实 例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。而且如果那个放 queue 的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让 RabbitMQ 落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个 queue 拉取数据。
镜像集群模式的策略是高可用策略，指定的时候可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的 节点上去了。

https://www.javazhiyin.com/22905.html

5、如何解决消息队列的延时以及过期失效问题？
其实本质针对的场景，都是说，可能你的消费端出了问题，不消费了；或者消费的速度极其慢，造成消息堆积了，MQ存储快要爆了，甚至开始过期失效删除数据了。

针对这个问题可以有事前、事中、事后三种处理

• 事前：开发预警程序，监控最大的可堆积消息数，超过就发预警消息（比如短信），不要等出生产事故了再处理。
• 事中：看看消费端是不是故障停止了，紧急重启。
• 事后：中华石杉老师就是说的这一种（https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/mq-time-delay-and-expired-failure.md），需要对消费端紧急扩容 ，增加处理消费者进程，如扩充10倍处理，但其实这也有个问题，即数据库的吞吐是有限制的，如果是消费到数据库也是没办法巨量扩容的，所以还是要在吞吐能力支持下老老实实的泄洪消 费。所以事前预防还是最重要的。否则出发删除过期数据，那就需要再重写生产消息的程序，重新产生消息。

6、RabbitMQ如何保证不丢数据？
需要考虑3个可能丢数据的地方：生产端、队列本身、消费端

• 6.1生产端：开启事务（不推荐，太耗性能降低吞吐），推荐开启 confirm 模式，在生产者那里设置开启 confirm 模式之后，你每次写的消息都会分配一个唯一的 id，然后如果写入了RabbitMQ 中，RabbitMQ 会给你回传一个 ack 消息，告诉你说这个消息 ok 了。如果 RabbitMQ 没能处理这个消息，会回调你的一个 nack 接口，告诉你这个消息接收失败，你可以重试。而 且你可以结合这个机制自己在内存里维护每个消息 id 的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。
• 6.2队列本身：就是 RabbitMQ 自己弄丢了数据，这个你必须开启 RabbitMQ 的持久化，就是消息写入之后会持久化到磁盘，哪怕是 RabbitMQ 自己挂了，恢复之后会自动读取之前存储的数据，一般数据不会丢。

设置持久化有两个步骤：

• • 　创建 queue 的时候将其设置为持久化，这样就可以保证 RabbitMQ 持久化 queue 的元数据，但是它是不会持久化 queue 里的数据的。
  • 　第二个是发送消息的时候将消息的 deliveryMode 设置为 2。就是将消息设置为持久化的，此时 RabbitMQ 就会将消息持久化到磁盘上去。
• 6.3消费端：其实和kafka的原理很类似，kafka即手动提交offsize。用RabbitMQ 提供的 ack 机制，简单来说，就是你必须关闭 RabbitMQ 的自动 ack，通过自己的一个 api 来调用就行，然后每次你自己代码里确保处理完的时候，再在程序里 ack。这样的话，如果你还没处理完，不就没有 ack 了？那 RabbitMQ 就认为你还没处理完，这个时候 RabbitMQ 会把这个消费分配给别 的 consumer 去处理，消息是不会丢的。

7、如何保证队列的消息不被重复消费？
这个需要灵活作答，考察的是思考力，因为消费的场景有很多，有数据库、有缓存、有第三方接口

• 1.比如针对数据库，你拿到这个消息做数据库的insert操作。那就容易了，给这个消息做一个唯一主键（或者UUID），那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
• 2.再比如redis缓存，你拿到这个消息做redis的set的操作，那就容易了，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。
• 3.再比如第三方接口，需要确定两点，第三方接口程序是有去重能力的，那么脏一点直接丢数据过去，如果没有去重能力，还是需要我们来写程序去重，就是第2点的办法。

8、集群节点类型都有什么？
节点的存储类型分为两种：

• 磁盘节点
• 内存节点

磁盘节点就是配置信息和元信息存储在磁盘上，内存节点把这些信息存储在内存中，当然内次节点的性能是大大超越磁盘节点的。
单节点系统必须是磁盘节点，否则每次你重启RabbitMQ之后所有的系统配置信息都会丢失。
RabbitMQ要求集群中至少有一个磁盘节点，当节点加入和离开集群时，必须通知磁盘节点。