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版本增加了节点自动分配的特性。

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

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

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

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

【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

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

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

原文地址:https://www.cnblogs.com/likethis/p/12001494.html

时间: 2024-11-08 17:45:23

Kafka各版本对比分析的相关文章

最短路径算法的命令式、函数式版本对比分析

C版本(来自 最短路径算法—Dijkstra(迪杰斯特拉)算法分析与实现(C/C++)) 1 /*************************************** 2 * About: 有向图的Dijkstra算法实现 3 * Author: Tanky Woo 4 * Blog: www.WuTianQi.com 5 ***************************************/ 6 7 #include <iostream> 8 using namespace

测试工程师的福利!各远程移动测试平台对比分析

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由腾讯移动品质中心TMQ发表于云+社区专栏 背景 随着移动设备和系统的碎片化程度越来越高以及复杂的移动网络情况, 兼容性测试以及远程真机测试的重要性越来越突出.根据远程测试机/人员与开发者间的合作方式,可以分为以下几种服务:云测试服务.内测服务以及众测服务,相应的平台支持如下图. 云测试平台 云测试平台提供了远程租用真机的服务,通常是利用自动化框架来实现真机上的脚本自动化运行,或远程租用真机人工测试,或真人真机测试.由于Androi

Storm 系列(六)—— Storm 项目三种打包方式对比分析

一.简介 在将 Storm Topology 提交到服务器集群运行时,需要先将项目进行打包.本文主要对比分析各种打包方式,并将打包过程中需要注意的事项进行说明.主要打包方式有以下三种: 第一种:不加任何插件,直接使用 mvn package 打包: 第二种:使用 maven-assembly-plugin 插件进行打包: 第三种:使用 maven-shade-plugin 进行打包. 以下分别进行详细的说明. 二.mvn package 2.1 mvn package的局限 不在 POM 中配置

GitHub &amp; Bitbucket &amp; GitLab &amp; Coding 的对比分析

来源于:https://www.v2ex.com/t/313263 目前在代码托管和版本控制上的主流工具 — Git ,比较流行的服务有 Github . Bitbucket . GitLab . Coding ,他们各自有什么特点,个人使用者和开发团队又该如何选择? 在这篇文章中,我们以客观的态度,以问题作为出发点,介绍和比较 GitHub . Bitbucket . GitLab . Coding 在基本功能,开源与协作,免费与付费计划,企业解决方案,集成 flow.ci 等方面,让大家了解

(转)netty、mina性能对比分析

转自: http://blog.csdn.net/mindfloating/article/details/8622930 流行 NIO Framework netty 和 mina 性能测评与分析 测试方法 采用 mina 和 netty 各实现一个 基于 nio 的EchoServer,测试在不同大小网络报文下的性能表现 测试环境 客户端-服务端: model name: Intel(R) Core(TM) i5-2320 CPU @ 3.00GHz cache size: 6144 KB

常用hash函数对比分析(一)

主要目标:寻找一个hash函数,高效的支持64位整数运算,使得在速度.空间等效率相对其它函数函数较高,以及内部运算时32位整数运算. 测试了"RSHash","JSHash","PJWHash","ELFHash","BKDRHash","SDBMHash","DJBHash","DEKHash","BPHash","

Android和Linux应用综合对比分析

公开发布的序言: 这篇文章是作于2012年7月12日,也就是自己刚从大学校园迈向工作岗位的时候遇到的第一个题目"请你针对我们公司目前的应用行业场景做一下调研:在终端做应用程序开发的平台是选择Linux好还是Android好"而写的. 在踏出校园之前,自己从来没有接触过安卓的开发领域(除了在2010年下半年买了一部分安卓的智能手机外).接到这个题目后,自己也没有退缩,硬着头皮接下来了,然后凭借自己在学校时候学的一点检索信息写学术论文的小功底,三天之内写下了这篇长达1万4千多字的调研报告,

三大WEB服务器对比分析(apache ,lighttpd,nginx)

一.软件介绍(apache  lighttpd  nginx) 1. lighttpd Lighttpd是一个具有非常低的内存开销,cpu占用率低,效能好,以及丰富的模块等特点.lighttpd是众多OpenSource轻量级的web server中较为优秀的一个.支持FastCGI, CGI, Auth, 输出压缩(output compress), URL重写, Alias等重要功能. Lighttpd使用fastcgi方式运行php,它会使用很少的PHP进程响应很大的并发量. Fastcg

近3年微软与谷歌的发展对比分析

     近3年微软与谷歌的发展对比分析   随着科技的快速发展,时代的不断进步,微软和谷歌凭借这不断的创新已然成为当今全球科技公司的领头羊.位列世界500强的微软是一个相当具有经济与科技实力的的公司,然而同样位列世界500强的谷歌凭借着家喻户晓的Google搜索成为了微软一个相当具有竞争力的科技大亨. 同为IT公司,微软和谷歌的比较如下: 一.发展历史 微软作为一个1975年成立的老牌公司,从一开始的为IBM提供文件系统和操作系统等软件,到现在业务中有各种操作系统编译器和解释器.网页浏览器等基