kafka中文文档（0.10.0）

kafka中文文档（0.10.0）

---

作者：链上研发-老杨叔叔
时间：2016-07-22
版本：Apache Kafka 0.10.0 （2016年5月底发布）

.目录

英文版

api doc

0.相关资料

代理服务器集群搭建

环境搭建另一

各种MQ比较

1.入门

• 1.1 介绍

  Kafka是分布式、分区、可复制的提交日志服务。它采用独特的设计来实现消息服务系统。

  这意味着什么呢？

  首先，让我们回顾一些基本的消息传递术语：

  • 主题：维护的一组消息分类；
  • 生产者：向kafka的主题中发布消息
  • 消费者：订阅并消费主题中的消息
  • 代理：kafka集群由一个或多个服务端组成。每个服务端称为代理

  因此，生产者通过网络发送消息给kafka集群，同时，kafka集群把消息转发给消费者，如下：

  

  客户和服务器之间的通信是通过一个简单的、高性能的、语言无关的TCP协议。我们不仅提供java 客户端，同时提供其它多种语言版本的客户端

  主题和日志

  一个主题就是一个用来发布消息的目录或订阅的名字，对于每个topic，Kafka维护一个分区日志，看起来如下
  

  每个分区是一个有序的，可以不断追加消息的消息序列。分区中的每个消息都会分配一个在分区内是唯一的序列号，这个序列号叫做偏移量(offset)。

  kafka集群保留所有已经发布的消息（无论这些消息是否已经被消费）一段时间。我们可以配置这个时间来决定集群维护消息的时间长短。比如：如果消息被设置保存两天，那么两天内，消息都是可以被消费的。但是两天后为了节省磁盘空间就会删除消息。

  kafka性能对数据大小不敏感，因此保留大量数据毫无压力。

  事实上，每个消费者仅仅需要保存的元数据是消费者在日志中的消费位置（偏移量），这个偏移量是由消费者控制：通常，消费者读取消息后会线性递增偏移量，但是，消费者可以按任意顺序消费消息。比如：消费者可以重置偏移量到老版本。

  以上特性的组合使得consumer的代价很小。consumer数量可以增加或减少而对整个集群影响很小。例如：略。

  日志分区的目的：第一：允许日志规模超出一台服务器的文件大小限止。每个单独的分区都必须受限于主机的文件限止，但一个主题可有多个分区，因此可以处理无限数量的数据。

  分布式

  日志的所有有分区被分发到集群中的服务器上，每个服务器处理全部分区中的部分分区数据和请求。为了容错，每个分区都被复制到一定数量（可配置）的不同服务器上。

  每个分区（有多个副本）都有一台服务器作为“leader”，大于等于0台服务器做为”followers”。”leader”服务器处理分区的所有读写操作。”followers”服务器对当前分区做为旁观者，什么都不做。当”leader”服务器不可用时，那么”followers”中的一台将自动成为”leader”。每台服务器都即做为一些分区的”leader”，又做为其它分区的“followers”。

  生产者

  生产者向所选的主题发布数据。生产者负责选择哪些消息应该分配到主题内的哪个分区。这种选择分区方式，可以使用简单的循环方式负载均衡； 也可以通过一些语义分区函数实现（如：基于消息的key的hash等）

  消费者

  传统的消息处理有两种模型：队列和发布订阅。队列模式，消费者池中的消费者可以从一台服务器读数据，并且每个消息只被其中一个消费者消费。发布订阅模式，消息通过广播方式发送给所有消费者。kafka提供了一个单一的抽象概念，可以满足这两种（队列、发布订阅）模式－－消费者组。

  消费者通过分组名标识自己，每条消息被发布到主题，并只会分发给消费者组中的 唯一个 消费者实例（即只被组中的一个消费者消费）。这些消费者即可以是同一台服务器上不同的进程，也可以是位于不同服务器上进程。

  如果所有的消费者实例属于同一分组（相同的分组名），那么这就是传统的队列模式（相同topic，只有一个消费者能抢到消息）。

  如果所有的消费者实例不属于同一分组，那么这就是发布订阅模式（每个消费者都能收到消息）

  通常，主题有少量称为逻辑订阅者的分组。为了可扩展性和容错每个分组是由许多消费者实例组成。

  kafka 也比传统消息系统拥有更强的顺序性。

  传统队列维护消息顺序性。如果多个消费者从队列中消费消息，那么服务器以存储的顺序分发消息。虽然消息从服务器出队列是按顺序的，但是被分发给消费者时，是通过异步的方式，因此消息到达不同消费者时可能是乱序的。这意味者并发消费时，消费是乱序的。消息系统为了做到这点，会采用只有一个消费者消费的理念，但这也意味是无法并行操作。

  kafka这点做的更好，通过称为分区（主题内）的并行概念，kafka即可以提供顺序又可以负载均衡。这是通过给主题内的相同分组下的消费者提供多个分区的架构，来实现每个分区只能被一个消费者消费。通过这种方式，可以确保同一分区只有一个消费者，因此一个分区消费消息是顺序的； 同时，由于有多个分区，因此可以负载均衡。注意：一个分组内，消费者数量不能多于分区数量。此处的：不能多于，应该不绝对。即：一个应用集群（有消费者）可能远远多于分区数量，只能说超出的消费者永远都无分区消费，但并不影响其它消费者正常使用（我瞎猜的，需要确认-todo)

  kafka仅仅支持分区内的消息顺序消费，并不支持全局（同一主题的不同分区之间）的消息顺序。这处方式下，通过按消息key隔离数据的方式足够满足大部分应用； 但是，如果你需要一个全局顺序消费消息，你可以通过一个主题只有一个分区的方法实现，但是这也意味着一个分组只有一消费者；

  保证（此处翻译偏差较大，待重新翻译）

  • 同一个生产者发送的不同消息在分区中的存储是顺序的。
  • 同一个消费者看的消息顺序与这些消息的存储顺序是一致的。
  • 对一个拥有Ｎ个复制因子（Ｎ个分区），最多允许N-1台server故障还能保证消息不丢失。
    （是最多，并不代表一定。因为每个分区可以位于不同机器，也可以同时位于一台机器）

