春招面试复习：消息队列（二）- MQ选型

Myth丶恋晨 2023-01-06 05:59 134阅读 0赞

# 1 MQ选型的标准 #

## 1.1 开源（白嫖） ##

方便可以修改源代码，而非一味地等待软件提供商猴年马月发布的下个版本解决。在知识产权下，使用开源的才可商用。

## 1.2 生态（大家都玩） ##

只要你的使用场景不冷门，你遇到Bug的概率非常低，因为大部分你可能遇到的，其他人早就遇到并且修复。使用过程中遇到的一些问题，也容易在网上搜索到类似的，然后找到解决方案。和其他框架也能无缝对接。

## 1.3 确保消息可靠传递 ##

## 1.4 Cluster ##

高可用性。

## 1.5 性能（用户就爱快的） ##

具备足够好的性能，能满足绝大多数场景的性能要求。

看完标准，于是市面上主要就如下可供选择：

# 2 RabbitMQ #

## 2.1 优点 ##

Erlang语言编写，最早是为电信行业系统可靠通信设计，是支持AMQP协议的消息队列之一。相当轻量级的消息队列，非常容易部署和使用。号称世上使用最广泛的开源消息队列。

### 支持非常灵活的路由配置 ###

和其他消息队列不同，它在生产者（Producer）和队列（Queue）之间增加了一个Exchange模块。作用和交换机也非常相似，根据配置的路由规则将生产者发出的消息分发到不同的队列中。路由的规则也非常灵活，甚至你可以自己来实现路由规则。如果你正好需要该功能，RabbitMQ是个不错选择。

### 支持的客户端语言 ###

所有消息队列中最多的。

## 2.2 缺点 ##

### 消息堆积的支持不好 ###

设计理念：消息队列是一个管道，大量的消息积压是一种不正常的情况，应当尽量避免。  
当大量消息积压的时候，RabbitMQ的性能急剧下降。

### 性能 ###

介绍的这几个消息队列中最差的，根据官方给出的测试数据综合我们日常使用的经验，依据硬件配置的不同，它大概每秒钟可以处理几万到十几万条消息。其实，这个性能也足够支撑绝大多数的应用场景了，不过，如果你的应用对消息队列的性能要求非常高，那不要选RabbitMQ。

### Erlang ###

小众语言，学习曲线非常陡峭。如果想做扩展和二次开发，慎重考虑维护问题。

# 3 RocketMQ #

阿里巴巴在2012年开源的消息队列产品，后来捐赠给 Apache 软件基金会，2017正式毕业，成为Apache的顶级项目。阿里内部也是使用RocketMQ作为支撑其业务的消息队列，经历过多次“双十一”考验，它的性能、稳定性和可靠性都是值得信赖的。作为优秀的国产消息队列，近年来越来越多的被国内众多大厂使用。

RocketMQ有着不错的性能，稳定性和可靠性，具备一个现代的消息队列应该有的几乎全部功能和特性，且还在持续成长。

## 3.1 优点 ##

*  非常活跃的中文社区  
    大多数问题你都可以找到中文的答案，也许会成为你选择它的一个原因。
 *  RocketMQ使用Java语言开发  
    贡献者大多数都是中国人，源代码相对也比较容易读懂，你很容易对RocketMQ进行扩展或者二次开发。
 *  RocketMQ对在线业务的响应时延做了很多的优化  
    大多数情况下可以做到毫秒级的响应，如果你的应用场景很在意响应时延，那应该选择使用RocketMQ。

> rocketMQ是怎么做到低延时的？  
> 主要是设计上的选择问题，Kafka中到处都是“批量和异步”设计，它更关注的是整体的吞吐量，而RocketMQ的设计选择更多的是尽量及时处理请求。  
> 比如发消息，同样是用户调用了send()方法，RockMQ它会直接把这个消息发出去，而Kafka会把这个消息放到本地缓存里面，然后择机异步批量发送。  
> 所以，RocketMQ它的时延更小一些，而Kafka的吞吐量更高。

*  RocketMQ的性能比RabbitMQ要高一个数量级  
    每秒钟大概能处理几十万条消息。

## 3.2 缺点 ##

RocketMQ的一个劣势是，作为国产的消息队列，相比国外的比较流行的同类产品，在国际上还没有那么流行，与周边生态系统的集成和兼容程度要略逊一筹。

# 4 Kafka #

最早由LinkedIn开发，目前也是Apache顶级项目。最初的设计目的是用于处理海量的日志。

在早期的版本中，为了获得极致的性能，在设计方面做了很多的牺牲，比如：

*  不保证消息的可靠性
 *  可能会丢失消息
 *  不支持集群
 *  功能上也比较简陋

这些牺牲对于处理海量日志这个特定的场景都是可以接受的。这个时期的Kafka甚至不能称之为一个合格的消息队列。

但作为后起之秀。随后Kafka逐步补齐这些短板，你在网上搜到的很多消息队列的对比文章还在说Kafka不可靠，其实这种说法早已过时。当下的Kafka已经发展为一个非常成熟的消息队列产品，无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求（快手就在使用其作为消息队列）。

## 4.1 优点 ##

*  Kafka与周边生态系统的兼容性最好  
    尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持Kafka。
 *  Kafka使用Scala和Java语言开发  
    设计上大量使用了批量和异步的思想，这种设计使得Kafka能做到超高的性能。可维护性也好，会 java 即可。
 *  Kafka的性能  
    尤其是异步收发的性能，三者中最好，但与RocketMQ并无量级差异，大约每秒钟可处理几十万条消息。

> 在有足够的客户端并发进行异步批量发送，并且开启压缩的情况下，Kafka的极限处理能力可以超过每秒2000万条消息。

## 4.2 缺点 ##

但Kafka这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka并不会立即发送出去，而是要等一会儿攒一批再发送，在它的Broker中，很多地方都会使用这种“先攒一波再一起处理”的设计。  
当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka的时延反而会比较高。所以，Kafka不太适合在线业务场景。

*  ActiveMQ  
    最老牌的开源消息队列，十年前唯一可供选择的开源消息队列，目前已进入老年期，社区不活跃。无论是功能还是性能方面，ActiveMQ都与现代的消息队列存在明显的差距，它存在的意义仅限于兼容那些还在用的爷辈儿系统。
 *  ZeroMQ  
    严格来说ZeroMQ并不能称之为一个消息队列，而是一个基于消息队列的多线程网络库，如果你的需求是将消息队列的功能集成到你的系统进程中，可以考虑使用ZeroMQ。
 *  Pulsar  
    Pulsar是一个新兴的开源消息队列产品，最早是由Yahoo开发，目前处于成长期，流行度和成熟度相对没有那么高。与其他消息队列最大的不同是，Pulsar采用存储和计算分离的设计，我个人非常喜欢这种设计，它有可能会引领未来消息队列的一个发展方向，建议你持续关注这个项目。  
    目前已经在使用Pulsar的公司已经不少了,国内的话有下面几家:  
    涂鸦智能、腾讯计费系统、智联招聘、甜橙金融、EMQX。

# 5 选型总结 #

如果消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，建议RabbitMQ。  
如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那RocketMQ的低延迟和金融级的稳定性是你需要的。

如果需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那Kafka是最适合。