【八股文】MQ篇

1. 什么是MQ

消息队列中间件，是一种跨进程的通信机制，用于上下游传递消息。使用了MQ之后，消息发送上游只需要依赖MQ，不用依赖其他服务。

2. MQ的优点（异步、削峰、解耦）

异步、削峰、解耦

1. 异步

不是很重要的操作，可以通过异步操作来实现。（当然线程池也可以实现，但没有解耦的特点）

2. 削峰

把请求放到队列里面，然后至于每秒消费多少请求，就看自己的服务器（一般是数据库）处理能力，等流量高峰下去了，你的服务也就没压力了（短暂的请求积压是允许的）

白话文：有点像限流算法中的漏桶算法，在【八股文】分布式篇中有讲

3. 解耦

每加一个下游操作，都需要改上游的代码，重新部署，太麻烦了；解耦的意思是，下游直接订阅MQ，上游不需要改代码，就很不错

代码耦合太多，排查问题也慢（你也不知道是哪个下游操作出的问题）

3. MQ的缺点

1. 系统的可用性降低

万一MQ突然挂了，上下游就没办法交互了，导致上游不可用

2. 系统复杂性提高

如何保证没有重复消费呢？如何处理消息丢失的情况？怎么保证消息传递的顺序？（下面一一补充）

3. 一致性问题

上游无法知道下游的执行结果，这一点是很致命的，分布式事务问题，当然当然，RocketMQ除外了

4. 为什么要使用MQ

我们公司本身的业务体量很小，所以直接单机一把梭啥都能搞定了，但是后面业务体量不断扩大，采用微服务的设计思想，分布式的部署方式，所以拆分了很多的服务，随着体量的增加以及业务场景越来越复杂了，很多场景单机的技术栈和中间件以及不够用了，而且对系统的友好性也下降了，最后做了很多技术选型的工作，我们决定引入消息队列中间件。

白话文：业务量增多了，业务场景复杂了，系统响应变慢了呀，但是单机的技术栈顶不住这个业务量

5. MQ的使用场景

原文地址：https://blog.csdn.net/qq_35152037/article/details/80012961

1. 上游不关心执行结果（异步、解耦）

1. 例子

拿下单来说，下单之后一般会有用户增加积分、发送短信等等操作，这些操作可以晚点再发，对用户来说只要不影响正常下单就行

2. 原实现方案（一一调用关系，依次执行）

下单之后，调用积分服务，增加积分，调用短信服务发送短信。

1. 导致的问题

• 主业务耗时增加：下单时间增加了，而且随着附属业务功能越来越多，时间会越来越久
• 系统可用性降低，万一下游的一个服务挂了，会导致下单失败

3. MQ方案

1. 下单业务成功后，给MQ发送一个消息
2. 积分业务、短信业务等等去MQ上主动订阅《下单成功》消息

2. 上游关注执行结果，但执行时间很长

白话文：下面的理解不了，我建议这种情况就别用了

1. 例子（跨公网调用）

下单操作，需要调用微信系统（跨公网调用，请求时间会比较长），延长了下单的时间

2. MQ方案（回调网关+MQ）

一般采用“回调网关+MQ”方案来解耦：

1. 调用方直接跨公网调用微信接口
2. 微信直接返回调用成功（此时并不代表返回成功）
3. 微信执行完成后，回调统一网关
4. 网关将返回结果发给MQ
5. 上游订阅MQ，收到结果通知
   

疑点：之前调用微信接口不是靠网关的吗？？不知道哪里增快了速度

1. 为什么需要网关还需要MQ

这里需要注意的是，不应该由回调网关来调用上游来通知结果，如果是这样的话，每次新增调用方，回调网关都需要修改代码，仍然会反向依赖，使用回调网关+MQ的方案，新增任何对微信支付的调用，都不需要修改代码啦

白话文：加了MQ，每次新增调用方，网关这块（相当于上游服务）就不用改代码了，懂！

3. 数据驱动的任务依赖（任务的执行需要顺序）

1. 例子（task1->task2->task3）

什么是任务依赖，举个栗子，互联网公司经常在凌晨进行一些数据统计任务，这些任务之间有一定的依赖关系，比如：

