本文是《从 0 开始带你成为消息中间件实战高手》内容总结,版权问题,特此声明

本篇文章持续更新,大概有上百道题,用这些题来驱动RocketMQ学习,在面试中也会脱颖而出!!

 

15 解决订单系统诸多问题的核心技术:消息中间件到底是什么?

 

问1:什么是“同步”调用?

答:

A、B、C三个系统,实现一个功能的调用链是:A调用B,B又调用C,A要返回结果,必须等B返回,B又等C返回,这种模式其实就是所谓的“同步调用”。

 

问2: 依托消息中间件如何实现异步?

答:

引入了MQ后,用来的依赖关系转移了,从系统之间的依赖,变成系统都依赖MQ

A调用B,只需要向MQ发送一条消息,A就认为自己的工作完成了。不用像之前调用B一样等着B处理一堆的业务逻辑和数据库操作。

B会从MQ中读取A发送的特定消息,完成自己该做的事情。

这样就实现了A异步调用B

 

问3:MQ是用来干嘛的?有什么作用?

答:

MQ其实就是一种系统,独立部署,让 系统之间通过发消息和收消息来进行异步的调用

作用:提升性能、系统解耦、流量消峰

提升性能:

一个请求调用了A、B两个系统,执行业务逻辑各需要20 、200毫秒,那么处理这个请求一共需要220毫秒

引入MQ后:发送消息给MQ的速度是很快的(没有业务逻辑、没有数据库操作),所以引入MQ后,20多毫秒就可以返回结果给用户了。

系统解耦:

系统A和系统B通过同步调用的模式耦合在了一起,一旦系统B出现故障,很可能会影响系统A也有故障

而且系统A还得去关心系统B的故障,去处理对应的异常,这是很麻烦的。

引入MQ后:B如果出现了故障,对系统A根本没影响,系统A也感觉不到,B自己处理自己的问题!

流量消峰:

如果高并发访问系统A(A没有数据库操作),A调用B(B有数据库操作),那么瓶颈在B,因为数据库操作是比较耗时的。

同样的机器配置下,如果数据库可以抗每秒 6000 请求, MQ 至少可以抗每秒几万请求。因为数据库复杂,需要支持事务、复杂的SQL查询等

引入MQ后:A系统依赖支持高并发的MQ,B也依赖MQ,此时B可以用自己的合适的速度访问MQ,即B系统流量被消峰了。整个系统的性能由A决定,而不速度慢的B决定

 


 

17 领导的要求:你来对 Kafka RabbitMQ 以及 RocketMQ 进行技术选型调研

 

问1:说说MQ解决了你们系统中的哪些问题?

答:

1、支付订单流程中步骤过多,订单系统完成核心的步骤,发送消息到MQ,其他的服务从MQ获取消息,执行比较耗时的操作。

2、退款失败问题,订单支付系统完成公司系统内部业务的核心流程,发送消息到MQ,使用一个专门的系统区处理和第三方支付系统的交互。

3、大促时,大量下单请求放到MQ,订单系统以合适的速度消费消息,处理相关业务

 

 

问2:你们MQ系统选型、技术调研怎么做的?

答:

初步考虑的因素:

 

  1. 业内常用的MQ有哪些?
  2. 每一种MQ各自的表现如何?
  3. 这些MQ在同等机器条件下,能抗多少QPS(每秒抗几千QPS还是几万QPS)?
  4. 性能有多高(发送一条消息给他要2ms还是20ms)?
  5. 可用性能不能得到保证(要是MQ部署的机器挂了怎么办)?

 

更多详细的因素:

 

  1. 他们会不会丢失数据?
  2. 如果需要的话能否让他们进行线性的集群扩容(就是多加几台机器)?
  3. 消息中间件经常需要使用的一些功能他们都有吗(比如说延迟消息、事务消息、消息堆积、消息回溯、死信队列,等等)?
  4. 另外还得考虑这些MQ在文档是否齐全?社区是否活跃?在行业内是否广泛运用?是用什么语言编写的?

 

问3:你们为什么选RocketMQ作为公司系统的消息中间件? Kafka RabbitMQ 以及 RocketMQ 的调研对比

答:

国内采用的MQ有:ActiveMQ、Kafka、RabbitMQ、RocketMQ,但现在ActiveMQ用的越来越少了。主要做其他三种的调研。

kafka:

1、开发语言:     Scala开发

2、性能、吞吐量: 吞吐量所有MQ里最优秀,QPS十万级、性能毫秒级、支持集群部署

