本文是《从 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系统选型、技术调研怎么做的？
答：
初步考虑的因素：
- 业内常用的MQ有哪些？
- 每一种MQ各自的表现如何？
- 这些MQ在同等机器条件下，能抗多少QPS（每秒抗几千QPS还是几万QPS）？
- 性能有多高（发送一条消息给他要2ms还是20ms）？
- 可用性能不能得到保证（要是MQ部署的机器挂了怎么办）？
更多详细的因素：
- 他们会不会丢失数据？
- 如果需要的话能否让他们进行线性的集群扩容（就是多加几台机器）？
- 消息中间件经常需要使用的一些功能他们都有吗（比如说延迟消息、事务消息、消息堆积、消息回溯、死信队列，等等）？
- 另外还得考虑这些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 开始带你成为消息中间件实战高手》内容总结，版权问题，特此声明。