• task3需要使用task2的输出作为输入
• task2需要使用task1的输出作为输入

这样的话，tast1, task2, task3之间就有任务依赖关系，必须task1先执行，再task2执行，载task3执行。

2. 原解决方案（cron人工排执行时间表）

定时任务之间设置预留时间，确保上一个任务执行完再进行下一个任务

1.每个任务执行的时间不确定，在任务之间需要有预留时间
2.如果任务执行快了，但预留时间太多了，下一个任务没法很快执行，浪费时间

1. 导致的问题（时间资源的浪费）

白话文：预留时间不好设定：1.每个任务执行的时间不确定，在任务之间需要有预留时间 2.如果任务执行快了，但预留时间太多了，下一个任务没法很快执行，浪费时间

3. MQ方案

1. 好处

• 不需要预留buffer，上游任务执行完，下游任务总会在第一时间被执行
• 解耦：依赖多个任务，被多个任务依赖都很好处理，只需要订阅相关消息即可
• 有任务执行时间变化，下游任务都不需要调整执行时间（和第一点一样）

6. MQ如何选型

推荐看看：敖丙之消息队列（mq）是什么？

1. 比较维度

1. 吞吐量

万级的 ActiveMQ 和 RabbitMQ 的吞吐量（ActiveMQ 的性能最差）要比 十万级甚至是百万级的 RocketMQ 和 Kafka 低一个数量级。

1. 万级别（ActiveMQ、RabbitMQ）

ActiveMQ、RabbitMQ

2. 十万级别（RocketMQ）

RocketMQ

3. 百万级别（Kafka）

Kafka

2. 可用性（高可用）

都可以实现高可用。ActiveMQ 和 RabbitMQ 都是基于主从架构实现高可用性。RocketMQ 基于分布式架构。 Kafka也是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用。

1. 基于什么架构实现高可用

1. 基于主从架构（ActiveMQ、RabbitMQ）

ActiveMQ、RabbitMQ

2. 基于分布式架构（RocketMQ、Kafka）

RocketMQ、Kafka（分布式架构和主从架构有什么区别，是集群模式？类似于redis集群？）

问题来了：下面讨论RocketMq的时候为什么是双主双从，看着像是主从架构 TODO

3. 时效性（修改后立马见效的意思）

RabbitMQ 基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。其他三个都是 ms 级。

1. 微秒级（RabbitMQ）

RabbitMQ

问：RabbitMQ反映最快，但是为什么吞吐量却不高？？？

2. 毫秒级（ActiveMQ、RocketMQ、Kafka）

ActiveMQ、RocketMQ、Kafka

4. 消息丢失

ActiveMQ 和 RabbitMQ 丢失的可能性非常低， RocketMQ 和 Kafka 理论上不会丢失。

1. 小概率丢失（ActiveMQ、RabbitMQ）

ActiveMQ、RabbitMQ

2. 不会丢失（RocketMQ、Kafka）

RocketMQ、Kafka

白话文：RocketMQ、Kafka比较自信，保证消息不丢失

5. 总结

1. ActiveMQ（不用了）

ActiveMQ的社区算是比较成熟，但是较目前来说，ActiveMQ 的性能比较差，而且版本迭代很慢，不推荐使用。

白话文：ActiveMQ老了（社区活跃度低），不推荐

2. RabbitMQ（基于 erlang 开发，JAVA人员看不懂）

RabbitMQ在吞吐量方面虽然稍逊于 Kafka 和 RocketMQ ，但是由于它基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。但是也因为 RabbitMQ 基于 erlang 开发，所以国内很少有公司有实力做 erlang 源码级别的研究和定制。如果业务场景对并发量要求不是太高（十万级、百万级？？这还不高。。），那这四种消息队列中，RabbitMQ 一定是你的首选。如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。

白话文：对于并发量要求不是很高的话，选择RabbitMQ，因为性能最好，而且还年轻（社区活跃度低）

3. RocketMQ（用JAVA开发，快乐来源）

