方便可以修改源代码,而非一味地等待软件提供商猴年马月发布的下个版本解决。在知识产权下,使用开源的才可商用。
只要你的使用场景不冷门,你遇到Bug的概率非常低,因为大部分你可能遇到的,其他人早就遇到并且修复。使用过程中遇到的一些问题,也容易在网上搜索到类似的,然后找到解决方案。和其他框架也能无缝对接。
高可用性。
具备足够好的性能,能满足绝大多数场景的性能要求。
看完标准,于是市面上主要就如下可供选择:
Erlang语言编写,最早是为电信行业系统可靠通信设计,是支持AMQP协议的消息队列之一。相当轻量级的消息队列,非常容易部署和使用。号称世上使用最广泛的开源消息队列。
和其他消息队列不同,它在生产者(Producer)和队列(Queue)之间增加了一个Exchange模块。 作用和交换机相似,根据配置的路由规则将生产者发出的消息分发到不同队列。 路由规则也非常灵活,甚至你可以自己来实现路由规则。如果你正好需要该功能,RabbitMQ是个不错选择。
所有消息队列中最多的。
设计理念:消息队列是一个管道,大量的消息积压是一种不正常的情况,应当尽量避免。 当大量消息积压的时候,RabbitMQ的性能急剧下降。
介绍的这几个消息队列中最差的,根据官方给出的测试数据综合我们日常使用的经验,依据硬件配置的不同,它大概可以处理几w~十几w条/s。也足够支撑绝大多数应用场景了,不过,如果你的应用对消息队列的性能要求非常高,那不要选RabbitMQ。
小众语言,学习曲线非常陡峭。如果想做扩展和二次开发,慎重考虑维护问题。
阿里巴巴在2012年开源的消息队列产品,后来捐赠给 Apache 软件基金会,2017正式毕业,成为Apache的顶级项目。阿里内部也是使用RocketMQ作为支撑其业务的消息队列,经历过多次“双十一”考验,它的性能、稳定性和可靠性都是值得信赖的。作为优秀的国产消息队列,近年来越来越多的被国内众多大厂使用。
RocketMQ有着不错的性能,稳定性和可靠性,具备一个现代的消息队列应该有的几乎全部功能和特性,且还在持续成长。
RocketMQ是怎么做到低延时的? 主要是设计上的选择问题,Kafka中到处都是“批量和异步”设计,它更关注的是整体的吞吐量,而RocketMQ的设计选择更多的是尽量及时处理请求。 比如发消息,同样是用户调用了send()方法,RockMQ它会直接把这个消息发出去,而Kafka会把这个消息放到本地缓存里面,然后择机异步批量发送。 所以,RocketMQ它的时延更小一些,而Kafka的吞吐量更高。
作为国产的消息队列,相比国外的比较流行的同类产品,在国际上还没有那么流行,与周边生态系统的集成和兼容程度要略逊一筹。
最早由LinkedIn开发,目前也是Apache顶级项目。最初的设计目的是用于处理海量的日志。
在早期的版本中,为了获得极致性能,在设计方面做了很多的牺牲,比如:
这些牺牲对于处理海量日志这个特定的场景都是可以接受的。这个时期的Kafka甚至不能称之为一个合格的消息队列。
但作为后起之秀。随后Kafka逐步补齐这些短板,你在网上搜到的很多消息队列的对比文章还在说Kafka不可靠,其实这种说法早已过时。当下的Kafka已经发展为一个非常成熟的消息队列产品,无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求(快手就在使用其作为消息队列)。
在有足够的客户端并发进行异步批量发送,并且开启压缩的情况下,Kafka的极限处理能力可以超过每秒2000万条消息。
但Kafka这种异步批量的设计带来的问题是,它的同步收发消息的响应时延比较高,因为当客户端发送一条消息的时候,Kafka并不会立即发送出去,而是要等一会儿攒一批再发送,在它的Broker中,很多地方都会使用这种“先攒一波再一起处理”的设计。 当你的业务场景中,每秒钟消息数量没有那么多的时候,Kafka的时延反而会比较高。所以,Kafka不太适合在线业务场景。