3、功能:         功能单一

4、缺点:         丢数据, 因为数据先写入磁盘缓冲区,未直接落盘。机器故障会造成数据丢失

5、应用场景:     适当丢失数据没有关系、吞吐量要求高、不需要太多的高级功能的场景,比如大数据场景。

RabbitMQ:

1、开发语言:     Erlang开发

2、性能、吞吐量: 吞吐量比较低,QPS几万级、性能u秒级、主从架构

3、功能:         功能单一

4、缺点:         Erlang小众语言开发,吞吐量低,集群扩展麻烦

5、应用场景:     中小公司对并发和吞吐量要求不高的场景。

RocketMQ:

1、开发语言:     java开发

2、性能、吞吐量: 吞吐量高,QPS十万级、性能毫秒级、支持集群部署

3、功能:         支持各种高级功能,比如说 延迟消息、事务消息、消息回溯、死信队列、消息积压等等

4、缺点:         官方文档相对简单可能是RocketMQ目前唯一的缺点

5、应用场景:     适当丢失数据没有关系、吞吐量要求高、不需要太多的高级功能的场景,比如大数据场景。

 

 


 

19 新技术引入:给团队分享 RocketMQ 的架构原理和使用方式

问1:MQ如何集群化部署来支撑高并发访问?

答:

系统的流量分散在RocketMQ部署的多台机器上

问2:RocketMQ如何分布式存储海量消息的?

答:

存储海量消息的机制也是分布式的存储。

RocketMQ进程一般称为Broker,集群部署的各个Broker收到不同的消息,然后存储在自己本地的磁盘文件中。

 

问3: 任何一台 Broker 突然宕机了怎么办?那不就会导致 RocketMQ 里一部分的消息就没了吗?这就会导致 MQ 的不可靠和不可用,这个问题怎么解决?

答:

RocketMQ的解决思路是Broker主从架构以及多副本策略。

Master收到消息后会同步给Slave,这样一条消息就不止一份了,Master宕机了还有slave中的消息可用,保证了MQ的可靠性和高可用新。

 

问4: 怎么知道有哪些 Broker ?怎么知道要连接到哪一台 Broker 上去发送和接收消息?

答:

有个NameServer的概念,是独立部署在几台机器上的,然后所有的Broker都会把自己注册到NameServer上去,NameServer就知道集群里有哪些Broker了!

发送消息到Broker,会找NameServer去获取路由信息

系统要从Broker获取消息,也会找NameServer获取路由信息,去找到对应的Broker获取消息。

 


 

21 设计生产架构之前的功课:消息中间件路由中心的架构原理是什么?

 

问1:RocketMQ包含了几个核心部分?

答:

NameServer集群、Broker集群、生产者、消费者

NameServer

负责管理所有的Broker消息

让生产者和消费者鬼知道集群里有哪些Broker,然后与之通信

Broker

实现数据多副本存储和高可用,使用 主从架构

生产者

向MQ发送消息

消费者

从MQ获取消息

问2:NameServer到底可以部署几台机器?为什么要集群化部署?

答:

部署多台,保证高可用性。

 

, NameServer是集群里非常关键的一个角色,如果部署一台 NameServer,宕机会导致RocketMQ集群出现故障,所以N ameServer一定会多机器部署,实现一个集群,起到高可用的效果。

 

问3: Broker把自己的信息注册到哪个NameServer上?

答:

每个Broker向所有的NameServer上注册自己的信息,即每个NameServer上有所有的Broker信息

 

问4:系统如何从NameServer获取Broker信息?

答:

//TODO 其他相关信息有哪些?

 

问5:如果Broker宕了,NameServer是怎么感知到的?

答:

Broker会定时(30s)向NameServer发送心跳

然后 NameServer会定时(10s)运行一个任务,去检查一下各个Broker的最近一次心跳时间,如果某个Broker超过120s都没发送心跳了,那么就认为这个Broker已经挂掉了。

问6:Broker挂了,系统是怎么感知到的?

答:

主要是通过拉取NameServer上Broker的信息。

我们先知道,对于生产者而言,他是有 一套容错机制的。

 

问:文中只提到生产者这有容错机制,消费者是不是应该有容错机制呢?

答:

//TODO

 

问1:如果某个Broker没有宕机,而是该Broker和Namesrv之间的网络问题造成NameSrv认为某个Broker宕机了,Producer后续拿到新的路由信息后,其实此时Producer可以连通该Broker,此时Producer就不会给该Broker发送消息了?

