rabbitMQ、activeMQ、zeroMQ、Kafka、Redis 比较

 

 

Kafka做为时下最流行的开源消息系统，被普遍地应用在数据缓冲、异步通讯、聚集日志、系统解耦等方面。相比较于RocketMQ等其余常见消息系统，Kafka在保障了大部分功能特性的同时，还提供了超一流的读写性能。

针对Kafka性能方面进行简单分析，相关数据请参考：http://www.javashuo.com/article/p-haqipkqc-ks.html，下面介绍一下Kafka的架构和涉及到的名词：

1. Topic：用于划分Message的逻辑概念，一个Topic能够分布在多个Broker上。

2. Partition：是Kafka中横向扩展和一切并行化的基础，每一个Topic都至少被切分为1个Partition。

3. Offset：消息在Partition中的编号，编号顺序不跨Partition。

4. Consumer：用于从Broker中取出/消费Message。

5. Producer：用于往Broker中发送/生产Message。

6. Replication：Kafka支持以Partition为单位对Message进行冗余备份，每一个Partition均可以配置至少1个Replication(当仅1个Replication时即仅该Partition自己)。

7. Leader：每一个Replication集合中的Partition都会选出一个惟一的Leader，全部的读写请求都由Leader处理。其余Replicas从Leader处把数据更新同步到本地，过程相似你们熟悉的MySQL中的Binlog同步。

8. Broker：Kafka中使用Broker来接受Producer和Consumer的请求，并把Message持久化到本地磁盘。每一个Cluster当中会选举出一个Broker来担任Controller，负责处理Partition的Leader选举，协调Partition迁移等工做。

9. ISR(In-Sync Replica)：是Replicas的一个子集，表示目前Alive且与Leader可以“Catch-up”的Replicas集合。因为读写都是首先落到Leader上，因此通常来讲经过同步机制从Leader上拉取数据的Replica都会和Leader有一些延迟(包括了延迟时间和延迟条数两个维度)，任意一个超过阈值都会把该Replica踢出ISR。每一个Partition都有它本身独立的ISR。

更多关于Kafka的数据，参考：http://www.javashuo.com/article/p-haqipkqc-ks.html

****************************************************

****************************************************

Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标以下：
以时间复杂度为O(1)的方式提供消息持久化能力，即便对TB级以上数据也能保证常数时间复杂度的访问性能。
高吞吐率。即便在很是廉价的商用机器上也能作到单机支持每秒100K条以上消息的传输。
支持Kafka Server间的消息分区，及分布式消费，同时保证每一个Partition内的消息顺序传输。
同时支持离线数据处理和实时数据处理。
Scale out：支持在线水平扩展。

RabbitMQ
RabbitMQ是使用Erlang编写的一个开源的消息队列，自己支持不少的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它很是重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。

Redis
Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它自己支持MQ功能，因此彻底能够当作一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操做，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不一样大小的数据。实验代表：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而若是数据大小超过了10K，Redis则慢的没法忍受；出队时，不管数据大小，Redis都表现出很是好的性能，而RabbitMQ的出队性能则远低于Redis。

ZeroMQ
ZeroMQ号称最快的消息队列系统，尤为针对大吞吐量的需求场景。ZeroMQ可以实现RabbitMQ不擅长的高级/复杂的队列，可是开发人员须要本身组合多种技术框架，技术上的复杂度是对这MQ可以应用成功的挑战。ZeroMQ具备一个独特的非中间件的模式，你不须要安装和运行一个消息服务器或中间件，由于你的应用程序将扮演这个服务器角色。你只须要简单的引用ZeroMQ程序库，可使用NuGet安装，而后你就能够愉快的在应用程序之间发送消息了。可是ZeroMQ仅提供非持久性的队列，也就是说若是宕机，数据将会丢失。其中，Twitter的Storm 0.9.0之前的版本中默认使用ZeroMQ做为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty做为传输模块）。

ActiveMQ
ActiveMQ是Apache下的一个子项目。 相似于ZeroMQ，它可以以代理人和点对点的技术实现队列。同时相似于RabbitMQ，它少许代码就能够高效地实现高级应用场景。

Kafka/Jafka
Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具备如下特性：快速持久化，能够在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既能够达到10W/s的吞吐速率；彻底的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；支持Hadoop数据并行加载，对于像Hadoop的同样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka经过Hadoop的并行加载机制统一了在线和离线的消息处理。Apache Kafka相对于ActiveMQ是一个很是轻量级的消息系统，除了性能很是好以外，仍是一个工做良好的分布式系统。

以上转自：http://www.infoq.com/cn/articles/kafka-analysis-part-1/

****************************************************

****************************************************

 

什么是Kafka？

引用官方原文：  “ Kafka is a distributed, partitioned, replicated commit log service. ”

它提供了一个很是特殊的消息机制，不一样于传统的mq。

官网：https://kafka.apache.org

---

它与传统的mq区别？