• 1.2 使用案例

  消息处理

  kafka是一个很好的传统消息代理替代产品。消息代理有几种原因：解耦生产者与消息处理、缓存消息等。与大多数消息系统相比，kafka有更好的吞吐量，内置分区，复制和容错性，这使它成为大规模消息处理应用很好的解决方案。

  ＸＸＸＸ

  网站活动跟踪

  kafka的原始用例（为此而生）是能重建一套可以实时发布，实时订阅消息，用于处理用户活动轨迹跟踪的管道。也就是说网站的活动（页面浏览、搜索、用户其它行为）可以按活动类型分别发布到各自的主题；这些订阅可以被用于后续各种用途：包括实时处理、实时监控、加载到hadoop、离线数据仓库。

  因为每个用户浏览页面都会产生活动消息，因此，活动跟踪数据量非常大。

  度量

  kafka经常被用于处理监控数据。这涉及到从分布式应用收集统计数据，并且做为后续分析的一个统一的数据源。（即分布式统计数据查询入口或代理）

  日志收集

  很多人把kafka做为日志收集解决方案。日志收集是从服务器上采集日志文件并把它们放入一个集中位置（如：文件服务器或hdfs）统一处理。kafka抽象了文件细节，并给出一个日志或事件消息流。这允许更低的延时处理，更容易支持多数据源以及分布式消息处理。与Scribe和Flume相比，kafka提供同样的良好性能，并提供更好的可用性（因为多个副本），和更低的延时。

  流处理

  很多kafka用户，通过把数据处理分成多个步骤，每个步骤处理数据的不同功能并放入此步骤的topic中，并通过kafka topics串联起所有步骤，形成一个数据处理通道。
  如：一个处理新闻的流程：首先通过RSS收集新闻，并发布到”articles”主题中；第二步，从“articles”主题中取新闻并清洗重复内容，然后发布一个新的主题中；最后，从上步的主题中取数据并推荐给用户。
  这样的处理管道是基于单个主题的实时数据流程图。从0.10.0.0版本开始，一个轻量但强大的，被称为kafka stream的功能用于处理这样的数据。除了Kafka stream还有另外相似的开源工具：Apache Storm / Apache Samza。

  Event Sourcing

  提交日志

  kafka可以做为分布式系统的外部提交日志服务器。可以帮助分布式节点存储数据失败时，做为重新同步机制，在节点与操作之间复制日志，以恢复数据。

  这种情况，kafka与Apache BookKeeper 非常相似。

