1. Kafka 只是一个消息引擎系统吗？

Apache Kafka 是消息引擎系统，也是一个分布式流处理平台（Distributed Streaming Platform）

Kafka 在设计之初就旨在提供三个方面的特性：

• 提供一套 API 实现生产者和消费者
• 降低网络传输和磁盘存储开销
• 实现高伸缩性架构

批处理：批量处理冷数据，单个处理数据量大

流处理：处理在线，实时产生的数据，单次处理的数据量小，但处理速度更快

 流处理要最终替代它的“兄弟”批处理需要具备两点核心优势：

1. 要实现正确性，实现正确性是流处理能够匹敌批处理的基石
2. 提供能够推导时间的工具。

正确性一直是批处理的强项，而实现正确性的基石则是要求框架能提供精确一次处理语义，即处理一条消息有且只有一次机会能够影响系统状态。目前主流的大数据流处理框架都宣称实现了精确一次处理语义，但这是有限定条件的，即它们只能实现框架内的精确一次处理语义，无法实现端到端的。

l  Kafka Streams 正是它提供了 Kafka 实时处理流数据的能力

l  Kafka Connect 通过一个个具体的连接器（Connector），串联起上下游的外部系统

2. apache Kafka 流处理平台主要组件介绍

Kafka Streams 正是它提供了 Kafka 实时处理流数据的能力

Kafka Connect 通过一个个具体的连接器（Connector），串联起上下游的外部系统

3.不同版本间的Kafka应该如何选择？

1. Apache Kafka

Apache Kafka 是最“正宗”的 Kafka，自 Kafka 开源伊始，它便在 Apache 基金会孵化并最终毕业成为顶级项目，它也被称为社区版 Kafka，也就是说，后面提到的发行版要么是原封不动地继承了 Apache Kafka，要么是在此之上扩展了新功能，总之 Apache Kafka 是我们学习和使用 Kafka 的基础

优点：是开发人数最多、版本迭代速度最快的 Kafka，当使用 Apache Kafka 碰到任何问题并提交问题到社区，社区都会比较及时地作出响应。

缺点：仅仅提供最最基础的组件，特别是对于前面提到的 Kafka Connect 而言，社区版 Kafka 只提供一种连接器，即读写磁盘文件的连接器，而没有与其他外部系统交互的连接器，在实际使用过程中需要自行编写代码实现。另外 Apache Kafka 没有提供任何监控框架或工具。显然在线上环境不加监控肯定是不可行的，你必然需要借助第三方的监控框架实现对 Kafka 的监控。好消息是目前有一些开源的监控框架可以帮助用于监控 Kafka（比如 Kafka manager）。kafka eagle 也是非常不错的监控软件，好像也是国人写的，一直在更新，而且不比kafka manager差（JMXTrans + InfluxDB + Grafana）

总而言之，如果你仅仅需要一个消息引擎系统亦或是简单的流处理应用场景，同时需要对系统有较大把控度，那么我推荐你使用 Apache Kafka

2. Confluent Kafka

2014 年，Kafka 的 3 个创始人 Jay Kreps、Naha Narkhede 和饶军离开 LinkedIn 创办了 Confluent 公司，专注于提供基于 Kafka 的企业级流处理解决方案。

Confluent 公司它主要从事商业化 Kafka 工具开发，并在此基础上发布了 Confluent Kafka

Confluent Kafka 提供了一些 Apache Kafka 没有的高级特性，跨数据中心备份、Schema 注册中心以及集群监控工具等

优点：

免费版：免费版包含了更多的连接器，它们都是 Confluent 公司开发并认证过的，你可以免费使用它们，还包含 Schema 注册中心和 REST proxy 两大功能

企业版：开放 HTTP 接口的方式允许你通过网络访问 Kafka 的各种功能，最有用的当属跨数据中心备份和集群监控两大功能了。多个数据中心之间数据的同步以及对集群的监控历来是 Kafka 的痛点，Confluent Kafka 企业版提供了强大的解决方案帮助你“干掉”它们

缺点：Confluent 公司暂时没有发展国内业务的计划，相关的资料以及技术支持都很欠缺，很多国内 Confluent Kafka 使用者甚至无法找到对应的中文文档，因此目前 Confluent Kafka 在国内的普及率是比较低的

一言以蔽之，如果你需要用到 Kafka 的一些高级特性，那么推荐你使用 Confluent Kafka。

3. Cloudera/Hortonworks Kafka

Cloudera 提供的 CDH 和 Hortonworks 提供的 HDP 是非常著名的大数据平台，里面集成了目前主流的大数据框架，能够帮助用户实现从分布式存储、集群调度、流处理到机器学习、实时数据库等全方位的数据处理。这两款产品中的 Kafka 称为 CDH Kafka 和 HDP Kafka

优点：这些大数据平台天然集成了 Apache Kafka，通过便捷化的界面操作将 Kafka 的安装、运维、管理、监控全部统一在控制台中。所有的操作都可以在前端 UI 界面上完成，而不必去执行复杂的 Kafka 命令。另外这些平台提供的监控界面也非常友好，你通常不需要进行任何配置就能有效地监控 Kafka

