KAFKA 1.0 文档（一）：快速入门

1.1、简介

ApacheKafka®是一个分布式流媒体平台。 这到底是什么意思呢？
- 它可以让你发布和订阅消息流。 在这方面，它类似于消息队列或企业消息传递系统。
- 它允许您以容错方式存储消息流。
- 它可以让你处理产生的流式消息。

Kafka的优势在哪里？
- 在系统或应用程序之间构建可靠的实时数据流管道
- 构建实时流应用程序，可以转换或响应数据流

要理解kafka必须要了解一下概念：
- Kafka在一个或多个服务器上的集群运行。
- Kafka集群以叫做主题（topic）的类别存储记录流。
- 每个记录（消息）由一个键，一个值和一个时间戳组成。

Kafka有四个核心API：
1. Producer API允许应用程序将一组记录发布到一个或多个Kafka主题。
2. Consumer API允许应用程序订阅一个或多个主题并处理产生给他们的消息流。
3. Streams API允许应用程序充当流处理器，从一个或多个主题中消费输入流，并将输出流生成为一个或多个输出主题，从而将输入流有效地转换为输出流。
4. Connector API允许构建和运行可重复使用的生产者或消费者，将Kafka主题连接到现有的应用程序或数据系统。 例如，连接到关系数据库的连接器可能会捕获对表的每个更改。

在Kafka中，客户端和服务器之间的通信是通过一个简单的，高性能的，与编程语言无关的TCP协议完成的。 这个协议是版本化的，并保持与旧版本的向后兼容性。 我们为Kafka提供了一个Java客户端，但客户端可以使用多种语言。

主题和日志

让我们先深入kafka为消息流提供的一个核心抽象- 主题（topic）。
Topic是消息发布到哪一个类别或者提要的名称。Kafka的主题可以是多订阅模式的，也就是说一个主题可以有0个、1个或者多个消费者去消费写入该主题的数据。

对于每个主题，Kafka集群维护一个分区日志，如下所示：

每个分区是一个有序的，不可变的消息序列，不断追加到结构化的提交日志（文件）中。 分区中的每个消息分配一个连续的id号，称为偏移量（offset），用于唯一标识分区内的每条消息。
Kafka集群使用可配置的保留期限来保留所有已发布的消息（无论是否已被使用）。 例如，如果保留策略设置为两天，则在消息发布后的两天内，消息可以可供使用，之后将被丢弃以腾出空间。Kafka性能对数据大小不敏感，所以长时间存储数据不成问题。

实际上，以消费者为单位保留的唯一元数据是消费者在日志中的偏移或位置。这个偏移量是由消费者控制的：消费者通常会在读取记录时线性地推进其偏移量，但事实上，由于消费者的位置是由消费者控制的，所以它可以以任何喜欢的顺序消费记录。例如，消费者可以重置为较早的偏移量以重新处理过去的数据，或者跳至最近的记录并从“现在”开始消费。

这些功能的组合意味着Kafka的消费者非常轻便 - 他们可以来来去去，对集群或其他消费者没有太大的影响。例如，您可以使用我们的命令行工具来“tail”任何主题的内容，而不会更改任何现有消费者使用的内容。

日志中的分区有几个用途。 首先，它们允许日志的大小超出适合单个服务器的存储限制。 每个单独的分区必须适合存放它的服务器，但是一个主题可能有许多分区，因此它可以处理任意数量的数据。 其次，更重要的是，它们是作为并行处理的单位。

分布式

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

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

生产者

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

消费者

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

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

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

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

两个服务器Kafka集群管理四个分区（P0-P3）与两个消费者组。消费者组A有两个消费者实例，而组B有四个消费者实例。
然而，更普遍的是，topic只有少量的消费组，每个“逻辑订阅者”都有一个消费组。每个组由许多消费者实例组成，具有可扩展性和容错性。这就是发布-订阅模式，订阅者是一群消费者而不是一个进程。

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

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

kafka仅仅支持分区内的消息顺序消费，并不支持全局（同一主题的不同分区之间）的消息顺序。每个分区排序与根据消息key进行数据分区的能力相结合，足以满足大多数应用程序的需求。 但是，如果你需要一个全局顺序消费消息，你可以通过一个主题只有一个分区的方法实现，但是这也意味着一个分组只有一消费者。

