1   概述

目前我们部分系统还在使用Kafka0.8.2.2 的版本。

0.8.2.2版本发行于2014年10月28号，距今已经过去4年多的时间。

三年的时间，Kafka截至到（2018-02-28），已经累计发布了14个版本，最新版本为1.0.0，由此，0.8.2已经远远落后于Kafka的最新版本14个版本，很多新特性和功能比新版本有较大差距。

0.8.2.2到1.0.0版本中间有0.9.x，0.10.x，0.11.x，1.0.0等四个大本版本的更迭，集中讨论0.8存在的问题以及0.9.x，0.10.x、0.11.x、1.0.0四大版本的新特性做分析说明。

2   版本0.8.2.2

2.1 存在问题

l  节点ID没有自动分配，需要在配置文件中设置Broker.ID=1,在0.9.x版本增加了节点自动分配的特性。

l  ZkClient重新连接后发生UnknownHostException异常，ZkClient异常死掉。

l  Broker-Topic数据未与Zookeeper同步。

l  Kafka生产者和消费者存在资源泄漏的风险。

l  【Kafka-2147】复制因子之间负载不均衡，导致某一个分区数据突发增长（常见于重做Broker节点或添加删除Broken节点，增加分区）。

l  【Kafka-2163】偏移量管理器处理过期偏移量清理时，丢失了当前消费者正常的偏移量（Offset值为负数或者无效值）

l  Flink的SDK组件有问题，Kafka宕机，容易导致Flink无限重启。

l  Kafka的0.8版本的sdk支持有限，大部分都不支持了。（SDK不再同步更新）

l  更多详情可查看连接

https://archive.apache.org/dist/kafka/0.9.0.0/RELEASE_NOTES.html

经过统计，0.8.x版本大大小小的Bug共计289个，其中大部分问题和Bug都在0.9以及更高版本中得到修复。

2.2 关于安全

截至目前版本，Kafka0.8.2中没有提供任何安全机制，但是从0.9版本开始，Kafka开始提供了可选的安全机制，主要包括认证和授权。

3    版本0.9.x

3.1 概述

一、安全特性：

0.9之前，Kafka的安全方面几乎为零，Kafka集群提供了安全性。其中主要包括：

1、 Broker使用SSL或者SASL（Kerberos），验证客户端（生产者消费者）、其他Broker或工具的连接。

2、 从Broker连接到Zookeeper的身份认证

3、 Broker和Client之间做数据传输时，Broker之间或使用SSL的Broker和Client之间的数据加密。（使用SSL时，性能会降低）

4、 Client的Read和Write操作有验证。

二、KafkaConnect

    全新的功能模块，主要用于与外部系统、数据集建立连接，实现数据的流入流出。

例如，可以通过KafkConect实现：

往一个文本文件输入数据，数据可以实时传输到Topic中。

三、新的ConsumerAPI

新的Consumer中，取消了High-level、Low-Level之分，都是自己维护Offset。

这样做的好处就是避免应用出现异常时，数据为消费成功，但是Offset已经提交，导致消息丢失。

Kafka可以自己维护Offset消费者的Position，也可以开发这自己维护Offset。

消费时，可以执行Partition消费

可以使用外部存储记录Offset（业务数据库）。

自行控制Consumer的消费位置。

可以多线程消费。

4    版本0.10.x

4.1 概述

目前0.10.x发行了一下几个版本

支持Scala2.10、2.11、2.12版本

4.2 新特性

• 从0.10.2版本开始，Java客户端（生产者和消费者）就有了旧版本Broker通信的能力。当然只能时0.10.0之后的版本。这就使得不停机升级Kafka集群（或客户端）成为了可能。
• Kafka已经提供了流计算的能力：每个消息都包含了时间戳的字段，Kafka Stream能够处理基于时间的流。
• Kafka内置了机架感知以便隔离副本，这使得Kafka保证副本可以跨越到多个机架或者可用区域，提高可Kafka的可用性和弹性。
• 增强了安全性
• KafkaConnect得到增强。
• 日志保留事件不在基于日志段的上次修改时间，而是基于日志中消息的最大时间。
• 日志转出也有响应的修改，之前基于日志创建时间，现在基于第一条消息的时间：如果最新消息的时间-第一条消息的时间>=log.roll.ms,消息日志将被转出。
• 每个消息段增加了时间戳，日志文件开销增大大约33%
• 时间索引和偏移索引文件的增加，在一些具有大量日志文件的Broker上，Broker启动的时间也会变长，可以设置num.recovery.threads.per.data.dir=1来缓解该现象
• 从0.10.1.0版本开始，集群唯一标识可以自动生成。
• 旧的Kafka生产者已经被弃用。
• 新的消费者API逐渐稳定。

