kafka 版本命名规则：

在1.x之前的版本，遵循4位版本号，例如：0.8.2.2、0.9.0.1、0.10.0.0…
在1.x之后，kafka 全面启用了遵循 Major.Minor.Patch 的三位版本规则，其中Major表示大版本，通常是一些重大改变，因此彼此之间功能可能会不兼容；Minor表示小版本，通常是一些新功能的增加；最后Patch表示修订版，主要为修复一些重点Bug而发布的版本。例如：Kafka 2.1.1，大版本就是2，小版本是1，Patch版本为1，是为修复Bug发布的第1个版本。

官网下载：

官网下载地址：https://kafka.apache.org/downloads
打开官网，看到如下界面：
image.png
这里简单介绍一下，kafka_2.12中的2.12表示的scala的版本，因为Kafka服务器端代码完全由Scala语音编写。”-“后面的2.5.0表示的kafka的版本信息，遵循上面的命令规则。
注：Kafka新版客户端代码完全由Java语言编写，当然，不是Scala不行了，而是社区找来了一批Java程序员而已，而之前的Scala程序员隐退罢了。

kafka版本演进：

Kafka总共发布了7个大版本，分别是：0.7.x、0.8.x、0.9.x、0.10.x、0.11.x、1.x 及 2.x 版本。

0.8 版本：

0.8.0

增加了副本机制，至此Kafka成为了一个真正意义上完备的分布式高可靠消息队列解决方案；