答:

没错,就是如此

 

问2:Producer发送消息到Broker,是随机选择一个Broker还是有一定的规则?

答:

一般是负载均衡做随机选择,但也可以走其他策略,比如根据某个字段来hash,后续会讲 //TODO 

 

问3:Producer是随机选择还是使用什么规则选择NameSrv获取路由信息?

答:

对NameSrv选择是随机的

 

问4:存在这样的情况,由于网络原因Broker和部分NameSrv可以连通,会造成各个Namesrv的路由信息是不一样的,此时RocketMQ如何处理?

答:

//TODO


23 设计生产架构之前的功课: Broker 的主从架构原理是什么?

 

问1: Master Broker 是如何将消息同步给 Slave Broker 的?

答:

RocketMQ自身的Master-Slave模式采取的是Pull模式拉取消息。

 

问2: 消费者的系统在获取消息的时候,是从 Master Broker 获取的?还是从 Slave Broker 获取的?

答:

可能从Master Broker获取消息,也有可能从Slave Broker获取消息

1、消费者的系统在获取消息的时候会先发送请求到Master Broker上去,请求获取一批消息,此时Master Broker是会返回一批消息给消费者系统的

2、Master Broker在返回消息给消费者系统的时候,会根据当时Master Broker的 负载情况和Slave Broker的 同步情况,向消费者系统建议下一次拉取消息的时候是从Master Broker拉取还是从Slave Broker拉取。

 

追问个问题:

 

问题1:Master会向消费者建议下次拉取信息的地方,也就是说Master里面会监控本身的qps和slave的数据同步情况?

 

问题2:Master给消费者返回数据时会带上相关负载和数据同步情况的信息,如果遵循Master的建议从slave拉取,那么后续访问slave会有这些信息么?如果没有那么消费者后续采用什么策略区拉取数据?是一直从slave一直取数据,还是说会定时再去从Master获取这些信息

 

答:这个涉及到了很多源码级别的细节了,继续跟着专栏学习,后面会在底层原理剖析环节分析你的问题。

 

 

问3: 如果 Slave Broker 挂掉了,会对整个系统有影响吗?

答:

有一点影响,但是影响不太大,因为消息写入全部是发送到Master Broker的,获取消息也可以Master获取,少了Slave Broker,会导致所有读写压力都集中在Master Broker

 

问4: Master Broker 突然挂了,这样会怎么样?

答:

RocketMQ 4.5版本之前,用Slave Broker同步数据,尽量保证数据不丢失,但是一旦Master故障了,Slave是没法自动切换成Master的。

所以在这种情况下,如果Master Broker宕机了,这时就得手动做一些运维操作,把Slave Broker重新修改一些配置,重启机器给调整为Master Broker,这是有点麻烦的,而且会导致中间一段时间不可用。

 

问5: 基于 Dledger 实现 RocketMQ 高可用自动切换

RocketMQ 4.5之后支持了一种叫做Dledger机制,基于Raft协议实现的一个机制。

一旦 Master Broker 宕机了,在多个 Slave 中通过 Dledger 技术 将一个 Slave Broker 选为新的 Master Broker 对外提供服务。

在生产环境中可以是用Dledger机制实现自动故障切换,只要10秒或者几十秒的时间就可以完成

 

 

问:从上文描述感觉是从哪读是Master来决定的,那么 Master宕机后,slave还可读么?

答:可读

 

问:Master宕机了, 修改slave为Master, 此时如果有的消息没有同步到slave,这个时候要丢失部分数据,丢失的数据如何处理呢?

答:

对的,master挂了应该让slave提供读,同时修复master,但4.5以后通常建议用dledger自动切换

//TODO 

问:Master宕机了,修改slave为Master,有段时间读写都不可用,为什么不修复Master?这样至少可以保证可以从slave读数据,而且修复Master后不会丢已经写入的数据

答:

后续会深入剖析如何保证数据不丢,要同时设置刷盘策略和副本同步相关配置

 

问:现在Broker slave主动从Master拉取消息,一旦Master宕机,是不就会丢失一部分消息?不是说RocketMQ可以保证不丢消息么?

答:

是的,后续会深入剖析如何保证数据不丢,要同时设置刷盘策略和副本同步相关配置。//TODO

 

 

 

 

 

 

 

红色标注的问题后续会不断完善答案

 

声明:本文是《从 0 开始带你成为消息中间件实战高手》内容总结,版权问题,特此声明。