• 更快！单机上万TPS
• 传统的MQ，消息被消化掉后会被mq删除，而kafka中消息被消化后不会被删除，而是到配置的expire时间后，才删除
• 传统的MQ，消息的Offset是由MQ维护，而kafka中消息的Offset是由客户端本身维护
• 分布式，把写入压力均摊到各个节点。能够经过增长节点下降压力

---

基本术语

为方便理解，我用对比传统MQ的方式阐述这些基本术语。

Producer 

Consumer

这两个与传统的MQ同样，不解释了

Topic

Kafka中的topic其实对应传统MQ的channel，即消息管道，例如同一业务用同一根管道

Broker

集群中的KafkaServer，用来提供Partition服务

Partition 

假如说传统的MQ，传输消息的通道(channel)是一条双车道公路，那么Kafka中，Topic就是一个N车道的高速公路。每一个车道均可以行车，而每一个车道就是Partition。

• 一个Topic中能够有一个或多个partition。
• 一个Broker上能够跑一个或多个Partition。集群中尽可能保证partition的均匀分布，例如定义了一个有3个partition的topic，而只有两个broker，那么一个broker上跑两个partition，而另外一个是1个。可是若是有3个broker，必然是3个broker上各跑一个partition。
• Partition中严格按照消息进入的顺序排序
• 一个从Producer发送来的消息，只会进入Topic的某一个Partition（除非特殊实现Producer要求消息进入全部Partition）
• Consumer能够本身决定从哪一个Partition读取数据

Offset

单个Partition中的消息的顺序ID，例如第一个进入的Offset为0，第二个为1，以此类推。传统的MQ，Offset是由MQ本身维护，而kafka是由client维护

Replica

Kafka从0.8版本开始，支持消息的HA，经过消息复制的方式。在建立时，咱们能够指定一个topic有几个partition，以及每一个partition有几个复制。复制的过程有同步和异步两种，根据性能须要选取。 正常状况下，写和读都是访问leader，只有当leader挂掉或者手动要求从新选举，kafka会从几个复制中选举新的leader。

Kafka会统计replica与leader的同步状况。当一个replica与leader数据相差不大，会被认为是一个"in-sync" replica。只有"in-sync" replica才有资格参与从新选举。

ConsumerGroup

一个或多个Consumer构成一个ConsumerGroup，一个消息应该只能被同一个ConsumerGroup中的一个Consumer消化掉，可是能够同时发送到不一样ConsumerGroup。

一般的作法，一个Consumer去对应一个Partition。

传统MQ中有queuing（消息）和publish-subscribe（订阅）模式，Kafka中也支持：

• 当全部Consumer具备相同的ConsumerGroup时，该ConsumerGroup中只有一个Consumer能收到消息，就是 queuing 模式
• 当全部Consumer具备不一样的ConsumerGroup时，每一个ConsumerGroup会收到相同的消息，就是 publish-subscribe 模式

---

基本交互原理

每一个Topic被建立后，在zookeeper上存放有其metadata，包含其分区信息、replica信息、LogAndOffset等 
默认路径/brokers/topics/<topic_id>/partitions/<partition_index>/state

Producer能够经过zookeeper得到topic的broker信息，从而得知须要往哪写数据。

Consumer也从zookeeper上得到该信息，从而得知要监听哪一个partition。

 

---

基本CLI操做

1. 建立Topic

./kafka-create-topic.sh --zookeeper 10.1.110.21:2181 --replica 2 --partition 3 --topic test 

2. 查看Topic信息

./kafka-list-topic.sh --topic test --zookeeper 10.1.110.24:2181 

3. 增长Partition

./kafka-add-partitions.sh --partition 4 --topic test --zookeeper 10.1.110.24:2181

更多命令参见：https://cwiki.apache.org/confluence/display/KAFKA/Replication+tools

---

建立一个Producer

Kafka提供了java api，Producer特别的简单，举传输byte[] 为例

Properties p = new Properties(); props.put("metadata.broker.list", "10.1.110.21:9092"); ProducerConfig config = new ProducerConfig(props); Producer producer = new Producer<String, byte[]>(config); producer.send(byte[] msg);

更具体的参见: https://cwiki.apache.org/confluence/display/KAFKA/0.8.0+Producer+Example

---

建立一个Consumer

Kafka提供了两种java的Consumer API：High Level Consumer和Simple Consumer

看上去前者彷佛要更牛B一点，事实上，前者作了更多的封装，比后者要Simple的多……

具体例子我就不写了，参见

High Level Consumer: https://cwiki.apache.org/confluence/display/KAFKA/Consumer+Group+Example 

Simple Consumer: https://cwiki.apache.org/confluence/display/KAFKA/0.8.0+SimpleConsumer+Example

 摘自：http://www.tuicool.com/articles/ruUzum

 

****************************************************

****************************************************

如何保证kafka的高容错性？

1. producer不使用批量接口，并采用同步模型持久化消息。
2. consumer不采用批量化，每消费一次就更新offset

	ActiveMq	RabbitMq	Kafka