RocketMQ 阿里出品，Java 系开源项目，源代码我们可以直接阅读，然后可以定制自己公司的 MQ，并且 RocketMQ 有阿里巴巴的实际业务场景的实战考验。RocketMQ 社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准 JMS 规范走的有些系统要迁移需要修改大量代码。还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用 RocketMQ 挺好的

白话文：java开发的，公司有实力的话可以改源码，中年人（社区活跃度一般）

4. Kafka（大数据、实时计算和日志采集）

Kafka 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时 kafka 最好是支撑较少的 topic 数量即可，保证其超高吞吐量。kafka 唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略，这个特性天然适合大数据实时计算以及日志收集。

白话文：大数据的日志采集用

原文链接：JavaGuide之常见的消息队列对比

7. 如何消息队列保证高可用（集群）

总结：NameServer、Broker、双主双从、主从复制、数据刷盘、心跳

1. 以RocketMQ为例

1. 几个概念

1. Topic消息类型（大类）

是相当于一种消息类型，通过topic可以找到对应的broker机子

2. Queue队列（明细类）

是属于某个Topic下的更细分的一种单元，一个broker机子有多个queue

3. 消费者组

消费者和消费者组属于个体与群体的关系

原文链接：rocketMQ中，消费者、消费者组、Topic、队列的关系

2. RocketMQ消息的存储结构（ConsumeQueue + CommitLog）

1. ConsumeQueue 逻辑队列（类似索引，指向真的文件CommitLog）

消息的逻辑队列，类似数据库的索引文件，存储的是指向物理存储的地址。每个 Topic下的每个 Message Queue都有一个对应的 ConsumeQueue文件

白话文：逻辑队列这么难记，不如叫索引队列吧！

2. CommitLog （提交日志？这名字也太怪了）刷盘后存在磁盘上的文件

消息真正的物理存储文件，每台 Broker上的 CommitLog被本机器所有 ConsumeQueue 共享。

白话文：刷盘后存在磁盘上的文件，真实的文件

3. 实现高可用的思路（多个Broker）

在实际生产环境中，一般需要服务达到高可用、无单节点故障的要求。在 rocketMq 中
就需要分布式部署。

白话文：分布式部署，就是所有节点不能部署到同一台机子上，不然这台机子挂了，全部节点都挂了，失去了集群的意义

RocketMQ的核心就是Broker的消息存储，而高可用的关键也在于Broker。

4. NameServer（类似于注册中心，管理Broker的）

因为NameServer是无状态的，如果要使用集群部署，只要有一台NameServer可用，那么集群就整体可用。

无状态：指的是节点平等，没有主从等一些关系

白话文：NameServer直接部署多个节点，自成集群（自动化形成集群。。很高级）

5. Broker（存储消息的服务）

一个很重要的消息存储模块

1. 作用

1. 接收Producer发过来的消息

2. 消息的持久化存储

Broker会把CommitLog文件通过刷盘的方式持久化到磁盘上，Broker中就留了一个类似索引的东西，叫做ConsumeQueue

3. 处理Consumer的消费消息请求

4. 消息的 HA 机制（高可用机制、同步机制）

消息到达主服务器后需要将消息同步到从服务器，如果主服务器 Broker 宕机后，消费者可以从从服务器拉取消息

2. Broker集群数量配置（推荐使用双主双从）

就是Broker的主从机子的数量，我自己猜有下面几种情况：

1. 一主多从

2. 双主双从（推荐）

为什么推荐使用双主双从？因为高可用

3. 多主多从

3. 主从复制模式配置（消息从主机到从机的过程）

把消息主节点复制到从节点的过程

注意：主从复制策略只在主节点配置就可以，相关配置的命名：主节点MASTER、从节点SLAVE

主从复制模式可以分为同步或者异步：

1. 同步双写（又叫同步复制）

同步双写保证消息不会丢失，如果5s内未完成消息复制，则给生产者Producer返回结果：数据同步到Slave服务器超时 SendStatus.FLUSH_SLAVE_TIMEOUT

1. 优点（消息不丢失）

保证消息不会丢失

2. 相关配置

brokerRole = SYNC_MASTER