• 1.3 快速开始

  本教程，假设你没有任何kafka知识。并且没有现成的kafka和zookeeper数据。

  步骤1: 下载代码

  下载0.10.0.0版本代码，并且解压

    tar -xzf kafka_2.11-0.10.0.0.tgz
    cd kafka_2.11-0.10.0.0
  

  步骤2: 启动服务

  kafka依赖zookeeper，因此首先要启动zookeeper；如果没有安装独立的zookeeper，可以使用kafka内嵌的zookepper。虽然这种方式快速但不是很好。

  启动zookeeper

    > bin/zookeeper-server-start.sh config/zookeeper.properties

  启动 kafka

     bin/kafka-server-start.sh config/server.properties

  步骤3: 创建一个主题

  手动创建一个名为“test”的主题

    bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
  

  查看刚创建的主题

    > bin/kafka-topics.sh --list --zookeeper localhost:2181

  可以通过配置“自动创建主题”，这样如果没有提前创建主题，那么在发布消息时，如果此消息对应的主题不存在，会自动创建。

  步骤4: 发送消息

  通过命令行客户端，可以通过文件或标准输入（命令行）向kafka集群发送消息。默认每行都是一条消息。

  启动生产者（启动成功进入命令行阻塞状态，可以输入数据，回车发送）

    bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test

  步骤5: 启动消费者

  启动消费者命令行(启动后命令行处于阻塞状态，生产者发布的消息会在此显示)

  “`

  bin/kafka-console-consumer.sh –zookeeper localhost:2181 –topic test –from-beginning

  “`

  步骤6: 设置服务器集群

  单个服务器挺没劲的，现在扩展到3台服务器（伪3台，在同一台机器上模拟）。
  现在配置服务器，让三台服务彼此联系

    > cp config/server.properties config/server-1.properties
    > cp config/server.properties config/server-2.properties
  

  修改上面配置文件，两个都修改

  config/server-1.properties:
      broker.id=1
      listeners=PLAINTEXT://:9093
      log.dir=/tmp/kafka-logs-1
  
  config/server-2.properties:
      broker.id=2
      listeners=PLAINTEXT://:9094
      log.dir=/tmp/kafka-logs-2

  broker.id是唯一的，为的是让服务器知道自己是谁，以及自己的配置是哪个。在不同机器上，会配置zookeeper的所有机器。通过这个id,可以知道自己的配置。
  配置了日志和端口，由于是在同一台机器模拟，所以日志路径和端口不能重了。

  启动新增的两台kafka（zookeeper已经启动，同一台只需要启动一个即可）

  > bin/kafka-server-start.sh config/server-1.properties &
  
  > bin/kafka-server-start.sh config/server-2.properties &

  创建一个新的的主题：

  > bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 1 --topic my-replicated-topic
  

  现在我们已经创建一个集群，但是我们怎么知道每个broker都做了什么？执行如下命令：”describe toics”：

  > bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic
    Topic:my-replicated-topic PartitionCount:1    ReplicationFactor:3 Configs:
     Topic: my-replicated-topic   Partition: 0    Leader: 1   Replicas: 1,2,0 Isr: 1,2,0
  

  第一行是所有分区的简介，其它行是每个具体分区的说明。因为我们只有一个分区，因此总共只有两行。

  • ”leader”: 是负责处理一个指定分区的所有读写操作。每个leader都是随机选择的。
  • “replicas”：副本是一个用来复制分区日志的节点列表。无论这些分区对应的服务器是leader还是处于激活状态，都会被复制。
  • “isr”

  注意：在我们的例子中，节点1是我们主题中唯一分区的leader；

  我们可以运行相同的命令，来查看我们最早创建的主题”test”的信息：

  > bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test
    Topic:test    PartitionCount:1    ReplicationFactor:1 Configs:
      Topic: test Partition: 0    Leader: 0   Replicas: 0 Isr: 0
  

  遗憾的是：这个主题没有副本；

  让我们向新主题发布一些消息：

  > bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-replicated-topic
  ...
  my test message 1
  my test message 2

  现在让我们消费这些消息：

  > bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic
  ...
  my test message 1
  my test message 2

  现在让我们来测试容错。broker 1 正在充当leader，我们先干掉它：

    > ps | grep server-1.properties
    7564 ttys002    0:15.91 /System/Library/Frameworks/JavaVM.framework/Versions/1.8/Home/bin/java...
    > kill -9 7564

  领袖已经由奴隶节点中的一个充当。节点1已经不再是xxxx

    > bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic
    Topic:my-replicated-topic PartitionCount:1    ReplicationFactor:3 Configs:
      Topic: my-replicated-topic  Partition: 0    Leader: 2   Replicas: 1,2,0 Isr: 2,0
  

  现在，即使原先那个写操作的leader已经仙逝，但消息仍然能被正常消费。

  > bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic
  ...
  my test message 1
  my test message 2

  步骤7: 使用kafka connect 导入/导出数据

  通过命令行读写数据是一个方便简单的开始。但是你可能希望通过其它数据源或者从kafka导出数据到其它系统。对大多数系统，你不需要写定制化的代码，只需要使用kafka connect 就可以导入或导出数据。kafka connect是一个可以运行多个connectors的扩展工具集。这些connectors实现了与外部系统交互的逻辑。在这个示例中，我们将体验怎么运行kafka connect ,并通过简单的connectors从文件把数据导入到主题，并从主题中把数据导出到文件。首先，我们创建一些种子数据，如下：
  ““

  echo -e “foo\nbar” > test.txt

  
  接着，我们以独立模式启动两个connectors。所谓独立模式，即这两个connectors运行在一个单一的、本地的、专有的进程中。我们提供三个配置文件做为后续命令的参数。第一个是用于普通的连接进程，包括broker，以及数据序列化格式。剩于的两个配置文件，每个都指定了一个需要创建的connector。这些文件包含一个唯一的connector名字，

  bin/connect-standalone.sh config/connect-standalone.properties config/connect-file-source.properties config/connect-file-sink.properties

  “`

kafka使用这些简单的配置文件启动，并创建两个connectors：第一个connector是一个从文件中按行读取数据，并把数据发布到主题的数据源connecotr。第二个是一个从主题消费消息，并把消息存到文件里的接收Connector。在启动过程中，你会看到许多日志信息，包括connetors实例化的一些指标信息。一旦kafka connect 进程启动，数据源connector就会开始从text.txt文件中读取数据。并且把数据发到connect-test主题。然后接收者connector开始从connect-test主题中读取数据，并且把数据写到test.sink.txt文件中。
我们可以检查test.sink.txt文件，来验证数据是否已经被传递到事个管道中。
“`

