消息队列的选择：kafka、rabbitmq、zeromq \ActiveMQ\MQTT
本帖最后由 java 于 2017-3-21 10:25 编辑最近在做一个数据分析相关的工作，需求是将全国各地idc内的流量信息进行汇总和分析最后吐出一些安全策略，由于对时效性的要求比较高，大概每隔几秒就会有一次几十M的的数据需要传递到汇总服务器上去，而且随着业务的发展数据量还会越来越大，所以使用什么手段来做数据的传输就成为了一个关键的问题。首先是可扩展性，如果使用标准socket进行传递的话随着数据量的扩大单点肯定会成为瓶颈，而且如果可用性要高的话，异步、缓存、重传等等都是需要考虑的要素，为了开速上线功能就要去几个开源的消息队列里挑选一下合适这个项目的了。由于团队内的一些推荐和自己以前的经验，初步定下了kafka、rabbitmq、zeromq三个软件，这里主要介绍一下这三个软件各自的特点和功能，详细的使用说明和学习资料后面在补。一、rabbitmq
首先是百科里的一段话，Rabbitmq是流行的开源消息队列系统，使用erlang语言进行开发。RabbitMQ是AMQP(高级消息队列协议)的标准实现。可以说从功能上rabbitmq基本上是符号这次项目要求的工具。它的优点有：1、完整的消息队列系统，支持多种消息队列模式，包括竞争消费；2、基于AMQP3、支持集群模式，扩展集群容量和性能比较方便，同时集成了集群的监控和管理；4、支持消息的持久化；缺点是：1、需要学习比较复杂的接口和协议，比较耗费时间；2、性能不是特别理想大概在1wqps左右；3、使用Erlang语言，以前没听说过，出了问题不会排查；二、zeromq
以前经常在内网中使用，号称是最快的消息队列，由于它支持的模式非常多：tcp、ipc、inproc、multicas，基本已经达到了替代标准socket的地步了，听说linux内核已经准备将zeromq纳入标准内核中了。zeromq是一个智能传输层，它并不是对socket的封装，而是在其之上有一套自己的协议，可以使用非常丰富的开发模式像扇出(fanout)、发布订阅(pub-sub)、任务分发(task distribution)、请求响应(request-reply)等。优点：1、缺省为异步I/O交互，封装了连接的维护操作，消息处理并行化；2、性能非常不错；3、编程简单，上手很快；缺点：1、消息无法持久化，除非自己在实现一个中间件，否则消息传递完成就删除了；2、扩展性不是很好，其实是一个消息库，并不算是MQ；三、kafka
日志团队正在使用的工具，是一个消息发布订阅系统。生产者向某个队列发送一个数据，消费者订阅一个队列，一旦这个队列内产生新的数据了，中间人就会将数据发送给所有订阅队列的消费者。用术语来说生产者就是producer、消费者就是consumer、中间人就是broker，kafka主要就是这三者之间进行联系的。优点：1、高吞吐量率，每秒能处理几十万条消息；2、分布式架构，能够以集群进行处理；3、日志团队已经建立了kafka集群，可以蹭一蹭；缺点：1、以前没有使用过，需要一定的熟悉时间，和开发工作；
http://www.mrhaoting.com/?p=139
Kafka 是LinkedIn 开发的一个高性能、分布式的消息系统，广泛用于日志收集、流式数据处理、在线和离线消息分发等场景。虽然不是作为传统的MQ来设计，在大部分情况，Kafaka 也可以代替原先ActiveMQ 等传统的消息系统。
Kafka 将消息流按Topic 组织，保存消息的服务器称为Broker，消费者可以订阅一个或者多个Topic。为了均衡负载，一个Topic 的消息又可以划分到多个分区(Partition)，分区越多，Kafka并行能力和吞吐量越高。Kafka 集群需要zookeeper 支持来实现集群，最新的kafka 发行包中已经包含了zookeeper，部署的时候可以在一台服务器上同时启动一个zookeeper Server 和 一个Kafka Server，也可以使用已有的其他zookeeper集群。和传统的MQ不同，消费者需要自己保留一个offset，从kafka 获取消息时，只拉去当前offset 以后的消息。Kafka 的scala/java 版的client 已经实现了这部分的逻辑，将offset 保存到zookeeper 上。每个消费者可以选择一个id，同样id 的消费者对于同一条消息只会收到一次。一个Topic 的消费者如果都使用相同的id，就是传统的 Queue；如果每个消费者都使用不同的id, 就是传统的pub-sub.如果在MQ的场景下，将Kafka 和 ActiveMQ 相比:
Kafka 的优点分布式可高可扩展。Kafka 集群可以透明的扩展，增加新的服务器进集群。
高性能。Kafka 的性能大大超过传统的ActiveMQ、RabbitMQ等MQ 实现，尤其是Kafka 还支持batch 操作。下图是linkedin 的消费者性能压测结果:
http://www.dongliu.net/showfile/ed25c976031a6557071698b42030bc21
容错。Kafka每个Partition的数据都会复制到几台服务器上。当某个Broker故障失效时，ZooKeeper服务将通知生产者和消费者，生产者和消费者转而使用其它Broker。
Kafka 的不利重复消息。Kafka 只保证每个消息至少会送达一次，虽然几率很小，但一条消息有可能会被送达多次。
消息乱序。虽然一个Partition 内部的消息是保证有序的，但是如果一个Topic 有多个Partition，Partition 之间的消息送达不保证有序。
复杂性。Kafka需要zookeeper 集群的支持，Topic通常需要人工来创建，部署和维护较一般消息队列成本更高
http://www.open-open.com/lib/view/open1425522959525.html
两者虽然都是从传统的Pub/Sub消息系统演化出来的，但是进化的方向不一样，以下是几个比较突出的点：
[*]Kafka是为了数据集成的场景，与以往Pub/Sub消息总线不一样，通过分布式架构提供了海量消息处理、高容错的方式存储海量数据流、保证数据流的顺序等特性。可以参考云上的卡夫卡 - 数据工会。
[*]MQTT是为了物联网场景而优化，不但提供多个QoS选项（exact once、at least once、at most once），而且还有层级主题、遗嘱等等特性。可以参考MQTT入门篇 - 数据工会。
说白了都是传统消息系统（老爸）的子嗣，只是与不同的场景（老妈）结合的产物。不过，两者却可以结合起来使用。比如可以用MQTT接受物联网设备上传的数据，然后接入Kafka，最后可以同时分发到HDFS归档、数据仓库做OLAP分析、Elasticsearch做全文检索，这样的架构非常适合大型物联网项目，不但能够处理海量数据同时也具有很好的扩展性。
kafka是分布式消息队列或者叫分布式消息中间件，有时候会叫做一种MQ产品（Message Queue),同类型的有RabbitMQ，ActiveMQ等等。
MQTT是一种即时消息传输协议，Message Queuing Telemetry Transport，也就是一种即时信息传输的一种格式约定，与其类似的有XMPP等，是用来做IM的。
据我所知，kafka是不支持MQTT协议的，如果非要把它们集成在一起，你要不自己分析，要不去Github上找找，说不定有人做过这样的项目。
我的理解是，两个M的意思，是完全不一样的，kafka的M是指各个服务器或各个进程间传输的消息，而MQTT的M，是指类似MSN，QQ那种IM中那种大家交流的那种消息。
https://www.zhihu.com/question/30343125
页:
[1]