一. 选择的基本标准
-
必须是开源产品。
在你遇到一个bug影响你线上的业务时,你至少还可以通过修改源代码进行问题修复。而不是束手无策等待开发者不知道在未来的哪个版本中会修复这个问题。 -
必须是近年来比较流行,社区比较活跃的产品。
流行的好处是:只要你的使用场景不冷门,遇到bug的概率会很低,因为你遇到的bug别人可能早已遇到并修复了,同时在使用中遇到问题时也比较容易找到解决方案。 -
与周边系统有比较好的集成和兼容。
-
作为一款及格的消息队列产品,必须具备如下特性:
- 消息的可靠传递,确保消息不丢。
- 支持集群(Cluster)。
- 性能:具备足够好的性能,能满足绝大多数场景的性能要求。
二. 可供选择的消息队列产品
名称 | 开发语言 | 优点 | 缺点 |
---|---|---|---|
RabbitMQ | Erlang | 轻量、开箱即用、灵活的路由配置、极其丰富的客户端编程语言支持 | 对消息堆积的支持不好、性能一般(几万~十几万/s)、开发语言小众且Erlang 的学习曲线陡峭 |
RocketMQ | Java | 不错的性能(几十万/s)、稳定性和可靠性,扩展和二次开发容易,毫秒级的响应延时 | 与周边生态的集成和兼容性一般 |
Kafka | Java、Scala | 周边生态的集成和兼容性好、超高的性能 | 同步收发的响应延时较严重、不适合在线业务场景 |
三. 第二梯队的消息队列
除了上面的三大消息队列产品外,还有几个第二梯队消息队列产品,他们之所以没有那么流行,或多或少都有着比较明显的短板,不推荐使用。
- ActiveMQ: 最老牌的消息队列,已进入老年期,社区不活跃,无能是性能还是功能与现代消息队列存在明显的差距。
- ZeroMQ: 严格说不是一个消息队列,而是一个基于消息队列的多线程的网络库。
- Pulsar: 新兴的开源消息队列产品,雅虎开发,目前处于成长期,与其他消息队列最大的不同采用存储和计算分离的设计。这种设计可能引领未来消息队列的方向,可以持续关注。
说明: 文章通过李玥老师的消息队列选型整理而成。