缺点：这样做的结果是直接降低了你对 Kafka 集群的掌控程度。毕竟你对下层的 Kafka 集群一无所知。另一个弊端在于它的滞后性。由于它有自己的发布周期，因此是否能及时地包含最新版本的 Kafka 就成为了一个问题。比如 CDH 6.1.0 版本发布时 Apache Kafka 已经演进到了 2.1.0 版本，但 CDH 中的 Kafka 依然是 2.0.0 版本，显然那些在 Kafka 2.1.0 中修复的 Bug 只能等到 CDH 下次版本更新时才有可能被真正修复。

简单来说，如果你需要快速地搭建消息引擎系统，或者你需要搭建的是多框架构成的数据平台且 Kafka 只是其中一个组件，那么我推荐你使用这些大数据云公司提供的 Kafka。

4. Kafka版本命名

前面的版本号是编译 Kafka 源代码的 Scala 编译器版本（2.12）

真正的 Kafka 版本号实际上是 2.5.0。那么这个 2.5.0 又表示什么呢？前面的 2 表示大版本号，即 Major Version；中间的 5 表示小版本号或次版本号，即 Minor Version；最后的 1 表示修订版本号，也就是 Patch 号

5.Kafka的版本引进

Kafka 目前总共演进了 7 个大版本，分别是 0.7、0.8、0.9、0.10、0.11、1.0 和 2.0，其中的小版本和 Patch 版本很多。哪些版本引入了哪些重大的功能改进？

0.7

这是最早开源时的“上古”版本了，以至于我也从来都没有接触过。这个版本只提供了最基础的消息队列功能。甚至连副本机制都没有

0.8

Kafka 从 0.7 时代演进到 0.8 之后正式引入了副本机制，至此 Kafka 成为了一个真正意义上完备的分布式高可靠消息队列解决方案。有了副本备份机制，Kafka 就能够比较好地做到消息无丢失。那时候生产和消费消息使用的还是老版本的客户端 API，所谓的老版本是指当你用它们的 API 开发生产者和消费者应用时，你需要指定 ZooKeeper 的地址而非 Broker 的地址。

老版本客户端有很多的问题，特别是生产者 API，它默认使用同步方式发送消息，可以想见其吞吐量一定不会太高。虽然它也支持异步的方式，但实际场景中可能会造成消息的丢失，因此 0.8.2.0 版本社区引入了新版本 Producer API，即需要指定 Broker 地址的 Producer.如果要使用0.8的版本至少要升级到 0.8.2.2 这个版本，因为该版本中老版本消费者 API 是比较稳定的。另外即使你升到了 0.8.2.2，也不要使用新版本 Producer API，此时它的 Bug 还非常多

0.9

2015 年 11 月，社区正式发布了 0.9.0.0 版本。这是一个重量级的大版本更迭，0.9 大版本增加了基础的安全认证 / 权限功能，同时使用 Java 重写了新版本消费者 API，另外还引入了 Kafka Connect 组件用于实现高性能的数据抽取。还有另一个好处是新版本 Producer API 在这个版本中算比较稳定了。如果你使用 0.9 作为线上环境不妨切换到新版本 Producer，这是此版本一个不太为人所知的优势。但和 0.8.2 引入新 API 问题类似，不要使用新版本 Consumer API，因为 Bug 超多的

0.10

0.10.0.0 是里程碑式的大版本，因为该版本引入了 Kafka Streams。从这个版本起，Kafka 正式升级成分布式流处理平台，虽然此时的 Kafka Streams 还基本不能线上部署使用

0.10 大版本包含两个小版本：0.10.1 和 0.10.2，它们的主要功能变更都是在 Kafka Streams 组件上。如果你把 Kafka 用作消息引擎，实际上该版本并没有太多的功能提升。

但是在0.10.2.2 版本起，新版本 Consumer API 算是比较稳定了。并且0.10.2.2 修复了一个可能导致 Producer 性能降低的 Bug

0.11

2017 年 6 月，社区发布了 0.11.0.0 版本，引入了两个重量级的功能变更：

• 提供幂等性 Producer API 以及事务（Transaction） API
• 对 Kafka 消息格式做了重构

Producer 实现幂等性以及支持事务都是 Kafka 实现流处理结果正确性的基石。没有它们，Kafka Streams 在做流处理时无法向批处理那样保证结果的正确性。当然同样是由于刚推出，此时的事务 API 有一些 Bug，不算十分稳定。另外事务 API 主要是为 Kafka Streams 应用服务的

第二个重磅改进是消息格式的变化。虽然它对用户是透明的，但是它带来的深远影响将一直持续。因为格式变更引起消息格式转换而导致的性能问题在生产环境中屡见不鲜，所以你一定要谨慎对待 0.11 版本的这个变化。不得不说的是，这个版本中各个大功能组件都变得非常稳定了，国内该版本的用户也很多，应该算是目前最主流的版本之一了。

1.0 和 2.0

两个大版本主要还是 Kafka Streams 的各种改进，在消息引擎方面并未引入太多的重大功能特性。如果你是 Kafka Streams 的用户，至少选择 2.0.0 版本吧。

思考

Kafka 版本是否升级应该如何考虑？

首先，看业务在使用当前Kafka版本是否有问题,是否有性能问题,
其次，当前版本特性是否满足业务需求,是否需要新的Kafka特性
然后，查看该当前版本是否还在迭代更新,以及迭代周期
最后，升级Kafka版开发人员所付出的人工成本和时间成本

不要成为最新版本的小白鼠， 如果确实想升级，也建议小范围可控制之内再升级

Kafka 版本介绍

原文：https://www.cnblogs.com/start-from-zero/p/13430611.html