2. 异步双写（又叫异步复制，是默认方式）

1. 优点

异步复制性能高

2. 相关配置

brokerRole = ASYNC_MASTER

4. 数据刷盘模式配置（消息从内存到磁盘的过程）

指的是消息（包括主从）被写入内存的pagecache再存到磁盘的过程

白话文：把消息从内存到磁盘的过程（持久化到磁盘，防止消息丢失？？这里的内存是包括主节点和从节点吗？包括的）

1. 同步刷盘

如果5s内未完成刷盘，则给生产者Producer返回结果：刷盘超时 SendStatus.FLUSH_SLAVE_TIMEOUT

1. 优点（保证消息持久化）

偏向消息高可靠，保证消息持久化

2. 相关配置

flushDiskType = SYNC_FLUSH

2. 异步刷盘（默认方式）

偏向性能，异步刷盘性能比较高

flushDiskType = ASYNC_FLUSH

4. 主从复制和刷盘模式的选择（两两组合四种情况）

• 异步复制，异步刷盘：如果偏向性能的话（默认方式）
• 同步双写，同步刷盘：如果偏向消息高可靠，不在乎性能
• 同步双写，异步刷盘：如果需求居中
• 异步双写，同步刷盘：啥玩意？？忽略（都不给你加粗）

如果断电等瞬时故障导致主从同时宕机可能会丢失几条消息。正常情况异步复制一台机器发生故障不会丢失数据。

5. 双主双从模式下的故障分析情况

原文链接：RocketMq高可用部署/消息高可靠性方案以及故障模拟

1. 题外话：问，双主之间是如何同步的？？

TODO

6. NameServer和Broker的关系（心跳）

每个Broker会和所有的NameServer保持长连接（通过心跳的方式）

1. 如何维持心跳

1. NameServer怎么做

nameserver每隔10秒钟（此时间无法更改），扫描所有还存活的broker连接，若某个连接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间无法更改）没有发送心跳数据，则断开连接。

白话文：NameServer每10s检测一次broker，如果broker超过2min没发心跳，则断开这个broker，并更新topic与队列queue的对应关系，但不会通知生产者和消费者

2. Broker怎么做

Broker每隔30秒（此时间无法更改）向所有nameserver发送心跳，心跳包含了自身的topic配置信息。

白话文：Broker每30s给所以NameServer发送心跳（包含topic配置信息）

8. RocketMQ如何保证消息不丢失（重要）

原文链接：面试官再问我如何保证 RocketMQ 不丢失消息，这回我笑了！

总结：1. 生产阶段：消息返回类型、重试机制、onSuccess、onException。2. 存储阶段：同步刷盘、同步复制 3. 消费阶段：消费失败重试（延迟队列、重试队列、死信队列、人工介入）

1. 消息的生命周期

1. 生产阶段

Producer生产消息，并通过网络把消息传给RocketMQ的Broker

2. 存储阶段

消息通过同步、异步刷盘的方式存储在Broker端磁盘中（CommitLog文件）

3. 消费阶段

Consumer将会从Broker拉取消息

2. 生产阶段如何保证消息不丢失

先上结论：根据消息的返回类型、设置重试次数（碰到网络问题导致重试失败）

生产者（Producer） 通过网络发送消息（可以分为同步和异步）给Broker，当Broker收到之后，将会返回确认响应信息给 Producer。

生产者只要接收到返回的确认响应，就代表消息在生产阶段未丢失

1. Broker返回给Producer消息的类型（来自官方）

1. SendStatus.SEND_OK：消息发送成功

消息发送成功，但并不意味这是可靠的，如果要确保不会丢失任何消息，还应该启动同步Master的服务器（SYNC_MASTER）和同步刷盘操作（SYNC_FLUSH）

2. SendStatus.FLUSH_DISK_TIMEOUT：刷盘超时

消息发送成功，但服务器刷盘超时，此时消息已经进入了服务器队列（内存），只有服务器宕机，消息才会丢失。消息存储配置参数中可以设置刷盘方式和同步刷盘的时间长度，如果Broker服务器设置了同步刷盘，当Broker服务器未在同步刷盘时间内（默认为5s）完成刷盘，则将返回这个状态。