保证

一个高级的kafka提供以下保证：
- 由生产者发送到特定主题分区的消息将按照它们发送的顺序添加。 也就是说，如果记录M1和记录M2由同一个生产者发送，并且M1被首先发送，则M1将具有比M2更低的偏移量值并且出现在日志中较早的地方。
- 消费者实例按照存储在日志中的顺序查看记录。
- 对于具有复制因子（replication factor）N的主题，我们将容忍多达N-1个服务器故障，而不会丢失任何提交给日志的记录。
有关这些保证的更多细节在文档的设计章节。

kafka作为消息系统

Kafka的流概念如何与传统的企业消息系统相比较？

消息传统上有两种模式：队列和发布-订阅。在队列中，消费者池可以从服务器读取并且每条消息只去往其中的一个;在发布-订阅中消息被广播给所有消费者。这两种模式都有其优点和缺点。队列的优势在于它允许您将数据处理划分为多个消费者实例，这样可以扩展处理。不幸的是，队列不是多订阅的，一旦一个进程读取了数据它就消失了。发布-订阅允许您将数据广播到多个进程，但无法进行扩展处理，因为每条消息都发送给每个订阅者。

Kafka的消费群体概念包含了这两个概念。与队列一样，消费者组允许您将一系列流程（消费者组的成员）的处理分开。与发布-订阅一样，Kafka允许您向多个消费者群体广播消息。

Kafka模型的优点是每个主题都具有这些属性 - 它可以扩展处理，也可以是多订阅 - topic不需要选择其中一个。

Kafka也比传统的消息系统有更强的顺序保证。

传统队列在服务器上按顺序保留记录，并且如果多个消费者从队列中消费，则服务器按照它们存储的顺序取出记录。但是，虽然服务器按顺序取出记录，但是记录是异步传递给消费者的，所以不同的消费者可能不是按照顺序收到消息。这实际上意味着记录的排序在并行消耗的情况下丢失。消息传递系统通常具有“排他消费者”的属性，只允许一个进程从队列中消耗，但这当然意味着在处理中没有并行处理能力。

Kafka做得更好。 通过在主题内部有一个并行的概念 - 分区，Kafka能够提供排序保证和负载平衡。 这是通过将主题中的分区分配给使用者组中的使用者来实现的，以便每个分区仅由组中的一个使用者使用。 通过这样做，我们确保消费者是该分区的唯一消费者，并按顺序使用这些数据。 由于有很多分区，这仍然可以平衡许多消费者实例的负载。 但请注意，消费群组中的消费者实例不能多于分区。

卡夫卡作为存储系统

任何允许将消息发布出去的消息队列都可以充当存储系统。 Kafka的不同之处在于它是一个非常好的存储系统。

数据写入kafka时被写入到磁盘, 并复制到其他服务器上进行容错, kafka允许生产者只有在消息已经复制完, 并存储后才得到写成功的通知, 否则就认为失败.

kafka也很有效率利用了磁盘结构–无论你存储的是50KB或50TB的数据在kafka上, kafka都会有同样的性能

由于严谨的考虑存储并允许客户端控制其读取位置，所以可以将Kafka视为专用于高性能，低延迟提交日志存储，复制和传播的专用分布式文件系统。

kafka作为数据流处理

只读取，写入和存储数据流是不够的，目的是允许流的实时处理。

kafka的流数据处理器是持续从输入的topic读取连续的数据流, 进行数据处理, 转换, 后产生连续的数据流输出到topic中

例如，零售应用程序可能会接受输入的销售和发货流，并输出一系列重排序的数据并针对这些数据的计算进行价格调整。

直接使用生产者和消费者API可以做简单的处理。但是对于更复杂的转换，Kafka提供了一个完全集成的Streams API。这允许构建应用程序进行非一般的处理，从而对流进行聚合或者join另外一个流。

这个工具有助于解决这类应用程序面临的难题：处理乱序数据，重新处理代码更改的输入，执行有状态的计算等等。

