RabbitMq、ActiveMq、Kafka和Redis做Mq对比

一、RabbitMq

RabbitMQ是一个Advanced Message Queuing Protocol(AMQP)的开源实现,由以高性能、可伸缩性出名的Erlang写成。RabbitMQ Server适用的OS有:Windows、Linux/Unix和Mac OS X,RabbitMQ官方的Client有Java、.Net/C#和Erlang。

AMQP协议主要有3个组件:
  • 交换器(Exchange):它是发送消息的实体
  • 队列(Queue):它是接收消息的实体
  • 绑定器(Bind):将交换器和队列连接起来,并且封装消息的路由信息
RabbitMq、ActiveMq、Kafka和Redis做Mq对比_第1张图片

图1  AMQP协议原理图


二、ActiveMq

ActiveMQ是一个完全支持JMS 1.1和J2EE 1.4规范的JMS Provider实现。JMS(Java Messaging Service)是Java平台上有关面向消息中间件的技术规范,它便于消息系统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口简化企业应用的开发。

JMS消息通常有两种类型:
  • 点对点(Point-to-Point):在点对点的消息系统中,消息分发给一个单独的使用者,点对点消息往往与队列相关联。
  • 发布/订阅(Publish/Subscribe):发布/订阅消息系统支持一个事件驱动模型,消息生产者和消费者都参与消息的传递。该类消息一般与特定的主题关联。
三、Kafka

Kafka是一种分布式的,基于发布/订阅的消息系统。Kafka开发语言为Scala,支持跨平台。其设计主要目标如下:
  • 以时间复杂度为O(1)的方式提供消息持久化能力
  • 高吞吐率
  • 支持Kafka Server间的消息分区,及分布式消费,同时保证消息顺序传输
  • 支持离线数据处理和实时数据处理
  • 支持在线水平扩展
RabbitMq、ActiveMq、Kafka和Redis做Mq对比_第2张图片

图2  Kafka结构图


Kafka的优点:

分布式高可扩展。Kafka 集群可以透明的扩展,增加新的服务器进集群;
高性能。Kafka 的性能大大超过传统的ActiveMQ、RabbitMQ等MQ 实现,尤其是Kafka 还支持batch 操作;
容错。Kafka每个Partition的数据都会复制到几台服务器上。当某个Broker故障失效时,ZooKeeper服务将通知生产者和消费者,生产者和消费者转而使用其它Broker。

Kafka的不利:

重复消息。Kafka 只保证每个消息至少会送达一次,虽然几率很小,但一条消息有可能会被送达多次;
消息乱序。虽然一个Partition 内部的消息是保证有序的,但是如果一个Topic 有多个Partition,Partition 之间的消息送达不保证有序;
复杂性。Kafka需要zookeeper 集群的支持,Topic通常需要人工来创建,部署和维护较一般消息队列成本更高。


四、Redis做Mq

Redis是一个高性能的key-value数据库,它的出现很大程度补偿了memcached这类key-value存储的不足。虽然它是一个数据库系统,但本身支持MQ功能,完全可以当做一个轻量级的队列服务器使用。Redis开发语言为C,支持OS为Linux。

Redis从2.0版本开始支持发布/订阅指令,发布者调用redis的publish方法往特定的channel发送消息,订阅者在初始化的时候要订阅到该channel,一旦有消息就会立即接收。

redis 消息推送(基于分布式 pub/sub)多用于实时性较高的消息推送,并不保证可靠。其他的mq和kafka保证可靠但有一些延迟(非实时系统没有保证延迟)。redis-pub/sub断电就清空,而使用redis-list作为消息推送虽然有持久化,但是也并非完全可靠不会丢。

另外一点,redis 发布订阅除了表示不同的 topic 外,并不支持分组,比如kafka中发布一个东西,多个订阅者可以分组,同一个组里只有一个订阅者会收到该消息,这样可以用作负载均衡。比如,kafka 中发布:topic = "发布帖子" data="文章1" 这个消息,后面有一百台服务器每台服务器都是一个订阅者,都订阅了这个 topic,但是他们可能分为三组,A组50台,用来真的做发布文章,A组50台里所有 subscriber 都订阅了这个topic。由于在同一组,这条消息 (topic="发布帖子", data="文章1")只会被A组里面一台当前空闲的机器收到。而B组25台服务器用于统计,C组25台服务器用于存档备份,每组只有一台会收到。用不同的组来决定每条消息要抄送出多少分去,用同组内哪些订阅者忙,哪些订阅者空闲来决定消息会被分到哪台服务器去处理,生产者消费者模型。 redis则没有这类机制。

性能上,对于RabbitMQ和Redis的入队和出队操作,各执行100万次,每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明:入队时,当数据比较小时Redis的性能要高于RabbitMQ,而如果数据大小超过了10K,Redis则慢的无法忍受;出队时,无论数据大小,Redis都表现出非常好的性能,而RabbitMQ的出队性能则远低于Redis。


参考资料:

http://www.flammulina.com/2018/02/25/java-kafkamqredis%E4%BD%9C%E4%B8%BA%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97%E6%97%B6%E7%9A%84%E5%B7%AE%E5%BC%82/

http://www.dataguru.cn/thread-748481-1-1.html

https://blog.csdn.net/shandianke/article/details/52080004

https://blog.csdn.net/jiangyeqt/article/details/52794965


你可能感兴趣的:(mq)