消息队列 ActiveMQ 、RocketMQ 、RabbitMQ 和 Kafka 如何选择？

 

「 预计阅读 6 分钟 」

旁白：这是一篇拖更了N久的文章...0.0（看不见我~）

往期回顾

前端框架 jQuery 和 Vue 如何选择？

安全框架 Shiro 和 Spring Security 如何选择？

正文

 

消息队列（MQ）

在百度百科中，消息队列（MQ）是这么解释的：“消息队列”是在消息的传输过程当中保存消息的容器（可存可取）。

它是分布式系统中重要的组件，使用消息队列主要是为了经过异步处理提升系统性能和削峰和下降系统耦合性。

• 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比较串行处理，减小处理时间；

• 应用耦合：多应用经过消息队列对同一消息进行处理，避免调用接口失败致使整个过程失败；

• 限流消峰：普遍应用于秒查或抢购活动中，避免某一刻流量过致使应用系统挂掉的状况；

目前使用较多的消息队列有 ActiveMQ 、RocketMQ 、RabbitMQ 和 Kafka 等。

消息队列的两种模式

消息队列包括两种模式：点对点模式 和 发布/订阅模式。

1）点对点模式

点对点模式下包括三个角色：

• 消息队列

• 发送者 (生产者)

• 接收者（消费者）

消息发送者生产消息发送到queue中，而后消息接收者从queue中取出而且消费消息。消息被消费之后，queue中再也不有存储，因此消息接收者不可能消费到已经被消费的消息。

点对点模式特色：

• 每一个消息只有一个接收者（Consumer）(即一旦被消费，消息就再也不在消息队列中)；

• 发送者和接收者间没有依赖性，发送者发送消息以后，无论有没有接收者在运行，都不会影响到发送者下次发送消息；

• 接收者在成功接收消息以后需向队列应答成功，以便消息队列删除当前接收的消息；

2）发布/订阅模式

发布/订阅模式下包括三个角色：

• 角色主题（Topic）

• 发布者(Publisher)

• 订阅者(Subscriber)

发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。

发布/订阅模式特色：

• 每一个消息能够有多个订阅者；

• 发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须建立一个订阅者以后，才能消费发布者的消息。

• 为了消费消息，订阅者须要提早订阅该角色主题，并保持在线运行；

异步处理

具体场景：用户为了使用某个应用，进行注册，系统须要发送注册邮件和注册短信。

对于该流程有两种处理方式：并行和串行。

1）串行处理：写入注册信息后，先发送注册邮件，再发送注册短信。

这种方式下，须要等发送短信处理完成后才完成注册。

2）并行处理：写入注册信息后，同时处理发邮件和发短信。

这种方式下，须要等发送短信和发送邮件处理完成后才完成注册。

假设上面三个子系统处理耗时均为：50ms，且不考虑网络延迟，系统卡顿等因素，则总的处理时间为：

串行：50ms + 50ms + 50 ms = 150ms

并行：50ms + 50ms = 100ms

使用消息队列结果将如何呢？

若使用消息队列，写入完注册信息后，再将信息写入消息队列就能直接返回成功给客户端了，而后注册完成。

如今总的响应时间依赖于写入消息队列的时间，而写入消息队列的时间是很快的，基本能够忽略不计。所以总的处理时间相比串行提升了 2 倍，相比并行提升了 1 倍。

应用解耦

具体场景：A 系统每次产生数据时，都要将数据发给 BC 两个系统（经过接口调用）。这个时候新增了一个 D 系统，以下图：

在这个场景中，A 系统和其余几个系统乱七八糟的耦合在一块儿，当 A 系统中产生一条数据时，须要将数据发给各个系统。

每次项目中新增了系统，A 系统都须要修改代码，还要时刻担忧那个系统挂掉了，信息没发送过去要不要重发，那个系统又不要该数据了，这时求 A 系统负责人的心理阴影...

若是使用 MQ，A 系统产生一条数据后，只须要插入到 MQ 里面去，那个系统须要就去 MQ 里消费。若是新增了一个系统，那么订阅 MQ 的消息便可；同理那个系统再也不须要该数据，那么只要取消订阅就好了。

经过一个 MQ， Pub/Sub 发布订阅消息模型，A 系统就跟其余系统实现解耦了。

限流削峰

具体场景：某电商网站开展秒杀活动，通常因为瞬间访问暴增，服务器收到请求过大，可能出现没法处理请求或崩溃的状况。

加入消息队列后，系统就能够从消息队列中读取数据，至关于作了一次缓冲，超出系统处理以外的请求会积压在消息队列中，等高峰期已过，就会快速将积压在队列中的数据处理完。

消息队列有什么优缺点

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

缺点有如下几个：

• 系统可用性下降
  系统引入的外部依赖越多，越容易挂掉。原本你就是 A 系统调用 BCD 三个系统的接口就行了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套系统崩溃的，你不就完了？如何保证消息队列的高可用，能够点击这里查看。
• 系统复杂度提升
  硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的状况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。
• 一致性问题
  A 系统处理完了直接返回成功了，人都觉得你这个请求就成功了；可是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。

因此消息队列实际是一种很是复杂的架构，你引入它有不少好处，可是也得针对它带来的坏处作各类额外的技术方案和架构来规避掉，作好以后，系统复杂度提高了一个数量级，也许是复杂了 10 倍。可是关键时刻，用，仍是得用的。

RabbitMQ/ActiveMQ/RocketMQ/Kafka对比

这里列举了上述四种消息队列的差别对比（图片来源：https://www.cnblogs.com/javalyy/p/8856731.html）：

图片来源（https://doocs.gitee.io/advanced-java/#/docs/high-concurrency/why-mq）

总结

通常业务系统要引入 MQ，最先你们都是用 ActiveMQ，可是如今你们用的很少了，没通过大规模吞吐量场景的验证，社区也不是很活跃，不推荐使用。

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

若是是高性能分布式、大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准。

普遍来讲，电商、金融等对事务性要求很高的，能够考虑RabbitMQ和RocketMQ，对性能要求高的可考虑Kafka。

 

若是你以为文章不错，欢迎在看、转发、赞扬一条龙，你的支持就是我最大的动力。

 

本文原发于 同名微信公众号「程序员的成长之路」，回复「1024」你懂得，给个赞呗。

回复 [ 520 ] 领取程序员最佳学习方式

回复 [ 256 ] 查看 Java 程序员成长规划