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中配置和使用安全功能。