RabbitMq、ActiveMq、Kafka和Redis做Mq对比

转载自：https://blog.csdn.net/qiqizhiyun/article/details/79848834

一、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）：将交换器和队列连接起来，并且封装消息的路由信息

图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间的消息分区，及分布式消费，同时保证消息顺序传输
• 支持离线数据处理和实时数据处理
• 支持在线水平扩展

图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