消息队列的选择：kafka、rabbitmq、zeromq

最近在作一个数据分析相关的工做，需求是将全国各地idc内的流量信息进行汇总和分析最后吐出一些安全策略，因为对时效性的要求比较高，大概每隔几秒就会有一次几十M的的数据须要传递到汇总服务器上去，并且随着业务的发展数据量还会愈来愈大，因此使用什么手段来作数据的传输就成为了一个关键的问题。

首先是可扩展性，若是使用标准socket进行传递的话随着数据量的扩大单点确定会成为瓶颈，并且若是可用性要高的话，异步、缓存、重传等等都是须要考虑的要素，为了开速上线功能就要去几个开源的消息队列里挑选一下合适这个项目的了。

因为团队内的一些推荐和本身之前的经验，初步定下了kafka、rabbitmq、zeromq三个软件，这里主要介绍一下这三个软件各自的特色和功能，详细的使用说明和学习资料后面在补。

1、rabbitmq

首先是百科里的一段话，Rabbitmq是流行的开源消息队列系统，使用erlang语言进行开发。RabbitMQ是AMQP(高级消息队列协议)的标准实现。能够说从功能上rabbitmq基本上是符号此次项目要求的工具。

它的优势有：

一、完整的消息队列系统，支持多种消息队列模式，包括竞争消费；

二、基于AMQP

三、支持集群模式，扩展集群容量和性能比较方便，同时集成了集群的监控和管理；

四、支持消息的持久化；

缺点是：

一、须要学习比较复杂的接口和协议，比较耗费时间；

二、性能不是特别理想大概在1wqps左右；

三、使用Erlang语言，之前没据说过，出了问题不会排查；

2、zeromq

之前常常在内网中使用，号称是最快的消息队列，因为它支持的模式很是多：tcp、ipc、inproc、multicas，基本已经达到了替代标准socket的地步了，据说linux内核已经准备将zeromq归入标准内核中了。

zeromq是一个智能传输层，它并非对socket的封装，而是在其之上有一套本身的协议，可使用很是丰富的开发模式像扇出(fanout)、发布订阅(pub-sub)、任务分发(task distribution)、请求响应(request-reply)等。

优势：

一、缺省为异步I/O交互，封装了链接的维护操做，消息处理并行化；

二、性能很是不错；

三、编程简单，上手很快；

缺点：

一、消息没法持久化，除非本身在实现一个中间件，不然消息传递完成就删除了；

二、扩展性不是很好，实际上是一个消息库，并不算是MQ；

3、kafka

日志团队正在使用的工具，是一个消息发布订阅系统。生产者向某个队列发送一个数据，消费者订阅一个队列，一旦这个队列内产生新的数据了，中间人就会将数据发送给全部订阅队列的消费者。

用术语来讲生产者就是producer、消费者就是consumer、中间人就是broker，kafka主要就是这三者之间进行联系的。

优势：

一、高吞吐量率，每秒能处理几十万条消息；

二、分布式架构，可以以集群进行处理；

三、日志团队已经创建了kafka集群，能够蹭一蹭；

缺点：

一、之前没有使用过，须要必定的熟悉时间，和开发工做；

4、结论

日志团队的强烈推荐，和强大的技术支持，最后决定使用kafka了，它提供的特色和优点确实也令人心动，不过此次的调研也让我了解了一些开源软件的设计思路和软件选择的见解，后面在写几篇记录一下。