5    版本0.11.x

5.1 概述

目前0.11.x发行了以下几个版本

支持Scala2.11和2.12版本，不再支持2.10版本

5.2 新特性

0.11版本，是个里程碑式的大版本。每一个改动都值的详细的研究。

• 修改了Unclear.Leader.election.enabed的默认值

Kafka将该参数的默认值改为False，不再允许Unclean leader选举的情况。在正确性和高可用性之间选择了正确性，如果要保证高可用性，需要将该参数显示的声明为true

• 确保Offsets.topic.relication.factor参数被正确应用。（复制因子数）

之前的版本中，都是取最小者，在0.11版本中，强制使用该参数值，如果不满足，则会抛出GROUP_COORDINATOR_NOT_AVAILABLE 异常，

假如指定的复制因子与该值不一致，则创建Topic不成功。

• 优化了对Snappy的支持。
• 每个消息增加了头部信息Header

Record增加了Header,每一个Header时KV存储，具体的Header设计可以参见KIP-82

• 空的消费者组延时relalance

为了缩短多Consumer首次Relalance的时间，增加了Group.initial.relance.delay.ms的设置，用于开启Relance延时，延时过程中可以有更多的Conumer加入组，提升了性能，同时也带来了消费延时。

• 消息格式变更
• 全新的平衡分配算法

经常遇见消费者分配不均匀的情况，增加了partion.assignment.strategy=

Org.apach.kafka.clients.consumer.stickassignore的设置。

1、  Contrller重新设计

a)      采用了单线程+基于消息队列的方式，一定程度上应该会提升性能。

2、  支持EOS

EOS流式处理。

6    版本1.0.0

6.1 概述

1.0.0版本发布于2017年11月1日

支持Scala2.11和2.12两个版本。

Kafka1.0.0也是一个里程碑是的大版本。

但是我们使用Flink的版本最高支持到Kafka0.11.x，所以，关于1.0.0只简单了解，不进行深入分析。

6.2 新特性

• 增加了StreamAPI。
• Kafka-Connect得到增强。
• 支持Java9
• 增强了安全性。
• 等

7    版本分析

我们对各个版本做了新特性的了解之后，结合现有的各大平台组件（Flink等），做以下表格对比：

• 对于Zookeeper版本，没有硬性要求，只要相差不大就可以，但是为了安全起见，我们选定版本使用kafka集成的版本相对应的的Zookeeper版本。(为何不使用集成的Zookeeper：后续可以拆分Zookeeper集群和Kafka集群)
• Flink支持最新版本到0.11.x
• Flume1.5.2目前收集到的信息能支持到0.10.x，再高级点的版本暂时未找到相关资料。
• JDK除0.8.x推荐1.7之外，其他都推荐JDK1.8
• 安全性方面，从0.9版本开始，每个版本都会对安全性做优化。
• 我们一直使用的监控工具是KafkaManager，新版本Kafka中也将使用KafkaManager作为监控工具。

以上分析，结合Fink和Flume的版本支持，我们目前选定0.10.2版本作为Kafka0.8.2的替换版本。

8    附录

8.1 SDK

A fullyfeatured .NET client for Apache Kafka based on librdkafka (a fork of rdkafka-dotnet).

KafkaVersion: 0.8.x, 0.9.x, 0.10.x, 0.11.x

Maintainer: Confluent Inc. (originalauthor Andreas Heider)

License:Apache 2.0

https://github.com/confluentinc/confluent-kafka-dotnet

官方指定的SDK，为ConfluentPlatform中的一部分，目前支持版本较多，各方面支持都做得很到位，用户基数也比较大。

8.2 安全性

在0.9.0.0版中，Kafka社区添加了一些特性，通过单独使用或者一起使用这些特性，提高了Kafka集群的安全性。目前支持下列安全措施：

1. 使用SSL或SASL验证来自客户端(producers和consumers)、其他brokers和工具的连接。Kafka支持以下SASL机制：

• SASL/GSSAPI (Kerberos) - 从版本0.9.0.0开始
• SASL/PLAIN - 从版本0.10.0.0开始
• SASL/SCRAM-SHA-256 和 SASL/SCRAM-SHA-512 - 从版本0.10.2.0开始

1. 验证从brokers 到 ZooKeeper的连接
2. 对brokers与clients之间、brokers之间或brokers与工具之间使用SSL传输对数据加密(注意，启用SSL时性能会下降，其大小取决于CPU类型和JVM实现)。
3. 授权客户端的读写操作
4. 授权是可插拔的，并且支持与外部授权服务的集成

值得注意的是，安全是可选的 - 支持非安全集群，也支持需要认证，不需要认证，加密和未加密clients的混合集群。 以下指南介绍了如何在clients和brokers中配置和使用安全功能。