消息队列高手课——02 | 该如何选择消息队列？

• 选择消息队列产品的基本标准
  • 消息的可靠传递：确保不丢消息；
  • Cluster：支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息；
  • 性能：具备足够好的性能，能满足绝大多数场景的性能要求。
• 1. RabbitMQ——轻量级，开箱即用
  • Erlang 语言编写的，它最早是为电信行业系统之间的可靠通信设计的，也是少数几个支持 AMQP 协议的消息队列之一
  • RabbitMQ 是一个相当轻量级的消息队列，非常容易部署和使用
• 接下来说下 RabbitMQ 的几个问题
  • 第一个问题是，RabbitMQ 对消息堆积的支持并不好，当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降
  • 第二个问题是，RabbitMQ 的性能是我们介绍的这几个消息队列中最差的
  • 最后一个问题是 RabbitMQ 使用的编程语言 Erlang，这个编程语言不仅是非常小众的语言，更麻烦的是，这个语言的学习曲线非常陡峭。所以如果你想基于 RabbitMQ 做一些扩展和二次开发什么的，建议你慎重考虑一下可持续维护的问题
• 2. RocketMQ——在线业务，低延迟
  • RocketMQ 是阿里巴巴在 2012 年开源的消息队列产品，后来捐赠给 Apache 软件基金会
  • 经历过多次“双十一”考验，它的性能、稳定性和可靠性都是值得信赖的
• 有着不错的性能，稳定性和可靠性
  • 有非常活跃的中文社区，大多数问题你都可以找到中文的答案
  • RocketMQ 使用 Java 语言开发，它的贡献者大多数都是中国人，源代码相对也比较容易读懂，你很容易对 RocketMQ 进行扩展或者二次开发
  • RocketMQ 对在线业务的响应时延做了很多的优化，大多数情况下可以做到毫秒级的响应，如果你的应用场景很在意响应时延，那应该选择使用 RocketMQ
  • RocketMQ 的性能比 RabbitMQ 要高一个数量级，每秒钟大概能处理几十万条消息。
  • RocketMQ 的一个劣势是，作为国产的消息队列，相比国外的比较流行的同类产品，在国际上还没有那么流行，与周边生态系统的集成和兼容程度要略逊一筹
• 3. Kafka——批量和异步
  • Kafka 最早是由 LinkedIn 开发，目前也是 Apache 的顶级项目。Kafka 最初的设计目的是用于处理海量的日志
  • Kafka 已经发展为一个非常成熟的消息队列产品，无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求
• Kafka 与周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持 Kafka
  • Kafka 使用 Scala 和 Java 语言开发，设计上大量使用了批量和异步的思想，这种设计使得 Kafka 能做到超高的性能。大约每秒钟可以处理几十万条消息
  • 但是 Kafka 这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka 并不会立即发送出去，而是要等一会儿攒一批再发送，在它的 Broker 中，很多地方都会使用这种“先攒一波再一起处理”的设计
  • 当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景
• Pulsar 是一个新兴的开源消息队列产品，最早是由 Yahoo 开发
  • Pulsar 采用存储和计算分离的设计，我个人非常喜欢这种设计，它有可能会引领未来消息队列的一个发展方向，建议你持续关注这个项目
• 小结
  • 1、如果说，消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，我建议你使用 RabbitMQ。
  • 2、如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那 RocketMQ 的低延迟和金融级的稳定性是你需要的。
  • 3、如果你需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合你的消息队列
  • 多套MQ共同作用，RocketMQ做在线业务，Kafka做日志监控