常见的Message Queue对比
RabbitMQ
RabbitMQ是使用Erlang编写的一个开源消息队列，本身支持很多协议:AMQP、XMPP、SMPT、STOMP，也正因为如此,它非常重量级，更适合于企业级的开发。同时实现了Broker架构，这意味着消息在发送给客户端时现在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。
Redis
Redis是一个基于Key-Value键值对的NoSQL的数据库，开发维护很活跃。虽然他是一个key-value的数据库存储系统，但他本身支持MQ功能，所以完全可以当做一个轻量级的消息队列来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每十万次记录一次执行时间。测试数据为128Bytes、512Bytes。1k和10k四个不同大小的数据。实验表明：入队时当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10k，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能远低于Redis。
ZerMQ
ZerMQ号称最快的消息队列系统。尤其针对大吞吐量的需求场景。ZerMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对ZerMQ能够应用成功的挑战。ZerMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用ZerMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZerMQ仅提供非持久性的队列，也就是说，如果宕机，数据将会丢失。其中，Twwitter的Storm0.9.0以前的版本中默认使用ZerMQ作为数据流的传输。
ActiveMQ
ActiveMQ是Apache下的一个子项目。类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。
Kafka中专业术语的解释
broker
Kafka集群包含一个或者多个服务器，服务器节点称为broker。
Topic
每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
Partition
topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。
Producer
生产者即数据的发布者，该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。
Consumer
消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。
Consumer Group
每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。
Follower
Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”列表中删除，重新创建一个Follower。