常见的消息队列中间件介绍.pdf

常见的消息队列中间件介绍

常见的消息队列中间件介绍

题⽬

为什么使⽤消息队列？

消息队列有什么优点和缺点？

Kafka、ActiveMQ、RabbitMQ、RocketMQ都有什么区别，以及适合哪些场景？

消息中间件各种⾯试题：

问题⽬录见简书转载博客：

⾯试题剖析

为什么使⽤消息队列

先说⼀下消息队列常见的使⽤场景吧，其实场景有很多，但是⽐较核⼼的有3个：解耦、异步、削峰。

解耦

看这么个场景。A系统发送数据到BCD三个系统，通过接⼝调⽤发送。如果E系统也要这个数据呢？那如果C系统现在不需要了呢？A系

统负责⼈⼏乎崩溃

mq-1

在这个场景中，A系统跟其它各种乱七⼋糟的系统严重耦合，A系统产⽣⼀条⽐较关键的数据，很多系统都需要A系统将这个数据发送过

来。A系统要时时刻刻考虑BCDE四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都⽩了啊！

如果使⽤MQ，A系统产⽣⼀条数据，发送到MQ⾥⾯去，哪个系统需要数据⾃⼰去MQ⾥⾯消费。如果新系统需要数据，直接从MQ⾥消

费即可；如果某个系统不需要这条数据了，就取消对MQ消息的消费即可。这样下来，A系统压根⼉不需要去考虑要给谁发送数据，不需要

维护这个代码，也不需要考虑⼈家是否调⽤成功、失败超时等情况。

mq-2

总结：通过⼀个MQ，Pub/Sub发布订阅消息这么⼀个模型，A系统就跟其它系统彻底解耦了。

⾯试技巧：你需要去考虑⼀下你负责的系统中是否有类似的场景，就是⼀个系统或者⼀个模块，调⽤了多个系统或者模块，互相之间的调⽤

很复杂，维护起来很⿇烦。但是其实这个调⽤是不需要直接同步调⽤接⼝的，如果⽤MQ给它异步化解耦，也是可以的，你就需要去考虑在

你的项⽬⾥，是不是可以运⽤这个MQ去进⾏系统的解耦。在简历中体现出来这块东西，⽤MQ作解耦。

异步

再来看⼀个场景，A系统接收⼀个请求，需要在⾃⼰本地写库，还需要在BCD三个系统写库，⾃⼰本地写库要3ms，BCD三个系统分别写

库要300ms、450ms、200ms。最终请求总延时是3+300+450+200=953ms，接近1s，⽤户感觉搞个什么东西，慢死了慢死了。⽤户

通过浏览器发起请求，等待个1s，这⼏乎是不可接受的。

mq-3

⼀般互联⽹类的企业，对于⽤户直接的操作，⼀般要求是每个请求都必须在200ms以内完成，对⽤户⼏乎是⽆感知的。

如果使⽤MQ，那么A系统连续发送3条消息到MQ队列中，假如耗时5ms，A系统从接受⼀个请求到返回响应给⽤户，总时长是3+5=

8ms，对于⽤户⽽⾔，其实感觉上就是点个按钮，8ms以后就直接返回了，爽！⽹站做得真好，真快！

mq-4

削峰

每天0:00到12:00，A系统风平浪静，每秒并发请求数量就50个。结果每次⼀到12:00~13:00，每秒并发请求数量突然会暴增到5k+

条。但是系统是直接基于MySQL的，⼤量的请求涌⼊MySQL，每秒钟对MySQL执⾏约5k条SQL。

⼀般的MySQL，扛到每秒2k个请求就差不多了，如果每秒请求到5k的话，可能就直接把MySQL给打死了，导致系统崩溃，⽤户也就没

法再使⽤系统了。

但是⾼峰期⼀过，到了下午的时候，就成了低峰期，可能也就1w的⽤户同时在⽹站上操作，每秒中的请求数量可能也就50个请求，对整

个系统⼏乎没有任何的压⼒。

[图⽚上传失败...(image-6444f7-1548645188187)]

如果使⽤MQ，每秒5k个请求写⼊MQ，A系统每秒钟最多处理2k个请求，因为MySQL每秒钟最多处理2k个。A系统从MQ中慢慢拉取

请求，每秒钟就拉取2k个请求，不要超过⾃⼰每秒能处理的最⼤请求数量就ok，这样下来，哪怕是⾼峰期的时候，A系统也绝对不会挂

掉。⽽MQ每秒钟5k个请求进来，就2k个请求出去，结果就导致在中午⾼峰期（1个⼩时），可能有⼏⼗万甚⾄⼏百万的请求积压在MQ

中。

mq-6

这个短暂的⾼峰期积压是ok的，因为⾼峰期过了之后，每秒钟就50个请求进MQ，但是A系统依然会按照每秒2k个请求的速度在处理。

所以说，只要⾼峰期⼀过，A系统就会快速将积压的消息给解决掉。

消息队列有什么优缺点

优点上⾯已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。

缺点有以下⼏个：