白话文：消息成功发送到Broker的内存，但同步刷盘超时了

3. SendStatus.FLUSH_SLAVE_TIMEOUT：数据同步到Slave服务器超时

消息发送成功，但同步到Slave时超时，此时消息也已经进入了服务器队列（内存），只有服务器宕机，消息才会丢失。如果Broker服务器的角色是同步Master，且从机Broker未在同步时间内（默认为5s）完成与主服务器的同步，则将返回这个状态。

白话文：消息成功发送到Broker主机的内存，但同步从机Slave超时了

4. SendStatus.SLAVE_NOT_AVAILABLE 无Slave服务器可用

消息发送成功，但此时Slave不可用，如果Broker服务器的角色是同步Master，但没有配置Slave Broker服务器，则将返回该状态

白话文：消息成功发送到Broker的内存，但没有Slave服务器

2. Producer异步发送消息给Broker

RocketMQ 还提供异步的发送的方式，适合于链路耗时较长，对响应时间较为敏感的业务场景。

异步发送消息send方法里面有个入参SendCallBack，一定要注意重写回调方法，在回调方法中检查发送结果。

图片来源：https://baijiahao.baidu.com/s?id=1662095398693413299&wfr=spider&for=pc

回调有2个需要重写的方法（onSuccess和onException），在做分布式事务的时候用到。 纠正一下，这两这个方法是用来保证消息一定会发生成功，和分布式事务可没关系吼。

3. 设置重试次数（同步、异步都有）

不管是同步还是异步的方式，都会碰到网络问题导致发送失败的情况。针对这种情况，我们可以设置合理的重试次数，当出现网络问题，可以自动重试。

tips：重试是补偿机制中的一种，只要消息返回的类型不是SEND_OK，都要有补偿机制

3. 存储阶段如何保证消息不丢失

先上结论：设置2个同步，然后配合Producer的补偿重试操作

1. 案例

1. 异步刷盘未完成

Master Broker挂了，异步刷盘还没完成，整体消息丢失

2. 异步Slave复制未完成

Master Broker挂了，异步Slave复制还没完成，还未复制到Slave的消息丢失

2. 解决

1. 设置同步刷盘（flushDiskType = SYNC_FLUSH）
2. 设置同步复制（brokerRole = ASYNC_MASTER）

3. 分析

• 设置这2个同步，再加上生产者端的补偿机制（如重试），就可以完全保证消息不会丢失
• 如果非要设置为异步刷盘，好像没法解决了

4. 那么同步落盘怎么才能快

1. 使用 FileChannel（文件管道？？） + DirectBuffer 池（直接缓冲池？？），使用堆外内存，加快内存拷贝
2. 使用数据和索引分离，当消息需要写入时，使用 commitlog 文件顺序写，当需要定位某个消息时，查询index文件来定位，从而减少文件IO随机读写的性能损耗（啊？原来不就是这么操作的吗）

4. 消费阶段如何保证消息不丢失（消费消息失败重试机制）

1. Comsumer返回给Broker的消息类型（都整理到这里）

1. 并发消费返回的状态

1. ConsumeConcurrentlyStatus.CONSUME_SUCCESS：消费成功

返回这个状态，告诉Broker，下游业务真的执行成功了，Broker可以把这个消息删掉了

2. ConsumeConcurrentlyStatus.RECONSUME_LATER：稍后再重试消费

返回这个状态，告诉Broker，等会会重新再消费

2. 有序消费返回的状态

1. ConsumeOrderlyStatus.SUCCESS：消费成功

2.ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT：稍后消费

返回这个状态，告诉Broker，先等一会，再继续处理这批消息（不会放到重试队列，也不会增加重试次数，就等一小会就行）

先上结论：Producer只有成功消费消息，会发送成功标志给Broker

2. 情况分析

1. 如果消费消息成功

消费者从Broker拉取消息，然后执行相应的业务逻辑。一旦执行成功，将会返回消费成功状态给Broker。

2. 如果消费消息失败（重试）

