消息队列解析(2)-MQ选型

1 选型标准

1.1 开源（白嫖）

方便修改源码，而非阻塞等待软件提供商猴年马月发布下个版本解决。

1.2 生态（大家一起玩）

方便找到很多问题的解决方案，和主流框架也无缝对接。

1.3 确保消息可靠传递

1.4 Cluster

高可用性。

1.5 性能

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

于是市面上主要就如下可供选择：

2 RabbitMQ

2.1 优点

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

灵活的路由配置

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

支持的客户端语言

所有消息队列中最多的。

2.2 缺点

消息堆积的支持不好

设计理念：MQ是个管道，大量消息积压是不正常情况，应尽量避免。
消息积压时，RabbitMQ性能会急剧下降。

性能

本文几个MQ中最差，依据硬件配置不同，大概可处理几w~十几w条/s，也足够支撑绝大多数应用场景了。但性能要求更高的就不要选了。

Erlang

小众。想做扩展和二次开发就很难的啦。

3 RocketMQ

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

3.1 优点

• 活跃的中文社区
  大多数问题你都可以找到中文答案。

• Java语言开发
  贡献者大多数都是中国人，源码相对易懂，方便二次开发。

• 对在线业务的响应时延做了很多优化
  大多数情况下可做到ms级响应，如果你的应用场景很在意响应时延，应选择RocketMQ。

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

• RocketMQ的性能比RabbitMQ要高一个数量级
  大概处理几十w条/s。

3.2 缺点

相比国外的比较流行的同类产品，在国际上还没那么流行，和周边生态系统的集成和兼容程度稍逊。

4 Kafka

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

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

• 不保证消息的可靠性
• 可能丢消息
• 不支持集群
• 功能简陋

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

但作为后起之秀。随后Kafka逐步补齐这些短板，网上文章还在说Kafka不可靠，这种说法早过时了。当下的Kafka已发展为成熟的MQ，无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求。

4.1 优点

• Kafka与周边生态系统的兼容性最好
  尤其在大数据和流计算领域。
• 使用Scala和Java语言开发
  设计上大量使用批量和异步思想，做到超高性能。可维护性也好，会 Java 即可。
• Kafka的性能
  异步收发的性能，三者中最好，但与RocketMQ并无量级差异，大约可处理几十万条消息/s。

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

4.2 缺点

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

其它MQ

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

MQ对比图

总结

• 最早大家都用ActiveMQ，但是现在用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，不推荐
• 后来大家用RabbitMQ，但erlang阻止了Java工程师前进的脚步，几乎不可控。但开源，稳定支持，活跃度也高。如果消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，建议RabbitMQ。
• 消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那就选择RocketMQ的低延迟和金融级稳定性。
• 处理海量消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，Kafka最适合。