一种分布式消息队列研究和测试.docVIP

一种分布式消息队列研究和测试 　　摘 要：为了解决实时流式数据的采集问题，研究了一种分布式消息队列Kafka，它可以实时采集流式数据，处理数据时先从它订阅，就可以以流数据的形式处理数据。该队列具有部署简单、易于管理、吞吐量高、高容错性等优点。经测试，该队列可以满足实际生产中对吞吐量的需求。 　　关键词：分布式；消息队列；主题；流数据 　　中图分类号：TP274.2 文献标识码：A 文章编号：2095-1302（2016）08-00-03 　　0 引 言 　　当前大数据处理的数据形式主要分为两种。一种是固定的批量数据，这种数据是一个文件或者一个数据库，其数据量是固定的，我们只需一次读取，然后进行计算；另外一种是活跃的流式数据，这种数据是一个数据流，是实时生成、可传输的，如一个网站的流量page views、用户搜索的内容等，这些数据是实时的，且数据量很大，其采集比较困难，传统的消息队列很难应用到此种场景中。要想处理这些数据就需要先采集这些数据，本文介绍了一种可以实时采集这些数据的分布式消息队列Kafka。 　　1 简介 　　Kafka是LinkedIn于2010年12月份开源的消息系统，它主要用于处理活跃的流式数据。活跃的流式数据在Web网站的应用中十分常见，包括网站的pv、用户访问的内容、搜索的内容等。这些数据通常以日志的形式记录下来，然后每隔一段时间进行一次统计处理。 　　传统的日志分析系统提供了一种离线处理日志信息的可扩展方案，但若要进行实时处理，通常会有较大延迟。而现有的消息（队列）系统能够很好地处理实时或者近似实时的应用，但未处理的数据通常不会写到磁盘上，这对于Hadoop之类（一小时或者一天只处理一部分数据）的离线应用而言，可能会存在些许问题。Kafka正是为了解决以上问题而设计的，它能够很好地提供离线和在线应用。 　　Kafka对消息按topic进行归类保存，消息的发布者称为生产者（Producer），消息的接收者称为消费者（Consumer）。Kafka是分布式，它的集群由多个Kafka实例组成，每个实例是一个Broker。Kafka集群的信息及生产者与消费者的元数据都由Zookeeper保存，它本身无需保存这些数据。 　　2 设计原理 　　Kafka的设计初衷是希望作为一个统一的数据收集平台，能够实时收集数据、支撑大数据，并具备良好的容错能力。 　　2.1 存储 　　Kafka不会在消息被消费后直接删除，而是将消息持久化在磁盘中，使用文件存储消息，而文件系统的优化几乎是不可能的，为了提高性能，采用了缓存/直接内存映射的方法。为了减少对磁盘的访问次数，Broker将数据暂时缓存起来，当消息的数量达到一定值时，再flush到磁盘中，减少了在磁盘I/O上消耗的时间。 　　2.2 高吞吐量 　　为了提高Kafka的吞吐量，它采用了批量传输发送的方法，即生产者发布消息时，先将消息缓存，当达到一定量时，批量发送到Broker；对于消费者也一样，Broker会批量发送多条消息。考虑到网络I/O，Kafka将在网络上传输的数据进行压缩，它支持的压缩方式有gzip/snappy等。而在创建主题时，可以分为多个分区，进一步提高读写的吞吐量。 　　2.3 负载均衡 　　生产者根据用户指定的算法，将消息发送到指定的分区；存在多个分区，每个分区都有自己的副本，每个副本分布在不同的Broker节点上；多个分区需要选取出主分区，主分区负责读写，并由Zookeeper负责故障恢复；通过Zookeeper管理Broker与消费者的动态加入与离开。 　　2.4 自动扩容 　　由于在大数据行业中数据量的大小难以估计，Kafka支持集群的横向扩展，当需要增加Broker结点时，新增的Broker、生产者、消费者会向Zookeeper注册，并及时作出调整。 　　3 技术架构 　　Kafka是使用scala语言开发的，同时支持多种编程语言的客户端（c++、java、python、go等），其总体架构如图1所示。 　　Kafka的消息分为以下几个层次： 　　（1）主题（Topic）：一类消息，例如页面浏览日志，用户搜索日志等都可以以主题的形式存在，Kafka集群能够同时负责一个或多个主题的分发。 　　（2）分区（Partition）：是在主题物理上的分组，一个主题可以分为多个分区，每个分区是一个有序的队列。分区中的每条消息都会被分配一个有序的id（offset）。 　　（3） 消息（Message）：最小订阅单元。 　　具体流程如下所示： 　　（1）生产者根据指定的分区方法（round-robin、hash等），将消息发布到指定主题的分区中； 　　（2）Kafka集群接收到生产者发过来的消息后，将其