流API基于Kafka提供的核心原函数构建：它使用生产者和消费者API进行输入，使用Kafka进行有状态存储，并在流处理器实例之间使用相同的组机制来实现容错。

整合

消息传递，存储和流处理的这种组合可能看起来很不寻常，但对于Kafka作为一个流媒体平台来说，这是非常重要的。
像HDFS这样的分布式文件系统允许存储用于批处理的静态文件。这样的系统可以有效地存储和处理过去的历史数据。

传统的企业消息系统只允许处理在你订阅之后到达的数据，以这种方式构建的应用程序处理在将来到达的数据。

Kafka结合了这两种功能，而且这两种组合对于Kafka用作流应用平台以及流式传输数据管道都是至关重要的。

通过将存储和低延迟订阅相结合，流式应用程序可以同样的方式处理历史和未来的数据。一个应用可以处理历史存储的数据, 也可以在读到最后记录后, 保持等待未来的数据进行处理。这是流处理的概括概念，包括批处理以及消息驱动的应用程序。

1.2 使用案例

消息处理

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

根据我们的经验，消息传递的使用往往是相对较低的吞吐量，但可能需要较低的端到端延迟，并且通常取决于Kafka提供的强大的持久性保证。

在这个领域，Kafka与传统的消息系统（如ActiveMQ或RabbitMQ）相当。

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

Metrics度量

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

日志收集

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

流处理

Kafka的许多用户在处理管道中处理数据，这些数据由多个阶段组成，其中原始输入数据从Kafka topic中消费，然后聚合，补充或以其他方式转化为新的topic，供进一步消费或后续处理。通过kafka topics串联起所有步骤，形成一个数据处理通道。
如：一个处理新闻的流程：首先通过RSS收集新闻，并发布到”articles”主题中；第二步，从“articles”主题中取新闻并清洗重复内容，然后发布一个新的主题中；最后，从上步的主题中取数据并推荐给用户。
这样的处理管道是基于单个主题的实时数据流程图。从0.10.0.0版本开始，一个轻量但强大的，被称为kafka stream的功能用于处理这样的数据。除了Kafka stream还有另外相似的开源工具：Apache Storm / Apache Samza。

事件溯源（Event Sourcing）

事件溯源是应用程序设计的一种风格，其中状态更改以时间排序的记录序列进行记录。 Kafka对非常大的存储日志数据的支持使得它成为以这种风格构建的应用程序的优秀后端。

提交日志Commit Log

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

1.3 快速开始

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

Step 1: 下载代码

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

1 > tar -xzf kafka_2.11-0.11.0.2.tgz
2 > cd kafka_2.11-0.11.0.2

Step 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

Step 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

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

Step 4: 发送消息

通过命令行客户端，可以通过文件或标准输入（命令行）向kafka集群发送消息。默认每行都是一条消息。
启动生产者（启动成功进入命令行阻塞状态，可以输入数据，回车发送）

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

Step 5: 启动消费者

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

bin/kafka-console-consumer.sh –bootstrap-server localhost:9092 –topic test –from-beginning

Step 6: 设置服务器集群

到目前为止，我们一直在使用一个broker，但这并不好玩。 对于kafka来说，一个broker是只是有一台服务的集群，所以集群除了多启动几个broker实例之外，没有太大的改变。。 现在来感受下，让我们把我们的集群扩展到三个节点（仍然都在我们的本地机器上）。

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和我们的一个单节点了，所以我们只需要启动两个新的节点：

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

现在创建一个复制因子为3的新主题：

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。上图可以看出分区leader的broker.id是1，可以唯一一个，因为分区数是1。
- “replicas” 是分区副本保存节点的列表，无论这些备份节点是否leader，也不管这些节点是否活着，上面可以看出在节点1,2,0上各保存了一个副本。
- “isr” 是同步的副本。这是副本列表的子集，即当前还活着的并且可以被leader联系到的。

请注意，在示例中，节点1是该主题的唯一分区的领导者。

我们可以运行相同的命令行，用来查看我们最初创建的topic的信息

>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

毫无疑问，最初的topic没有副本备份，并且处于server 0上，就是当我们创建这个server时，我们的集群中仅有的server。

下面向新topic发送一些消息：

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

然后消费这些消息：

