Fork me on GitHub

RabbitMq、kafka、ActiveMq、ZeroMq之间的比较

RabbitMQ,ActiveMq,ZeroMq比较

吞度量(TPS)

  都是采用默认配置的,并无调优。
  ZeroMq 最好,RabbitMq次之, ActiveMq最差

  TPS : Transaction Per Second, 每秒事务数, 是衡量系统性能的一个非常重要的指标,
  并发用户数(Vu): 指的是现实系统中操作业务的用户,在性能测试工具中,一般称为虚拟用户数(Virutal User),注意并发用户数跟注册用户数、在线用户数有很大差别的,并发用户数一定会对服务器产生压力的,而在线用户数只是 “挂”在系统上,对服务器不产生压力,注册用户数一般指的是数据库中存在的用户数。
  响应时间: 一般取平均响应时间
  QPS(TPS)= 并发数/平均响应时间

持久化消息比较

  zeroMq不支持,activeMq和rabbitMq都支持。
  持久化消息主要是指:MQ down或者MQ所在的服务器down了,消息不会丢失的机制。

技术点:可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统、社区

  RabbitMq最好,ActiveMq次之,ZeroMq最差。
  当然ZeroMq也可以做到,不过自己必须手动写代码实现,代码量不小。尤其是可靠性中的:持久性、投递确认、发布者证实和高可用性。
  所以在可靠性和可用性上,RabbitMQ是首选,虽然ActiveMQ也具备,但是它性能不及RabbitMQ。

高并发

  从实现语言来看,RabbitMQ最高,原因是它的实现语言是天生具备高并发高可用的erlang语言。

总结:

  按照目前网络上的资料,RabbitMQ、activeM、zeroMQ三者中,综合来看,RabbitMQ是首选。


kafka和RabbitMQ的比较

  关于这两种MQ的比较,最权威的的是kafka的提交者写一篇文章。What are the differences between Apache Kafka and RabbitMQ?
  里面提到的要点:
  1、RabbitMq比kafka成熟,在可用性上,稳定性上,可靠性上,RabbitMq超过kafka
  2、Kafka设计的初衷就是处理日志的,可以看做是一个日志系统,针对性很强,所以它并没有具备一个成熟MQ应该具备的特性
  3、Kafka的性能(吞吐量、tps)比RabbitMq要强,这篇文章的作者认为,两者在这方面没有可比性
  kafka是一个高吞吐量的分布式发布订阅日志服务。目前已经在各大公司中广泛使用。和Redis做轻量级消息队列不同,kafka利用磁盘作队列,所以也就无所谓消息缓冲时的磁盘问题。

在应用场景方面,

  RabbitMQ,遵循AMQP协议,由内在高并发的erlanng语言开发,用在实时的对可靠性要求比较高的消息传递上。
  kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。

在架构模型方面,

  RabbitMQ遵循AMQP协议,RabbitMQ的broker由Exchange,Binding,queue组成,其中exchange和binding组成了消息的路由键;客户端Producer通过连接channel和server进行通信,Consumer从queue获取消息进行消费(长连接,queue有消息会推送到consumer端,consumer循环从输入流读取数据)。rabbitMQ以broker为中心;有消息的确认机制。
  kafka遵从一般的MQ结构,producer,broker,consumer,以consumer为中心,消息的消费信息保存的客户端consumer上,consumer根据消费的点,从broker上批量pull数据;无消息确认机制。

在吞吐量,

  kafka具有高的吞吐量,内部采用消息的批量处理,zero-copy机制,数据的存储和获取是本地磁盘顺序批量操作,具有O(1)的复杂度,消息处理的效率很高。
  rabbitMQ在吞吐量方面稍逊于kafka,他们的出发点不一样,rabbitMQ支持对消息的可靠的传递,支持事务,不支持批量的操作;基于存储的可靠性的要求存储可以采用内存或者硬盘。

在可用性方面,

  rabbitMQ支持miror的queue,主queue失效,miror queue接管。
  kafka的broker支持主备模式。

在集群负载均衡方面,

  kafka采用zookeeper 对集群中的broker、consumer进行管理,可以注册topic到zookeeper上;通过zookeeper的协调机制,producer保存对应topic的broker信息,可以随机或者轮询发送到broker上;并且producer可以基于语义指定分片,消息发送到broker的某分片上。
  rabbitMQ的负载均衡需要单独的loadbalancer进行支持。

总结

​  所以关于这两个选择,我们还是了解了这4个大致的区别。关于高吞吐,以及我们队日志的特定场景分析,任然选择了,kafka。当然设计理念不一样,rabbitMQ用于可靠的消息传递,智齿事物,不支持批量的操作,可用性差不多,只是实现不一样。在集群方面,kafka胜一筹,通过topic注册zookeeper,调用机制,实现语义指定分片,然而rabbitMQ的负载需要单独loadbalancer支持  
  两者对比后,还是选择RabbitMq,性能其实是很强劲的,同时具备了一个成熟的MQ应该具有的特性,我们无需重新发明轮子。


参考文章:
  kafka原理简介并且与RabbitMQ的选择
  rabbitmq和kafka

-----------------本文结束,感谢您的阅读-----------------