Kafka各版本对比分析

 

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发行了一下几个版本

版本号	发行时间
0.10.0.0	2016-05-22
0.10.0.1	2016-08-10
0.10.1.0	2016-10-20
0.10.1.1	2016-12-20
0.10.2.0	2017-02-21
0.10.2.1	2017-04-26

支持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发行了以下几个版本

版本号	发行时间
0.11.0.0	2017-06-28
0.11.0.1	2017-09-13
0.11.0.2	2017-11-13

支持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等），做以下表格对比：

 

特性/Kafka版本	0.8.x	0.9.x	0.10.x	0.11.x	1.0.0
StreamAPI (流式计算支持)	不支持	支持	增强	增强	增强
安全性 （数据传输，连接等）	无	SSL/SASL 验证连接 授权客户端	优化支持 SASL/PLAN	优化	优化
平滑升级 （不停机升级）	不支持	不支持	0.10.2	支持	支持
KafkaConnact (数据导入导出)	不支持	支持	优化	优化	优化
当前Fink (支持的Kafka版本)	支持	支持	支持	支持	不支持
Flume1.5.2	支持	支持	有类似对接	不确定	不确定
SDK (.net-confluent)	支持	支持	支持	支持	不支持
Zookeeper版本	3.4.6	3.4.6	3.4.8-3.4.9	3.4.10	3.4.10
JDK	JDK1.7-U51	JDK1.8U5	JDK1.8U5	JDK1.8U5	JDK1.8U5
KafkaManager	支持	支持	支持	支持	不支持
Scala	2.9.1/2.9.2 2.10/2.11	2.10/2.11	2.10/2.11	2.11/2.12	2.11/2.12

• 对于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 fully featured .NET client for Apache Kafka based on librdkafka (a fork of rdkafka-dotnet).

Kafka Version: 0.8.x, 0.9.x, 0.10.x, 0.11.x

Maintainer: Confluent Inc. (original author 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开始

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

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