cat test.sink.txt
foo
bar

注意：数据正在被存储到connect-test主题中，因此我们可以运行一个命令行消费者来查看主题中的数据。

bin/kafka-console-consumer.sh –zookeeper localhost:2181 –topic connect-test –from-beginning
{“schema”:{“type”:”string”,”optional”:false},”payload”:”foo”}
{“schema”:{“type”:”string”,”optional”:false},”payload”:”bar”}
…

我们可以向源文件中添加数据来检查数据在管道中的流动：

echo “Another line” >> test.txt
“`
你是不是惊奇的发现，”Another line”这条数据已经保存到test.sink.txt文件中了。我的天哪，这太神奇了。

### 步骤8: 使用 kafka Streams处理数据
kafka stream是一个处理实时的流式操作和数据分析的客户端库。 下面的快速入门示例将演示如何使用这个库去运行一个流式应用代码。下面是WordCountDemo示例的关键代码(使用的是java8 lamda表达式)。

```
KTable wordCounts = textLines
// Split each text line, by whitespace, into words.
.flatMapValues(value -> Arrays.asList(value.toLowerCase().split("\\W+")))

// Ensure the words are available as record keys for the next aggregate operation.
.map((key, value) -> new KeyValue<>(value, value))

// Count the occurrences of each word (record key) and store the results into a table named "Counts".
.countByKey("Counts")

