RabbitMQ、Kafka、RocketMQ正确选型姿势【消息中间件篇】

大家想一想在你们平时开发的系统里面有没有这种情况，就是你们系统会调用到第三方接口服务，而且这个接口服务是在你流程里面进行同步调用的，这个时候你们的系统性能是直接和第三方接口服务挂钩的，也就是第三方接口服务性能的好坏直接影响到你自己的系统。

我想大部分人都遇到过这样的系统调用吧，我们公司也经常遇到，合作商给的接口，就直接同步调用了，上个月我们有一个第三方接，开始组员调研时没太仔细，以为对于我们业务影响不是太大，就采用了直接同步调用，以至于线上运行两周后内存增长迅速，性能吞吐量逐渐下降，后来发现是因为三方接口性能支撑不住我们现有并发。如是就改成了异步，使用我们的消息中间件MQ来解决此类情况，那么今天我们就先来聊聊相关中间件的必经之路，即调研和如何取舍的话题

什么是消息中间件

说到消息中间件，我想大家应该并不陌生，或多或少都有所接触。其实通俗的理解就是，消息中间件MQ也就是一种开发好的系统，并且独立部署，然后我们业务系统通过它来发消息和收消息以至于达到异步调用的效果。

消息中间件有什么用处

消息中间件既然被发明出来，肯定是有诸多好处的，是能解决我们实际问题的，对我们开发最直接的影响就是提升系统性能、系统间解耦、流量削峰等，下面分别对其解释下，方便大家更好的去理解MQ。

1，异步化提升系统性能

现在假设有两个系统A和B，其中A系统处理业务大概20毫秒，B系统处理业务大概180毫秒，然后A系统调用B系统这一过程一共是花了200毫秒。如果这里使用了消息中间件的话，则是A系统处理业务20毫秒，发送消息到MQ中2毫秒然后就直接返回给用户了，B系统什么时候去MQ中取消息A系统此时是不管的，所以对于用户来说22毫秒就得到了返回，即使用MQ直接提升了我们系统的性能。

 

2，系统间解耦

如上A B系统所示，即使B系统出现了故障，于A系统来说是不关心的，即用户也就是无感知的，B系统恢复了就会自动再去取消息来处理业务。所以，消息中间件能使系统间解耦，且使系统间不互相直接影响。

3，大流量削峰

现在假设我们在做双十二活动促销的时候，在线系统A面临过万的QPS，而另一个后端数据系统B只能处理每秒5000左右的并发，这个时候如果我们将并发全部打到B系统的话，很可能就会挂掉了，即促销活动就会失败。而我们现在引入消息队列MQ，将1万+的并发先打到MQ中，然后B系统就可以按照他自己的5000并发的处理能力来从MQ中获取消息，这样就完成了我们业务中大流量削峰的作用。

基于什么需求去调研消息队列

我们在去调研以及去学习消息队列的时候，一定要时刻将自己的调研目的带上，要清楚自己想要什么，希望消息队列给我们带来什么实质性的好处。所以，这里建议大家基于下面这几个大点去考虑自己的消息队列：

• 首先要调研出我们当今业内最常用的MQ有哪些？
• 然后逐一看各个MQ是如何表现的，即它各自有什么特点等。
• 这些个MQ在同等机器配置的情况下，到底能抗住多少的QPS，是几千呢还是几万呢还是会更多呢？
• 这些MQ各自性能怎么样？即考虑收发消息大概要几毫秒。
• MQ本身支不支持高可用，是否易扩展。假设宕机了它有没有什么故障迁移、数据防丢失的方案。
• 消息中间件的常用功能是否具备，比如延迟消息、事务消息、消息堆积、消息回溯、死信队列等。
• 社区是否活跃？文档是否齐全？应用的广度如何？基于什么语言开发的？

如果带着这些问题去调研消息队列MQ，我相信，大家肯定就觉得没那么难了，肯定会挑选出适合自己适合公司业务发展的消息中间件的，那接下来，我就基于我们公司的业务来看看目前应用广泛的Kafka、RabbitMQ以及RocketMQ，该怎么去选型

Kafka、RabbitMQ以及RocketMQ调研