>bin/kafka-console-consumer.sh –bootstrap-server localhost:9092 –from-beginning –topic my-replicated-topic
…
my test message 1
my test message 2
^C

现在可以测试kafka 的容错性能，broker 1一直充当leader，我们可以杀掉他：

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

leader已经切换到两个从节点中的一个，并且broker1已经不在ISR中：

>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已经被killed，但是消息仍然可以使用

>bin/kafka-console-consumer.sh –bootstrap-server localhost:9092 –from-beginning –topic my-replicated-topic
…
my test message 1
my test message 2
^C

Step7：使用 Kafka Connect导出/导入数据

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

首先，我们创建一些种子数据，如下：

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

接下来，我们在独立模式下启动运行两个connectors，也就是在单一的，本地，专用的线程中。我们提供了三个配置文件作为参数。第一个是 Kafka Connect进程的，包含一些常见的配置，比如要链接的brokers和要序列格式化的数据。其余的每个配置都指定一个连接器去创建。这些文件包括一个唯一的连接器名称，连接器实例化类，和一些连接器需要的其他配置。

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

kafka包内包含了这些配置文件，用默认本地的kafka集群配置，并且创建两个connectors：第一个是一个source connector用来从输入文件逐行读取并且发送到topic，第二个是sink connector从topic读取消息并且逐行写到文件中。

当启动过程中，在会看到连接器的实例化日志。启动成功后，source connector开始从test.txt读取数据并且发送到connect-test这个topic中。同时sink connector开始从connect-test topic中读取消息并且写到test.sink.txt文件中。
我们可以看下test.sink.txt这个文件，看有没有数据写入：

> cat test.sink.txt foo bar
foo
bar

该数据被存储在kafka的connect-test topic中，所以我们可以运行一个消费者终端去看看在这个topic中的数据：

> 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”} …

connectors 继续处理数据，我们尝试向test.txt文件中继续添加数据：

> echo “Another line” >> test.txt

你应该看到有一行在消费者控制台输入，并且写入了sink文件。

Step 8：使用Kafka流来处理数据

见第9章

1.4生态系统

在主发行版之外还有大量与Kafka集成的工具。 生态系统页面列出了其中的许多内容，包括流处理系统，Hadoop集成，监控和部署工具。

1.5从以前的版本升级

从0.8.x，0.9.x，0.10.0.x，0.10.1.x或0.10.2.x升级到0.11.0.0

kafka0.11.0.0引入了一个新的消息格式版本以及有线协议的变化。 通过遵循以下建议的滚动升级计划，您可以保证在升级过程中不会出现停机。 不过，请在升级之前查看0.11.0.0中的版本更改。

从版本0.10.2开始，Java客户端（生产者和消费者）已经可以与老的broker进行通信。 版本0.11.0客户端可以与版本0.10.0或更加新的broker进行通信。 但是，如果您的broker版本比0.10.0老旧，则必须先升级Kafka集群中的所有broker，然后再升级您的客户端。 版本0.11.0 broker支持0.8.x和更加新的客户端。

滚动升级

1. 更新所有broker上的server.properties并添加以下属性。CURRENT_KAFKA_VERSION是指您要从哪个版本升级。CURRENT_MESSAGE_FORMAT_VERSION指的是当前正在使用的消息格式版本。如果您以前没有重写消息格式，那么应该将CURRENT_MESSAGE_FORMAT_VERSION设置为和CURRENT_KAFKA_VERSION一样。

   • inter.broker.protocol.version=CURRENT_KAFKA_VERSION (e.g. 0.8.2, 0.9.0, 0.10.0, 0.10.1 or 0.10.2).
   • log.message.format.version=CURRENT_MESSAGE_FORMAT_VERSION （请参阅升级后的潜在性能影响，了解有关此配置的详细信息。）

2. 一次升级一个broker：shut down the broker，更新代码并重新启动broker。

3. 一旦整个群集升级，通过编辑inter.broker.protocol.version并将其设置为0.11.0颠覆协议版本，但是不要更改log.message.format.version。
4. 重新启动代理，以使新的协议版本生效。
5. 一旦所有（或大部分）使用者升级到0.11.0或更高版本，则将每个代理上的log.message.format.version更改为0.11.0，然后逐个重新启动它们。