```

它实现了 WordCount（单词计数）算法，用于计算一个单词在文本中出现的次数。但是跟其它你以前见过的WordCount算法有些许不同。因为它是被设计用来处理无限的流式数据。它是一个跟踪和更新单词计数的动态算法。由于必须假定输入数据是无限的，并且无法确定什么时候处理完“所有”数据，因此它会定期输入出当前状态和处理结果。

现在，我们准备向kafka 主题中输入一些数据，用于kafka Streams应用程序后续数据。

```
> echo -e "all streams lead to kafka\nhello kafka streams\njoin kafka summit" > file-input.txt
```

接着，我们把输入的数据通过命令行生产者发送到```streams-file-input```主题中（在实践中，流式数据会源源不断的发布到kafka中）。
```
  > bin/kafka-topics.sh --create \
              --zookeeper localhost:2181 \
              --replication-factor 1 \
              --partitions 1 \
              --topic streams-file-input
  > cat file-input.txt | bin/kafka-console-producer.sh --broker-list localhost:9092 --topic streams-file-input

```

现在，我们可以启动WordCount示例应用来处理输入的数据。

```
  > bin/kafka-run-class.sh org.apache.kafka.streams.examples.wordcount.WordCountDemo

```
因为结果被写回到另一个主题，因此，除了日志条件，没有任何内容输出到“标准输出”。不像典型的流处理程序，示例代码运行几秒后会自动停止。

我们现在可以通过读取输出主题的消息，来检查WordCount示例输出的数据：
```
> bin/kafka-console-consumer.sh --zookeeper localhost:2181 \
        --topic streams-wordcount-output \
        --from-beginning \
        --formatter kafka.tools.DefaultMessageFormatter \
        --property print.key=true \
        --property print.value=true \
        --property key.deserializer=org.apache.kafka.common.serialization.StringDeserializer \
        --property value.deserializer=org.apache.kafka.common.serialization.LongDeserializer

```
程序运行后，会在命令行输出以下数据：
```
    all     1
    streams 1
    lead    1
    to      1
    kafka   1
    hello   1
    kafka   2
    streams 2
    join    1
    kafka   3
    summit  1
