05 | 聊聊Kafka的版本号
该思维导图由 AI 生成，仅供参考
Kafka 版本命名
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Kafka版本选择对于使用Kafka的关键性很重要。文章首先解释了Kafka版本号的命名规则，强调了理解版本号的重要性。作者指出，Kafka版本号实际上由三个部分构成，即“大版本号 - 小版本号 - Patch号”，并对此进行了详细解释。此外，文章还介绍了Kafka的版本命名存在的歧义，解释了版本号中Scala编译器版本的含义。作者还提到了Kafka客户端代码由Java语言编写的转变，以及Scala语言的特点。总的来说，文章强调了理解Kafka版本号的重要性，以及对版本号命名规则的解释和建议。 Kafka版本演进自0.7至2.0，每个版本都带来了重大的功能改进。0.7版本是最早开源的版本，功能基础，不建议使用。从0.8版本开始引入了副本机制，使Kafka成为完备的分布式高可靠消息队列解决方案。0.9版本增加了基础的安全认证/权限功能，使用Java重写了新版本消费者API，并引入了Kafka Connect组件。0.10.0.0版本引入了Kafka Streams，正式升级成分布式流处理平台。0.11.0.0版本引入了幂等性Producer API、事务API和对Kafka消息格式的重构。1.0和2.0版本主要改进了Kafka Streams。作者建议选择适合自身情况的Kafka版本，而不是一味追求最新版本。 总的来说，了解各个Kafka版本的差异，根据实际情况做出最正确的选择是至关重要的。文章还提到了保持服务器端版本和客户端版本一致的重要性。最后，作者鼓励读者分享自己的思考或疑问，并欢迎开放讨论。 文章内容涵盖了Kafka版本演进的重要里程碑和功能改进，以及选择合适版本的建议，对于Kafka用户来说具有很高的参考价值。
《Kafka 核心技术与实战》，新⼈⾸单¥68
全部留言(64)
- 最新
- 精选
风中花每次看完就想打卡，以表示我还在坚持学习，如此看来，这个版本真不能忽视作者回复: 嗯嗯，之前在做咨询的时候发现过两个问题：1. 很多人碰到的问题实际上已经是新版本解决的bug；2. 客户端/服务器端版本不一致导致的性能问题 因此觉得写一篇版本的文章还是有点必要的。
2019-06-17216
开水目前用的是hdp2.4.2内嵌版本。应该是apache版本的0.8.2.0。遇到很多问题都很难找到解决方法。比如前几天遇到了replicaFetcherThread oom的问题，网上根本找不到什么正经的解释。但又不能一味的调高jvm参数。老大说现在生产稳定就行了，暂时不要升级了，改代码耗时切面对的问题未知。期待老大能看到这篇文章，升级到0.11.0.3。作者回复: 嗯嗯，可以查一下ZooKeeper中是否存在大量session超时的情况。不过还是建议升级吧，听着很像是一个已知的bug。如果暂时不能升级，可以尝试调低replica.fetch.max.bytes的值试试。
2019-06-1312
King Yao我是一名运维，在维护工作环境维护几十台Kafka。最近打算扩容。我有三个问题请教： 1.kafka如何做压力测试，它的参考主要指标是什么，比如QPS,最大连接数，延迟等等。 2.扩容如何做到平滑扩容，不影响原业务 3.kafka有什么好的监控软件。作者回复: 1. Kafka提供了命令行脚本可以执行producer和consumer的性能测试，主要指标还是TPS，延时 2. 增加broker很简单，也不会对现有业务有影响。关键是做好迁移计划——比如避开业务高峰时刻，如果迁移对业务影响最小
2019-06-13311
平叔叔不论你用的是哪个版本，都请尽量保持服务器端版本和客户端版本一致 另外即使你升到了 0.8.2.2，也不要使用新版本 Producer api 不是互相矛盾吗？作者回复: 不矛盾。保持版本一致是任何时候都要尽力保持的。如果你依然使用0.8.x版本，那么最好使用Scala producer，而不是java producer
2019-09-2227
南辕北辙记得在刚开始学kafka写demo时，找到了kafka.producer.Producer,以及apache.kafka...KafkaProducer，还以为只是2种不同的实现方式，后来在老师的书上才得知这完全是2个版本。针对今天讨论的版本差异，书上也做了很好了总结。 现在看来比较难理解的就是客户端的版本与服务端版本的兼容问题，与之前的各种技术还是有点差异的，并不是一味的较新客户端就完事，kafka中还有一种请求版本号的存在。 图片为书中版本对比 https://raw.githubusercontent.com/DarkerPWQ/picgo/master/img/Kafka%E7%89%88%E6%9C%AC%E5%8F%98%E8%BF%81.png作者回复: 嗯嗯，请求版本号偏底层的设计了，一般用户用不到。其实客户端和服务器端版本的差异很大一部分也是请求版本号的差异
2019-06-136
疯琴美音最正的老师没有之一。有两个问题：1 文章前面说某些旧版本的服务端不适用新版本的客户端，文末又说二者应该保持一致，感觉是矛盾的，应该是我没理解清楚，还请说明 2 服务端版本靠编号就可以识别，而客户端是怎么定义新旧版本的呢？谢谢。作者回复: 1. 其实我也没太明白您的意思：） “旧版本的服务端不适用新版本的客户端 所以建议保持一致”，不是挺自然的结论吗。。。。 2. 客户端也有版本号，和broker端是一样的。比如Java客户端，如果我们使用Gradle的话，就类似于这样： compile group: 'org.apache.kafka', name: 'kafka-clients', version: '2.2.1'
2019-06-1326- 火力全开“最后还有个建议，不论你用的是哪个版本，都请尽量保持服务器端版本和客户端版本一致，否则你将损失很多 Kafka 为你提供的性能优化收益。” —— KIP-35 - Retrieving protocol version 这个特性不是可以让支持的client适配多个不同版本的broker吗？
作者回复: 兼容性是一方面。因版本差异导致消息格式转换会丧失Zero Copy
2020-02-1424 
bee请问胡老师， RESTful的幂等性是无论调用多少次都不会有不同结果的HTTP 方法。也就是说不会去改变资源。这里的幂等性虽然是确保了单个partition的数据不会重复，但是更改了资源。这样说会有冲突吗？作者回复: 这里的幂等性也没有你所谓的更改资源。当producer发送了一条重复消息时Broker端会拒绝接收，而不是在后面自己做去重
2019-06-1324
jacke胡老师，问下： "如果你不能升级大版本，我也建议你至少要升级到0.8.2.2+这个版本，因为该版本中老版本消费者API是比较稳定的。另外即使你升到了0.8.2.2，也不要使用新版本+Producer+API，此时它的Bug还非常多" == 不是很明白 这段话的意思升级到0.8.2.2，使用0.8.2.2的consumer api, 但是不要0.8.2.2的 producer api? 使用0.8大版本号下的producer api 是这个意思吗作者回复: 如果使用0.8.2.2，那么使用老版本的consumer和producer，不要使用新版本的客户端。它们此时还有很多bug。我是这个意思。。。。
2019-06-223
云＆龙既然新版本的老功能更加完善，而老版本又没有新版本的新功能，那为什么不无脑用最新的版本呢？？？反正用老版本也没有新功能。作者回复: 如果是新环境，也许可以采用最新版本。但如果是要升级的话就要考虑这些问题了
2019-06-133