producer容错，是否会丢数据		有ack模型，也有事务模型，保证至少不会丢数据。ack模型可能会有重复消息，事务模型则保证彻底一致	批量形式下，可能会丢数据。 非批量形式下， 1. 使用同步模式，可能会有重复数据。 2. 异步模式，则可能会丢数据。
consumer容错，是否会丢数据		有ack模型，数据不会丢，但可能会重复处理数据。	批量形式下，可能会丢数据。非批量形式下，可能会重复处理数据。（ZK写offset是异步的）
架构模型	基于JMS协议	基于AMQP模型，比较成熟，但更新超慢。RabbitMQ的broker由Exchange,Binding,queue组成，其中exchange和binding组成了消息的路由键；客户端Producer经过链接channel和server进行通讯，Consumer从queue获取消息进行消费（长链接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）。rabbitMQ以broker为中心；有消息的确认机制	producer，broker，consumer，以consumer为中心，消息的消费信息保存的客户端consumer上，consumer根据消费的点，从broker上批量pull数据；无消息确认机制。
吞吐量		rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不同，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操做；基于存储的可靠性的要求存储能够采用内存或者硬盘。	kafka具备高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操做，具备O(1)的复杂度，消息处理的效率很高
可用性		rabbitMQ支持miror的queue，主queue失效，miror queue接管	kafka的broker支持主备模式
集群负载均衡		rabbitMQ的负载均衡须要单独的loadbalancer进行支持	kafka采用zookeeper对集群中的broker、consumer进行管理，能够注册topic到zookeeper上；经过zookeeper的协调机制，producer保存对应topic的broker信息，能够随机或者轮询发送到broker上；而且producer能够基于语义指定分片，消息发送到broker的某分片上

参考：http://www.liaoqiqi.com/post/227

 

****************************************************

****************************************************

 

注：下文转载自：http://blog.csdn.net/linsongbin1/article/details/47781187

MQ框架很是之多，比较流行的有RabbitMq、ActiveMq、ZeroMq、kafka。这几种MQ到底应该选择哪一个？要根据本身项目的业务场景和需求。下面我列出这些MQ之间的对比数据和资料。 

第一部分：RabbitMQ,ActiveMq,ZeroMq比较

一、 TPS比较 一

ZeroMq 最好，RabbitMq 次之， ActiveMq 最差。这个结论来自于如下这篇文章。

http://blog.x-aeon.com/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/

测试环境：

     Model: Dell Studio 1749

     CPU: Intel Core i3 @ 2.40 GHz

     RAM: 4 Gb

     OS: Windows 7 64 bits

其中包括持久化消息和瞬时消息的测试。注意这篇文章里面提到的MQ，都是采用默认配置的，并没有调优。

更多的统计图请参看我提供的文章url。

 

 

二、TPS比较二

ZeroMq 最好，RabbitMq次之， ActiveMq最差。这个结论来自于一下这篇文章。http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html 

 

显示的是发送和接受的每秒钟的消息数。整个过程共产生1百万条1K的消息。测试的执行是在一个Windows Vista上进行的。

 

3、持久化消息比较

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

 

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

 

      RabbitMq最好，ActiveMq次之，ZeroMq最差。固然ZeroMq也能够作到，不过本身必须手动写代码实现，代码量不小。尤为是可靠性中的：持久性、投递确认、发布者证明和高可用性。

      因此在可靠性和可用性上，RabbitMQ是首选，虽然ActiveMQ也具有，可是它性能不及RabbitMQ。

 

 五、高并发

从实现语言来看，RabbitMQ最高，缘由是它的实现语言是天生具有高并发高可用的erlang语言。

 

 

总结：

按照目前网络上的资料，RabbitMQ、activeM、zeroMQ三者中，综合来看，RabbitMQ是首选。下面提供一篇文章，是淘宝使用RabbitMQ的心得，能够参看一些业务场景。

http://www.docin.com/p-462677246.html

 

 

第二部分：kafka和RabbitMQ的比较

 

关于这两种MQ的比较，网上的资料并很少，最权威的的是kafka的提交者写一篇文章。http://www.quora.com/What-are-the-differences-between-Apache-Kafka-and-RabbitMQ

里面提到的要点：

一、  RabbitMq比kafka成熟，在可用性上，稳定性上，可靠性上，RabbitMq超过kafka

二、  Kafka设计的初衷就是处理日志的，能够看作是一个日志系统，针对性很强，因此它并无具有一个成熟MQ应该具有的特性

三、  Kafka的性能（吞吐量、tps）比RabbitMq要强，这篇文章的做者认为，二者在这方面没有可比性。

这里在附上两篇文章，也是关于kafka和RabbitMq之间的比较的：

一、http://www.mrhaoting.com/?p=139

二、http://www.liaoqiqi.com/post/227

 

总结：

二者对比后，我仍然是选择RabbitMq，性能实际上是很强劲的，同时具有了一个成熟的MQ应该具备的特性，咱们无需从新发明轮子