一消息队列MQ

Posted 2021-10-27 上善若水

一、MQ的相关概念

1.1、什么是MQ

MQ(Message Queue)，从字面意思上看，本质是个队列，FIFO先入先出，只不过队列中存放的内容是message而已，还是一种跨进程的通信机制，用于上下游传递信息。在互联网架构中，MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了MQ之后，消息发送上游只需要依赖MQ，不用依赖其他服务。

1.2、为什么要用MQ

先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有3个：应用解耦、异步提速、流量削峰。

1.2.1、应用解耦

看这么个场景。A系统发送数据到BCD三个系统，通过接口调用发送。如果E系统也要这个数据呢？那如果D系统现在不需要了呢？A系统负责人几乎崩溃……

在这个场景中，A系统跟其它各种乱七八糟的系统严重耦合，A系统产生一条比较关键的数据，很多系统都需要A系统将这个数据发送过去。A系统要时时刻刻考虑BCDE四个系统，如果挂了该咋办？要不要重发，要不要把消息存起来？
如果使用MQ，A系统产生一条数据，发送到MQ里面去，哪个系统需要数据自己去MQ里面消费。如果新系统需要数据，直接从MQ里消费即可；如果某个系统不需要这条数据了，就取消对MQ消息的消费即可。这样下来，A系统压根不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。
总结： 通过一个MQ，Pub [pʌb] / Sub [sʌb] 发布订阅消息这么一个模型，A系统就跟其它系统彻底解耦了。
面试技巧： 你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用MQ给它异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个MQ去进行系统的解耦。在简历中体现出来这块东西，用MQ做解耦。

1.2.2、异步提速

再来看一个场景，A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个1s，这几乎是不可接受的。

一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在200ms以内完成，对用户几乎是无感知的。
如果使用MQ，那么A系统连续发送3条消息到MQ队列中，假如耗时5ms，A系统从接受一个请求到返回响应给用户，总时长是3 + 5 = 8 ms，对于用户而言，其实感觉就是点了个按钮，8ms以后就直接返回了，爽！网站做得真好，真快！

1.2.3、流量削峰

每天0：00到12：00，A系统风平浪静，每秒并发请求数量就是50个。结果每次一到12：00~13：00，每秒并发请求数量突然会暴增到5k+条。但是系统是直接基于mysql的，大量的请求涌入MySQL，每秒钟对MySQL执行约5k条SQL。一般的MySQL，扛到每秒2k个请求就差不多了，如果每秒请求到5k的话，可能就直接把MySQL给打死了，导致系统崩溃，用户也就没法再使用系统了。
但是高峰期一过，到了下午的时候，就成了低峰期，可能也就1w的用户同时在网站上操作，每秒中的请求数量可能也就50个请求，对于整个系统几乎没有任何的压力。
如果使用MQ，每秒5k个请求写入MQ，A系统每秒钟最多处理2k个请求，因为MySQL每秒钟最多处理2k个。A系统从MQ中慢慢拉取请求，每秒钟就拉取2k个请求，不要超过自己每秒能处理的最大请求数量就ok，这样下来，哪怕是高峰期的时候，A系统也绝对不会挂掉。而MQ每秒钟5k个请求进来，就2k个请求出去，结果导致在中午高峰期(1个小时)，可能有十几万甚至几百万的请求积压在MQ中。

这个短暂的高峰期积压是ok的，因为高峰期过了之后，每秒钟就50个请求进MQ，但是A系统依然会按照每秒2k个请求的速度在处理。所以说，只要高峰期一过，A系统就会快速将积压的消息给解决掉。

1.3、MQ的优缺点

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

缺点有以下几个：

• 系统可用性降低
  系统引入的外部依赖越多，越容易挂掉。本来你就是A系统调用BCD三个系统的接口就好了，ABCD四个系统还好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ一挂，整套系统崩溃，你不就完了？如果保证消息队列的高可用，后续探讨。
• 系统复杂度提高
  硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？……
• 一致性问题
  A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统哪里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。
  所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来得坏处做各种额外得技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻，用，还是得用的。

1.4、MQ的选择

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，比RocketMQ、Kafka低一个数量级	同ActiveMQ	10万级，支撑高吞吐	10万级，高吞吐，一般配合大数据类的系统来进行实时数据计算，日志采集等场景
topic数量对吞吐量的影响			topic可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic	topic从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka尽量保证topic数量不要过多，如果要支撑大规模的topic，需要增加更多的机器资源。
时效性	ms级	微秒级，这是RabbitMQ的一大特点，延迟最低	ms级	延迟在ms级以内
可用性	高，基于主从架构实现高可用	同ActiveMQ	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
功能支持	MQ领域的功能极其完备	基于erlang ['ə:læŋ] 开发，并发能力很强，性能极好，延时很低	MQ功能较为完善，还是分布式的，扩张性好。	功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用

综上，各种对比之后，有如下建议：
一般的业务系统要引入MQ，最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐这个了；

后来大家开始用RabbitMQ，但是确实erlang语言阻止了大量的Java工程师去深入研究和掌握它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高；

不过现在确实越来越多的公司去用RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前RocketMQ已捐给Apache，但GitHub上的活跃度其实不算高），推荐用RocketMQ，否则回去老老实实用RabbitMQ吧，人家有活跃的开源社区，绝对不会黄。

所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择。

如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。