其他升级说明：

1. 如果你可以接受停机，你可以简单地把所有的经纪人关闭，更新代码并重新开始。 他们将默认启动新的协议。
2. 颠覆协议版本并重新启动可以在代理升级后的任何时候完成。 它不一定要在升级之后立即进行。对于log.message.format.version一样。
3. 在更新全局设置log.message.format.version之前，还可以使用主题管理工具（bin / kafka-topics.sh）在各个主题上启用0.11.0消息格式。
4. 如果要从0.10.0之前的版本升级，则在切换到0.11.0之前，不必先将消息格式更新为0.10.0。

关于一次语义的注记

kafka0.11.0支持生产者的幂等和事务性能力。 幂等式发送确保消息在单个生产者的生命周期内仅向特定主题分区发送一次。 事务发送允许生产者发送数据到多个分区，使得所有的消息都被成功地传递，或者全部都是失败。 结合在一起，这些功能使kafka“恰好一次语义”。 有关这些功能的更多详细信息，请参阅用户指南，但下面我们说一些关于在升级群集中启用它们的特定注意事项。 请注意，启用EoS不是必需的，如果未使用，则不会影响broker的行为。

1. 只有新的Java生产者和消费者支持一次语义。
2. 这些功能主要取决于0.11.0消息格式。 尝试以较旧的格式使用它们将导致不受支持的版本错误。
3. 事务状态存储在一个新的内部主题__transaction_state中。 直到首次尝试使用事务性请求API时才创建此主题。 类似于消费者偏移主题，有几个设置来控制主题的配置。 例如，transaction.state.log.min.isr控制这个主题的最小ISR。 请参阅用户指南中的配置部分以获取完整的选项列表。
4. 对于安全集群，事务性API需要新的ACL，可以使用bin / kafka-acls.sh工具打开。
5. Kafka的EoS引入了新的请求API，并修改了几个现有的API。 有关完整的详细信息，请参阅KIP-98

关于0.11.0中新消息格式的说明

为了支持生产者更好的交付语义（见KIP-98）和改进的复制容错能力（见KIP-101），0.11.0消息格式包括几个主要的增强。虽然新格式包含更多信息以使这些改进成为可能，但是我们已经使批处理格式更有效率。只要每批消息的数量大于2，就可以降低整体开销。然而，对于较小的批次，可能会有一个小的性能影响。请参阅这里了解我们对新消息格式的初始性能分析结果。您还可以在KIP-98提案中找到关于消息格式的更多细节。

新消息格式的显着差异之一是，使未压缩的消息一起存储为一个批次。这对broker配置max.message.bytes有一些影响，这会限制单个批处理的大小。首先，如果一个较老的客户端使用旧的格式向主题分区产生消息，并且个别消息小于max.message.bytes，则broker可能在消息的向上转换过程中合并为一个批次后仍然拒绝它们。通常，这可能发生在个别消息的聚合大小大于max.message.bytes的情况下。类似对于旧的消费者消费从新格式向下转换的消息也一样：如果获取大小没有被设置为至少与max.message.bytes一样大，即使单个未压缩的消息小于配置的提取大小，消费者也可能无法进行处理。此行为不影响Java客户端的0.10.1.0及更高版本，因为它使用更新的获取协议，该协议确保即使超过获取大小，也可以返回至少一条消息。为了解决这些问题，你应该确保

1）生产者的批量大小没有被设置为大于max.message.bytes，
2）消费者的获取大小至少被设置为max.message.bytes。

大多数关于升级到0.10.0消息格式对性能影响的讨论仍然与0.11.0升级有关。 这主要影响不使用TLS保护的群集，因为在这种情况下，“零复制”传输已经不可行。 为了避免消息向下转换成本，您应该确保客户应用程序升级到最新的0.11.0客户端。 值得注意的是，由于不支持新的消息格式，旧消费者在0.11.0.0已被弃用。 您必须升级才能使用新消费者消费新的消息格式，而不需要向下转换成本。 请注意，0.11.0的消费者支持0.10.0 broker向上兼容，因此可以在broker之前先升级客户端。