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

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

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

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

一、rabbitmq

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

它的优点有：

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

2、基于AMQP

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

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、以前没有使用过，需要一定的熟悉时间，和开发工作；

四、结论

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