，咱们把音讯中间件这块高频的面试题给咱们说一下，也会包含一些MQ中间件常见的技能问题。

  这个首要你能够说下你们公司选用的是什么音讯中间件，比方用的是RabbitMQ，然后能够开始给一些你对不同MQ中间件技能的选型剖析。

  举个比方：比方说ActiveMQ是老牌的音讯中间件，国内许多公司曩昔运用的仍是十分广泛的，功用很强壮。

  可是问题在于无法承认ActiveMQ能够支撑互联网公司的高并发、高负载以及高吞吐的杂乱场景，在国内互联网公司落地较少。而且运用较多的是一些传统企业，用ActiveMQ做异步调用和体系解耦。

  然后你能够说说RabbitMQ，他的优点在于能够支撑高并发、高吞吐、功用很高，一起有十分完善快捷的后台办理界面能够运用。

  而且经过调研，国内各大互联网公司落地大规模RabbitMQ集群支撑本身事务的case较多，国内各种中小型互联网公司运用RabbitMQ的实践也比较多。

  除此之外，RabbitMQ的开源社区很活泼，较高频率的迭代版别，来修正发现的bug以及进行各种优化，因而归纳考虑往后，公司采纳了RabbitMQ。

  可是RabbitMQ也有一点缺点，便是他本身是根据erlang言语开发的，所以导致较为难以剖析里边的源码，也较难进行深层次的源码定制和改造，究竟需求较为厚实的erlang言语功底才能够。

  然后能够聊聊RocketMQ，是阿里开源的，经过阿里的出产环境的超高并发、高吞吐的检测，功用杰出，一起还支撑分布式事务等特别场景。

  而且RocketMQ是根据Java言语开发的，合适深化阅览源码，有需求能够站在源码层面处理线上出产问题，包含源码的二次开发和改造。

  其他便是Kafka。Kafka供给的音讯中间件的功用显着较少一些，相对上述几款MQ中间件要少许多。

  可是Kafka的优势在于专为超高吞吐量的实时日志收集、实时数据同步、实时数据核算等场景来规划。

  因而Kafka在大数据领域中合作实时核算技能（比方SparkStreaming、Storm、Flink）运用的较多。可是在传统的MQ中间件运用场景中较少选用。

  PS：假如咱们对上述一些MQ技能还没在自己电脑布置过，没写几个helloworld体会一下的话，主张先上各个技能的官网找到helloworlddemo，自己跑一遍玩玩

  然后结合你们本身体系对应的运用场景，说一下在你们体系中引进音讯中间件是处理了什么问题。

  假定你有个体系A，这个体系A会产出一个中心数据，现在下流有体系B和体系C需求这个数据。

  可是现在要是来了体系D、体系E、体系F、体系G，等等，十来个其他体系渐渐的都需求这份中心数据呢？如下图所示。

  咱们可别认为这是恶作剧，一个大规模体系，往往会拆分为几十个乃至上百个子体系，每个子体系又对应N多个服务，这些体系与体系之间有着错综杂乱的联系网络。

  假如某个体系产出一份中心数据，或许下流许多的其他体系都需求这份数据来完结各种事务逻辑。

  此刻假如你要是采纳上面那种形式来规划体系架构，那么肯定你担任体系A的同学要被烦死了。

  先是来一个人找他要求发送数据给一个新的体系H，体系A的同学要修正代码然后在那个代码里参加调用新体系H的流程。

  一会那个体系B是个陈腐老体系要下线了，告知体系A的同学：别给我发送数据了，接着体系A再次修正代码不再给这个体系B。

  然后假如要是某个下流体系忽然宕机了呢？体系A的调用代码里是不是会抛反常？那体系A的同学会收到报警说反常了，成果他还要去care是下流哪个体系宕机了。

  所以在实践的体系架构规划中，假如悉数采纳这种体系耦合的方法，在某些场景下肯定是不合适的，体系耦合度太严峻。

  而且相互耦合起来并不是中心链路的调用，而是一些非中心的场景（比方上述的数据消费）导致了体系耦合，这样会严峻的影响上下流体系的开发和保护功率。

  体系A就把自己的一份中心数据发到MQ里，下流哪个体系感兴趣自己去消费即可，不需求了就撤销数据的消费，如下图所示。

  假定你有一个体系调用链路，是体系A调用体系B，一般耗时20ms；体系B调用体系C，一般耗时200ms；体系C调用体系D，一般耗时2s，如下图所示。

  现在最大的问题便是：用户一个恳求过来巨慢无比，由于走完一个链路，需求消耗20ms+200ms+2000ms（2s）=2220ms，也便是2秒多的时刻。

  可是实践上，链路中的体系A调用体系B，体系B调用体系C，这两个进程起来也就220ms。

  就由于引进了体系C调用体系D这个进程，导致终究链路履行时刻是2秒多，直接将链路调用功用下降了10倍，这便是导致链路履行过慢的元凶巨恶。

  那此刻咱们能够考虑一下，是不是能够将体系D从链路中抽离出去做成异步调用呢？其实许多的事务场景是能够答应异步调用的。

  ，你平常点个外卖，咔嚓一会儿下订单然后付款了，此刻账户扣款、创立订单、告诉商家给你预备菜品。

  接着，是不是需求找个骑手给你送餐？那这个找骑手的进程，是需求一套杂乱算法来完结调度的，比较耗时。

  可是其实略微晚个几十秒完结骑手的调度都是ok的，由于实践并不需求在你付出的一会儿立马给你找好骑手，也没那个必要。

  那么咱们是不是就能够把找骑手给你送餐的这个进程从链路中抽离出去，做成异步化的，哪怕推迟个几十秒，可是只要在必定时刻范围内给你找到一个骑手去送餐就能够了。

  这样是不是就能够让你下订单点外卖的速度变得超快？付出成功之后，直接创立好订单、账户扣款、告诉商家立马给你预备做菜就ok了，这个进程或许就几百毫秒。

  然后后台异步化的消耗或许几十秒经过调度算法给你找到一个骑手去送餐，可是这个进程不影响咱们快速下订单。

  当然咱们不是说那些咱们了解的外卖渠道的技能架构就必定是这么完结的，只不过是用一个日子中常见的比方给咱们举例说明罢了。

  所以上面的链路也是同理，假如事务流程支撑异步化的话，是不是就能够考虑把体系C对体系D的调用抽离出去做成异步化的，不要放在链路中同步顺次调用。

  这样，完结思路便是体系A-体系B-体系C，直接就消耗220ms后直接成功了。

  然后体系C便是发送个音讯到MQ中间件里，由体系D消费到音讯之后渐渐的异步来履行这个耗时2s的事务处理。经过这种方法直接将中心链路的履行功用提升了10倍。

  假定你有一个体系，平常正常的时分每秒或许就几百个恳求，体系布置在8核16G的机器的上，正常处理都是ok的，每秒几百恳求是能够轻松抗住的。

  那假如瞬时顶峰每天就那么半个小时，接着直接就下降为了每秒就几百恳求，假如你线上布置了许多台机器，那么每台机器就处理每秒几十个恳求就能够了，这不是有点糟蹋机器资源吗？

  大部分时分，每秒几百恳求，一台机器就足够了，可是为了抗那每天瞬时的顶峰，硬是布置了10台机器，每天就那半个小时有用，其他时分都是糟蹋资源的。

  可是假如你就布置一台机器，那会导致瞬时顶峰时，一会儿压垮你的体系，由于肯定无法抗住每秒几千的恳求顶峰。

  此刻咱们就能够用MQ中间件来进行流量削峰。一切机器前面布置一层MQ，平常每秒几百恳求咱们都能够轻松接纳音讯。

  一旦到了瞬时顶峰期，一下涌入每秒几千的恳求，就能够积压在MQ里边，然后那一台机器渐渐的处理和消费。

  这个便是很典型的一个MQ的用法，用有限的机器资源承载高并发恳求，假如事务场景答应异步削峰，顶峰期积压一些恳求在MQ里，然后顶峰期过了，后台体系在必定时刻内消费结束不再积压的话，那就很合适用这种技能计划。