```
第一列是消息的key，第二列是消息的值。两列都使用了java.lang.String格式。注意，那个“输出”是一个持续的更新流。其中每条记录（原输出中的每一行）是一个单词的更新统计。对具有相同key的多条记录，以后的每条统计记录都是前一次的更新。

现在，你可以向streams-file-input主题中写入更多的数据，你会发现，添加的数据会追加到“streams-wordcount-output”主题，并且体现到单词计数记录中（上述操作，可以通过命令行生产者和消费者来观察）

• 1.4 生态

  除了上面描述的工具外，还有很多其它工具，如： stream processing system，Hadoop集成，monitoring，开发工具等。具体请看生态页;

• 1.5 版本升级

  略

2. API

apache kafka包含一个新的java客户端（位于org.apache.kafka.clients包中）。新的java客户端是为了替换旧的Scala客户端。但是一段时间内两个客户端会共存。同时这些客户端可以以单独的jar存在，而旧的Scala客户端仍然打包在server中。

• 2.1 生产者api

  我们鼓励开发者使用新的java版客户端生产者api。这个客户端是经过生产环境测试，并且包含比Scala 客户端更快更全面的功能。你可以通过maven配置来加载客户端。

    <dependency>
      <groupId>org.apache.kafka</groupId>
      <artifactId>kafka-clients</artifactId>
      <version>0.10.0.0</version>
    </dependency>

  这里的api 文档中包含了一些示例。javadocs

  scala开发者看这里：scala example

• 2.2 消费者api

  在0.90版本，我们已经提供了新的java 版本消息都客户端。目的是替换旧版基于zookeeper的上层（xxx???)consumer，以及低层的consumer apis。当前版本是测试版。为了让用户平滑升级，我们仍然维护0.8.0版本的客户端。下面我们即讲解0.8.0版，也讲解最新版。

  • ### 2.2.1 Old High Level Consumer API

  class Consumer {
      /**
       *  Create a ConsumerConnector
       *
       *  @param config  at the minimum, need to specify the groupid of the consumer and the zookeeper
       *                 connection string zookeeper.connect.
       */
      public static kafka.javaapi.consumer.ConsumerConnector createJavaConsumerConnector(ConsumerConfig config);
      }
  
    /**
      *  V: type of the message
      *  K: type of the optional key associated with the message
      */
      public interface kafka.javaapi.consumer.ConsumerConnector {
       
      /**
       *  Create a list of message streams of type T for each topic.
       *
       *  @param topicCountMap  a map of (topic, #streams) pair
       *  @param decoder a decoder that converts from Message to T
       *  @return a map of (topic, list of  KafkaStream) pairs.
       *          The number of items in the list is #streams. Each stream supports
       *          an iterator over message/metadata pairs.
       */
      public <K,V> Map<String, List<KafkaStream<K,V>>>
        createMessageStreams(Map<String, Integer> topicCountMap, Decoder<K> keyDecoder, Decoder<V> valueDecoder);
  
      /**
       *  Create a list of message streams of type T for each topic, using the default decoder.
       */
      public Map<String, List<KafkaStream<byte[], byte[]>>> createMessageStreams(Map<String, Integer> topicCountMap);
  
      /**
       *  Create a list of message streams for topics matching a wildcard.
       *
       *  @param topicFilter a TopicFilter that specifies which topics to
       *                    subscribe to (encapsulates a whitelist or a blacklist).
       *  @param numStreams the number of message streams to return.
       *  @param keyDecoder a decoder that decodes the message key
       *  @param valueDecoder a decoder that decodes the message itself
       *  @return a list of KafkaStream. Each stream supports an
       *          iterator over its MessageAndMetadata elements.
       */
      public <K,V> List<KafkaStream<K,V>>
        createMessageStreamsByFilter(TopicFilter topicFilter, int numStreams, Decoder<K> keyDecoder, Decoder<V> valueDecoder);
  
      /**
       *  Create a list of message streams for topics matching a wildcard, using the default decoder.
       */
      public List<KafkaStream<byte[], byte[]>> createMessageStreamsByFilter(TopicFilter topicFilter, int numStreams);
  
      /**
       *  Create a list of message streams for topics matching a wildcard, using the default decoder, with one stream.
       */
      public List<KafkaStream<byte[], byte[]>> createMessageStreamsByFilter(TopicFilter topicFilter);
  
      /**
       *  Commit the offsets of all topic/partitions connected by this connector.
       */
      public void commitOffsets();
  
      /**
       *  Shut down the connector
       */
      public void shutdown();
    }

  这里有一些示例

  • 2.2.2 Old Simple Consumer API

      class kafka.javaapi.consumer.SimpleConsumer {
        /**
         *  Fetch a set of messages from a topic.
         *
         *  @param request specifies the topic name, topic partition, starting byte offset, maximum bytes to be fetched.
         *  @return a set of fetched messages
         */
        public FetchResponse fetch(kafka.javaapi.FetchRequest request);
    
        /**
         *  Fetch metadata for a sequence of topics.
         *
         *  @param request specifies the versionId, clientId, sequence of topics.
         *  @return metadata for each topic in the request.
         */
        public kafka.javaapi.TopicMetadataResponse send(kafka.javaapi.TopicMetadataRequest request);
    
        /**
         *  Get a list of valid offsets (up to maxSize) before the given time.
         *
         *  @param request a [[kafka.javaapi.OffsetRequest]] object.
         *  @return a [[kafka.javaapi.OffsetResponse]] object.
         */
        public kafka.javaapi.OffsetResponse getOffsetsBefore(OffsetRequest request);
    
        /**
         * Close the SimpleConsumer.
         */
        public void close();
      }

    对大多数应用而言，上层consumer api就可以满足。但是有些应用可能需要一些没有暴露到上层consumer中的特性（如：当重启consumer时重置偏移量）。他们可以使用低层的SimpleConsumer api。这个逻辑有点复杂，你可以参考这里的示例;

  • 2.2.3 新版消费者 Api

    新版consumer api删除了0.8版中，高层api与底层api的区别，直接使用统一的api。你直接使用下面的maven配置加载新版客户端。

      <dependency>
            <groupId>org.apache.kafka</groupId>
            <artifactId>kafka-clients</artifactId>
            <version>0.10.0.0</version>
        </dependency>

  用法示例

• 2.3 streams api

  在0.10.0版本中我们新增了一个称为”Kafka Stream”的新客户端库。它主要用于处理流式操作。特别注意,这个还是内测试版。有许多api在未来很可能有大的变动，因此使用需谨慎。你可以通过以下maven配置加载它。

    <dependency>
          <groupId>org.apache.kafka</groupId>
          <artifactId>kafka-streams</artifactId>
          <version>0.10.0.0</version>
      </dependency>

  这里的[javadocs]有一些示例（切记：标注了@InterfaceStability.Unstable注解的class，在未来很可能有大的变动，而且不会向后兼容。一句话：谁用谁填坑）。

3. 配置

kafka使用基于property文件格式的键值对配置程序。这些键值对即可以来自property文件，也可以来自编程方式。

• 3.1 代理(broker)（服务器）配置

  最核心最必须最基础的配置如下

  • broker.id
  • log.dirs
  • zookeeper.connect
    主题级别的配置，以及具体的默认配置在下面有详情讨论：看这里
    以下表格可以左右滚动

  名称	说明	数据类型	默认值	有效值	重要程度
  zookeeper.connect	zookeeper集群地址(多个用英文逗号分隔).集群中所有zookeeper主机ip及端口配置。	string			high
  advertised.host.name	DEPRECATED: only used when `advertised.listeners` or `listeners` are not set. Use `advertised.listeners` instead. Hostname to publish to ZooKeeper for clients to use. In IaaS environments, this may need to be different from the interface to which the broker binds. If this is not set, it will use the value for `host.name` if configured. Otherwise it will use the value returned from java.net.InetAddress.getCanonicalHostName().	string	null		high
  advertised.listeners	Listeners to publish to ZooKeeper for clients to use, if different than the listeners above. In IaaS environments, this may need to be different from the interface to which the broker binds. If this is not set, the value for `listeners` will be used.	string	null		high
  advertised.port	DEPRECATED: only used when `advertised.listeners` or `listeners` are not set. Use `advertised.listeners` instead. The port to publish to ZooKeeper for clients to use. In IaaS environments, this may need to be different from the port to which the broker binds. If this is not set, it will publish the same port that the broker binds to.	int	null		high
  auto.create.topics.enable	发布消息，如果主题不存在，则自动创建主题。否则必须先创建主题。线上一般为false	boolean	true		high
  auto.leader.rebalance.enable	Enables auto leader balancing. A background thread checks and triggers leader balance if required at regular intervals	boolean	true		high
  background.threads	The number of threads to use for various background processing tasks	int	10	[1,…]	high
  broker.id	The broker id for this server. If unset, a unique broker id will be generated.To avoid conflicts between zookeeper generated broker id’s and user configured broker id’s, generated broker idsstart from reserved.broker.max.id + 1.	int	-1		high
  compression.type	Specify the final compression type for a given topic. This configuration accepts the standard compression codecs (‘gzip’, ‘snappy’, ‘lz4’). It additionally accepts ‘uncompressed’ which is equivalent to no compression; and ‘producer’ which means retain the original compression codec set by the producer.	string	producer		high
  delete.topic.enable	Enables delete topic. Delete topic through the admin tool will have no effect if this config is turned off	boolean	false		high
  host.name	DEPRECATED: only used when `listeners` is not set. Use `listeners` instead. hostname of broker. If this is set, it will only bind to this address. If this is not set, it will bind to all interfaces	string	""		high
  leader.imbalance.check.interval.seconds	The frequency with which the partition rebalance check is triggered by the controller	long	300		high
  leader.imbalance.per.broker.percentage	The ratio of leader imbalance allowed per broker. The controller would trigger a leader balance if it goes above this value per broker. The value is specified in percentage.	int	10		high
  listeners	Listener List - Comma-separated list of URIs we will listen on and their protocols. Specify hostname as 0.0.0.0 to bind to all interfaces. Leave hostname empty to bind to default interface. Examples of legal listener lists: PLAINTEXT://myhost:9092,TRACE://:9091 PLAINTEXT://0.0.0.0:9092, TRACE://localhost:9093	string	null		high
  log.dir	日志（即数据)目录，其实是kafka的持久化文件目录。(log.dirs补充此配置)	string	/tmp/kafka-logs		high
  log.dirs	日志（即数据)目录，其实是kafka的持久化文件目录(可以配置多个用逗号隔开). 如果未设置，将使用 log.dir 配置的目录	string	null		high
  log.flush.interval.messages	The number of messages accumulated on a log partition before messages are flushed to disk	long	9223372036854775807	[1,…]	high
  log.flush.interval.ms	The maximum time in ms that a message in any topic is kept in memory before flushed to disk. If not set, the value in log.flush.scheduler.interval.ms is used	long	null		high
  log.flush.of