起初当我们准备引入消息队列的时候，一共发现业界内使用很多的有四种MQ，分别是ActiveMQ、Kafka、RabbitMQ、RocketMQ。由于ActiveMQ目前并不是很活跃了，就直接没去深入对比了，前几年这个MQ用的还是比较多的，我在2015年之前在金融机构的项目基本都是基于ActiveMQ来做的。所以，我们今天就对Kafka、RabbitMQ、RocketMQ这三种MQ来做个选型对比

Kafka的优缺点

我们先来看看大家特别熟悉的Kafka中间件。

优点：

1. 首先，Kafka的最大优势就在于它的高吞吐量，在普通机器4CPU8G的配置下，一台机器可以抗住十几万的QPS，这一点还是相当优越的。
2. 其次，Kafka的性能同样很高，发送消息过去基本都是毫秒级别的。
3. Kafka支持集群部署，如果部分机器宕机不可用，则不影响Kafka的正常使用。

缺点：

1. Kafka有可能会造成数据丢失，因为它在收到消息的时候，并不是直接写到物理磁盘的，而是先写入到磁盘缓冲区里面的。
2. Kafka功能比较的单一 主要的就是支持收发消息，高级功能基本没有，就会造成适用场景受限。

业界里一般将kafka用来处理用户的行为日志的采集的传输，用在大数据团队较多，我们公司同样也引入了它，就只是用来收发消息这种的场景，如用户行为日志等。因为，可以接受数据的丢失，而且要求吞吐量要极高。

RabbitMQ的优缺点

其实在RabbitMQ开始被广大程序员接受的时候，就有很多公司开始将自己ActiveMQ中间件切换到RabbitMQ中去了，直到现在被使用的频率还是很高的。

优点：

1. RabbitMQ能保证数据不丢失
2. 能保证高可用，部分机器宕机了还可以继续使用。
3. 支持很多高级功能，如消息重试、死信队列等

缺点：

1. 首先是RabbitMQ吞吐量比较低，大概在每秒几万的样子，这样像对于大型电商促销秒杀就不能胜任。
2. 集群线性扩展比较麻烦。
3. 开发语言是erlang，懂得人不是很多，无法对其改造。

RocketMQ的优缺点：

RocketMQ是阿里巴巴开源的消息中间件，各方面也表现的比较优越，几乎同时解决了Kafka和RabbitMQ它们两个的缺点。

优点：

1. 吞吐量很高，大概普通机器有十万QPS往上。
2. 保证高可用，高性能。
3. 保证数据绝对不丢失
4. 支持大规模集群部署，线性扩展方便
5. 支持各种高级的功能，如延迟消息、消息回朔等
6. java语言开发，满足了国内绝大部分公司技术栈

缺点：

目前我觉得唯一的缺点就是文档没有前面两种文档详细，写的稍微简单了点。

该怎么对比选择呢

通过上面的调研结果来看，其实大家应该就能很容易的选出自己的消息队列中间件。同时我这里也给点自己的建议：

1. 如果我们业务只是收发消息这种单一类型的需求，而且可以允许小部分数据丢失的可能性，但是又要求极高的吞吐量和高性能的话，就直接选Kafka就行了，就好比我们公司想要收集和传输用户行为日志以及其他相关日志的处理，就选用的Kafka中间件。
2. 如果自己所处公司业务比较平稳，未来几年内不会出现飞速发展，而且没有什么改源码的特殊需求的话，在面对选择MQ的时候就可以选用RabbitMQ。毕竟如今这样的中小公司也就是这么干的。
3. 如果自己所处公司发展迅猛，一年经常搞一些特别大的促销秒杀活动，公司技术栈主要是Java语言的话，就直接一步到位选择RocketMQ，这样会省很多事情。

总结，今天我们讲到了消息中间件如何被引入到业务系统中来，同时知道了消息中间件能给我们业务带来各种实质性的好处。最后调研了Kafka、RabbitMQ以及RocketMQ这三种业内使用较为广泛的消息中间件，分析了各自的优缺点，最后选出更能适合我们自己业务发展的中间件。如果大家喜欢，或是对大家有所帮助就关注我，我会一直分享业界流行技术方案，让我们共同学习共同进步。