如果 Broker未收到消费确认响应，消费者下次还会再次拉取到该条消息，进行重试。这样的方式有效避免了消费者消费过程发生异常，或者消息在网络传输中丢失的情况。

3. Comsumer消费消息失败，是如何重试消费的？

1. 关键字

延迟队列、重试队列、死信队列、人工介入或定时任务

2. 步骤如下

1. 把这个消息先放到延迟队列中，设定的延时时间
2. 延迟时间到了，再放到重试队列中
3. 每隔一定时间，再去重试这条消息，默认最多重试16次
4. 如果还是消费不了，就会进入死信队列
5. 人工介入处理，或者启动一个定时任务去订阅这个死信队列完成后续的处理

4. 存在的问题

1. 可能会导致消息重复消费

Producer消费消息成功，但是因为网络原因，未能把成功标志返回给Broker，Broker侧判断不出Producer是否有消费消息，所以没有操作这条消息，Producer还是可以继续消费这条消息，导致重复消费

1. 解决方案

需要保证消费接口的幂等性，可以看我的另一篇文章 ：【八股文】分布式篇

9. RocketMQ如何保证消息的顺序性

总结：1. 保证一对一 2. 自定义负载均衡模式（哈希取余） 3. 使用有序消费模式

1. 为什么会出现乱序（负载均衡）

Broker中的每个Topic都有多个Queue，写入消息的时候会平均分配（负载均衡机制，默认轮询，也可以自定义）给不同的Queue，假如我们有一个消费者组ComsumerGroup，这个消费组中的每一台机器都会负责一部分Queue，那么就会导致顺序的乱序问题

2. 例子

Producer先后发送了2条消息，一条insert，一条update，分别分配到2台Queue中，消费者组中的两台机器分别处理这两个Queue中的消息，这时候顺序是无法保证的

3. 如何解决

1. 保证Producer、Queue、Comsumer是一对一对一的关系

1. 缺点

1. 吞吐量降低

消息队列的吞吐量降低（绝对不容忍这样的情况发生）

2. 有阻塞的风险

如果Comsumer服务炸了，后面的消息就无法消费，被阻塞了

2. 把需要保持顺序消费的消息放到同一个Queue中，且让同一台机子处理

自定义负载均衡模式，把这一批顺序消息有共同的唯一ID，把唯一ID与队列的数量进行hash取余运算，保证这批消息进入到同一个队列

1. 存在的问题

还要考虑Comsumer消费失败的重试问题

3. 使用有序消费的模式

如果失败了会返回这个状态
ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT：稍后消费

10. 如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？

1. 分析

这一系列问题的本质其实就是消费端出问题了！！！（消费慢或者不消费了）

2. 线上出问题怎么解决（修复Comsumer、紧急扩容）

思路：临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据

1. 修复consumer的BUG，确保其恢复消费速度，然后将现有cnosumer都停掉

2. 创建10倍新队列：新建一个topic，queue是原来的10倍，临时建立好原先10倍或者20倍的queue数量

3. 写一个临时的分发数据的consumer程序：这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue

   目的：把大量消息均匀分发到新队列上

4. Comsumer10倍扩容：临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据

5. 打完收工：等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息

3. 消息过期失效了怎么办？（人工介入，半夜执行代码）

RabbitMQ的消息会有失效时间，写一个程序，把失效的消息ID找回来，等机子空闲的时候再手动塞进MQ里

4. 消息队列满了怎么办？（快速消费，假消费）

快速消费掉所有消息，如假装消费（直接返回ConsumeConcurrentlyStatus.CONSUME_SUCCESS），先把消息保存下来，等空闲的时候再手动塞进MQ里

1. 如果让你设计一个消息队列，你会怎么设计架构

1. 问题剖析

其实问的就是MQ有哪些核心点

1. 有没有对RocketMQ消息队列做过较为深入的原理的了解，或者从整体了解把握住一个mq的架构原理
2. 看看你的设计能力，给你一个常见的系统，就是消息队列系统，看看你能不能从全局把握一下整体架构设计，给出一些关键点出来

剖析：主要就是看你对这块知识的原理架构有多深的了解

开放性问题，不写答案啦~