0.8.2

  1. 引入了新版本Producer API：新版本Producer API有点不同，一是连接Kafka方式上，旧版本的生产者及消费者API连接的是Zookeeper，而新版本则连接的是Broker；二是新版Producer采用异步批量方式发送消息，比之前同步发送消息的性能有所提升。producer请求会返回一个应答对象，包括偏移量或者错误信。这种异步方地批量的发送消息到kafka broker节点，因而可以减少server端资源的开销。新的producer和所有的服务器网络通信都是异步地，在ack=-1模式下需要等待所有的replica副本完成复制时，可以大幅减少等待时间。 ```java //旧版本 Producerkafka.javaapi.producer.Producer

//新版本 Producerorg.apache.kafka.clients.producer.KafkaProducer

  2. 2. consumer 的消费偏移位置 offset 由原来的保存在 zookeeper 改为保存在 kafka 本身。对zookeeper而言，每次写操作代价是很昂贵的，而且zookeeper集群是不能扩展写能力的。在0.8.2开始，可以把comsumer提交的offset记录在compacted topic（__comsumer_offsets）中，该topic设置最高级别的持久化保证，即ack=-1。__consumer_offsets由一个三元组< comsumer group, topic, partiotion> 组成的key和offset值组成，在内存也维持一个最新的视图view，所以读取很快。kafka可以频繁的对offset做检查点checkpoint，即使每消费一条消息提交一次offset。
  3. 2. 在0.8.1中，已经实验性的加入这个功能，0.8.2中可以广泛使用。auto rebalancing的功能主要解决broker节点重启后，leader partition在broker节点上分布不均匀，比如会导致部分节点网卡流量过高，负载比其他节点高出很多。auto rebalancing主要配置如下：<br />controlled.shutdown.enable ，是否在在关闭broker时主动迁移leader partition。基本思想是每次kafka接收到关闭broker进程请求时，主动把leader partition迁移到其存活节点上，即follow replica提升为新的leader partition。如果没有开启这个参数，集群等到replica会话超时，controller节点才会重现选择新的leader partition，这些leader partition在这段时间内也不可读写。如果集群非常大或者partition 很多，partition不可用的时间将会比较长。
  4.    - 可以关闭unclean leader election，也就是不在ISR（IN-Sync Replica）列表中的replica，不会被提升为新的leader partition。unclean.leader.election=false时，kafka集群的持久化力大于可用性，如果ISR中没有其它的replica，会导致这个partition不能读写。
  5.    - 设置min.isr（默认值1）和 producer使用ack=-1，提高数据写入的持久性。当producer设置了ack=-1，如果broker发现ISR中的replica个数小于min.isr的值，broker将会拒绝producer的写入请求。max.connections.per.ip限制每个客户端ip发起的连接数，避免broker节点文件句柄被耗光。
  6. <a name="Nc0Dd"></a>
  7. ## **0.9 **版本：
  9. 1. 新版本Comsumer API<br />Kafka 0.9.0使用java重写了新版Consumer API，使用方式也是从连接Zookeeper切到了连接Broker，新的Comsumer API不再有high-level、low-level之分了，而是自己维护offset。这样做的好处是避免应用出现异常时，数据未消费成功，但Position已经提交，导致消息未消费的情况发生。Comsumer API有以下功能：
  10.    - Kafka可以自行维护Offset、消费者的Position。也可以开发者自己来维护Offset，实现相关的业务需求。
  11.    -  消费时，可以只消费指定的Partitions
  12.    - 可以使用外部存储记录Offset，如数据库之类的。
  13.    - 自行控制Consumer消费消息的位置。
  14.    - 可以使用多线程进行消费
  15. 2. 安全特性<br />在0.9之前，Kafka安全方面的考虑几乎为0，在进行外网传输时，只好通过Linux的防火墙、或其他网络安全方面进行配置。Kafka 0.9.0 在安全认证、授权管理、数据加密等方面都得到了支持，包括支持Kerberos等。
  16.    - 客户端连接borker使用SSL或SASL进行验证
  17.    - borker连接ZooKeeper进行权限管理
  18.    - 数据传输进行加密（需要考虑性能方面的影响）
  19.    - 客户端读、写操作可以进行授权管理
  20.    - 可以对外部的可插拔模块的进行授权管理
  22. 当然，安全配置方面是可选的，可以混合使用。如：做过安全配置的的borkers和没有进行安全配置的borkers放在同一集群，授权的客户端和没有授权的客户端，也可以在同一个集群等等。具体配置详见官方文档
  24. 3. Kafka Connect
  26. Kafka 0.9.0 引入了新的组件 Kafka Connect ，用于实现Kafka与其他外部系统之间的数据抽取。它可以和外部系统、数据集建立一个数据流的连接，实现数据的输入、输出。<br />官方文档中，也给出了例子。通过配置，往一个文本文件中输入数据，数据可以实时的传输到Topic中。在进行数据流或者批量传输时，是一个可选的解决方案。
  27. <a name="L9ngk"></a>
  28. ## **0.10 **版本：
  29. Kafka 0.10.0.0 引入了 Kafka Streams，使得Kafka不再仅是一个消息引擎，而是往一个分布式流处理平台方向发展。0.10 大版本包含两个小版本：0.10.1 和 0.10.2，它们的主要功能变更都是在 Kafka Streams 组件上。<br />值得一提的是，自 0.10.2.2 版本起，新版本 Consumer API 已经比较稳定了，而且新版本的 Producer API 的性能也得到了提升，因此对于使用 0.10.x 大版本的用户，建议使用或升级到 Kafka 0.10.2.2 版本。
  31. 1. Streams
  33. 如果你有这样的需求，从Kafka拉取数据进行流处理然后再推送回Kafka，那么你会喜欢0.10的Kafka Streams。Kafka Streams是一个类库，它实现了一系列流处理动作（例如join，filter，aggregate等），能够帮助你构建一个功能齐全的低延迟的流处理系统。它支持有状态或无状态的处理，并且能够被部署在各种框架和容器中（例如YARN，Mesos，Docker），也可以集成在Java应用里。
  35. 2. 机架感知
  37. 和Hadoop一样，Kafka现在也实现了机架感知。如果所有备份都在单个机架上，那么一旦这个机架出问题，那么所有的备份都将失效。现在Kafka会让备份分布在不同的机架上，显著的提高了可用性。
  39. 3. Message中加入Timestamp
  41. 在Message中加入了Timestamp，如果没有被用户声明，该字段会被自动设为被发送的时间。这使得Kafka Streams实现了基于时间事件的流处理，你也可以使用Timestamp来实现消息的追踪查找。除次之外Message中还加入了checksum（但并不是保存在Kafka中，只是取出来之后计算），可以以比较小的代价比对Message。
  43. 4. SASL增强
  45. Kafka0.9提供了SASL/Kerberos，在0.10中增加了更多的SASL功能，比如SASL/Plaintext
  47. 5. Kafka Connect Rest API
  49. 在之前的版本中，用户只能通过log来监控Connector的状态。在0.10中增加了监控和控制的API，可以列出所有的Connector状态，并且可以暂停或重启任务。
  51. 6. Kafka Consumer Max Record
  53. 在0.9中，如果想要控制Consumer的单次请求返回数据量，只能控制timeout的大小，0.10加入新的Consumer参数max.poll.records来控制返回的数据条数
  55. 7. 协议版本改进(Protocol Version Improvements)
  57. Kafka brokers现在支持返回所有支持的协议版本的请求API，这个特点的好处就是以后将允许一个客户端支持多个broker版本。
  58. <a name="bJ5dE"></a>
  59. ## 0.11 版本：
  60. Kafka0.11版本是一个里程碑式的大版本，特别是Kafka从这个版本开始支持“exactly-once”语义(下称EOS， exactly-once semantics)。
  62. 1. 支持EOS<br />0.11最重要的功能，没有之一！EOS是流式处理实现正确性的基石。主流的流式处理框架基本都支持EOS（如Storm Trident, Spark Streaming, Flink），Kafka streams肯定也要支持的。0.11版本通过3个大的改动支持EOS：1.幂等性producer；2. 支持事务；3. 支持EOS的流式处理(保证读-处理-写全链路的EOS)。
  63. 1.  修改unclean.leader.election.enabled默认值<br />Kafka社区终于下定决心要把这个参数的默认值改成false，即不再允许出现unclean leader选举的情况，在正确性和高可用性之间选择了前者。如果依然要启用它，用户需要显式地在server.properties中设置这个参数为true。
  64. 1. 确保offsets.topic.replication.factor参数被正确应用<br />__consumer_offsets这个topic是Kafka自动创建的，在创建的时候如果集群broker数<offsets.topic.replication.factor，原先的版本取其小者，但这会违背用户设置该参数的初衷。因此在0.11版本中这个参数会被强制遵守，如果不满足该参数设定的值，会抛出GROUP_COORDINATOR_NOT_AVAILABLE
  65. 1. 优化了对Snappy压缩的支持<br />之前由于源代码中硬编码了block size，使得producer使用Snappy时的表现比LZ4相差很多，但其实Snappy和LZ4两者之差距不应该很大。故此0.11版本中对Snappy的默认block size做了调整。不过这一点需要详尽的性能测试报告来证明此改动是有效的。
  66. 1. 消息增加头部信息(Header)<br />Record增加了Header，每个header是一个KV存储。具体的header设计参见KIP-82
  67. 1. 空消费者组延时rebalance<br />为了缩短多consumer首次rebalance的时间，增加了“group.initial.rebalance.delay.ms”用于设置group开启rebalance的延时时间。这段延时期间允许更多的consumer加入组，避免不必要的JoinGroup与SyncGroup之间的切换。当然凡事都是trade-off，引入这个必然带来消费延时。
  68. 1. 消息格式变更<br />增加最新的magic值：2。增加了header信息。同时为了支持幂等producer和EOS，增加一些与事务相关的字段，使得单个record数据结构体积增加。但因为优化了RecordBatch使得整个batch所占体积反而减少，进一步降低了网络IO开销。我们要特别注意Kafka不同版本间消息格式不兼容的问题。
  69. 1. 新的分配算法：StickyAssignor<br />比range和round-robin更加平衡的分配算法。指定partition.assignment.strategy = org.apache.kafka.clients.consumer.StickyAssignor可以尝尝鲜。不过根据我的经验，分配不均匀的情况通常发生在每个consumer订阅topic差别很大的时候。比如consumer1订阅topic1, topic2, topic4, consumer2订阅topic3, topic4这种情况。
  70. 1. controller重设计<br />Controller原来的设计非常复杂，使得社区里面的人几乎不敢改动controller代码。老版本controller的主要问题在我看来有2个：1.  controller需要执行1，2，3，4，5，6步操作，倘若第3步出错了，无法回滚前两步的操作；2. 多线程访问，多个线程同时访问Controller上下文信息。0.11版本部分重构了controller，采用了单线程+基于事件队列的方式。
  71. <a name="Ab0Rv"></a>
  72. ## 1.x 版本：
  73. Kafka 1.x 更多的是Kafka Streams方面的改进，以及Kafka Connect的改进与功能完善等。但仍有两个重要特性：
  75. 1. Kafka 1.0.0实现了磁盘的故障转移，当Broker的某一块磁盘损坏时数据会自动转移到其他正常的磁盘上，Broker还会正常工作，这在之前版本中则会直接导致Broker宕机，因此Kafka的可用性与可靠性得到了提升；
  76. 1. Kafka 1.1.0开始支持副本跨路径迁移，分区副本可以在同一Broker不同磁盘目录间进行移动，这对于磁盘的负载均衡非常有意义。
  77. <a name="yL1i0"></a>
  78. ## 2.x 版本：
  79. Kafka 2.x 更多的也是Kafka Streams、Connect方面的性能提升与功能完善，以及安全方面的增强等。一个使用特性，Kafka 2.1.0开始支持ZStandard的压缩方式，提升了消息的压缩比，显著减少了磁盘空间与网络io消耗。
  80. <a name="atQXg"></a>
  81. ## 关于客户端版本：
  82. kafka 支持多个语言的客户端api，maven 的工程我们一般这样引入 kafka 客户端。
  83. ```xml
  84. <dependency>
  85.   <groupId>org.apache.kafka</groupId>
  86.   <artifactId>kafka_2.11</artifactId>
  87.   <version>0.10.2.0</version>
  88. </dependency>

这种会引入两个依赖jar，分别是

  • kafka-clients-0.10.2.0.jar
  • kafka_2.11-0.10.2.0.jar

前者是官方推荐的java客户端，后者是scala客户端。调用方式有所不同。如果确定不使用 scala api，也可以用下面这种方式只包含java版本的客户端。

  1. <dependency>
  2.     <groupId>org.apache.kafka</groupId>
  3.     <artifactId>kafka-clients</artifactId>
  4.     <version>0.10.2.0</version>
  5. </dependency>

最后，给出一些建议：

  • 遵循一个基本原则，Kafka客户端版本和服务端版本应该保持一致，否则可能会遇到一些问题。
  • 根据是否用到了Kafka的一些新特性来选择，假如要用到Kafka生产端的消息幂等性，那么建议选择Kafka 0.11 或之后的版本。
  • 选择一个自己熟悉且稳定的版本，如果说没有比较熟悉的版本，建议选择一个较新且稳定、使用比较广泛的版本。

参考：

https://blog.csdn.net/liuxiao723846/article/details/106020738 https://www.cnblogs.com/cssdongl/p/6185997.html