Kafka0.8.2-1.0新特性

安全性：--0.9引入

kafka集群提高了安全性，目前支持以下的安全措施

broker使用SSL或SASL(Kerberos)，验证客户端（生产者或消费者）、其他broker或工具的连接。支持以下的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版本开始

从broker连接到Zookeeper的身份验证。
broker和client之间的数据传输，broker之间，或使用SSL的broker和工具之间的数据加密
client的read/write操作验证。
验证是插拔的，支持外部认证服务集成。

Kafka Connect：--0.9引入

Kafka Connect 是一个可扩展、可靠的在Kafka和其他系统之间流传输的数据工具。
两个核心概念：
　　Source和Sink。 Source负责导入数据到Kafka，Sink负责从Kafka导出数据

配额：--0.9引入

Kafka集群能够对生产和消费设置配额。为每个客户端分组设置配额阈值（基于字节比率）。

Kafka集群有能力对请求进行配额来控制客户端使用的broker资源。可以为共享配额的每个客户组执行两种类型的客户配额：

通过配额定义网络带宽的字节率阈值（从0.9版本开始）
请求率配额将CPU的利用率阈值定义为网络和I/O线程的百分比（自0.11版本起）

Kafka Streams：--0.10引入

Kafka Streams是一个客户端程序库，用于处理和分析存储在Kafka中的数据，并将得到的数据写回Kafka或发送到外部系统。Kafka Stream基于一个重要的流处理概念。如正确的区分事件时间和处理时间，窗口支持，以及简单而有效的应用程序状态管理。

机架感知：--0.10引入

和Hadoop一样，Kafka现在也实现了机架感知。如果所有备份都在单个机架上，那么一旦这个机架出问题，那么所有的备份都将失效。现在Kafka会让备份分布在不同的机架上，显著的提高了可用性。

Message中加入Timestamp：--0.10引入

在Message中加入了Timestamp，如果没有被用户声明，该字段会被自动设为被发送的时间。这使得Kafka Streams实现了基于时间事件的流处理，你也可以使用Timestamp来实现消息的追踪查找。除次之外Message中还加入了checksum（但并不是保存在Kafka中，只是取出来之后计算），可以以比较小的代价比对Message。

协议版本改进：--0.10引入

Kafka brokers支持返回所有支持的协议版本的请求API，这个特点的好处就是以后将允许一个客户端支持多个broker版本。在Kafka 0.10.2.0之前，Kafka服务器端和客户端版本之间的兼容性是“单向”的，即高版本的broker可以处理低版本client的请求。反过来，低版本的broker不能处理高版本client的请求。

可以运行命令先查看当前broker支持的协议版本，然后再选择broker支持的最高版本封装请求即可。命令格式如下(在client端运行该命令)：

bin/kafka-broker-api-version.sh --bootstrap-server localhost:9092

下面两张图分别表示查看0.10.2.0和0.10.0.1的broker所支持各协议的版本范围，注意我标红了FETCH请求以示区别：

image

image.png

空消费者组延时rebalance：--0.11引入

为了缩短多consumer首次rebalance的时间，增加了“group.initial.rebalance.delay.ms”用于设置group开启rebalance的延时时间。这段延时期间允许更多的consumer加入组，避免不必要的JoinGroup与SyncGroup之间的切换。当然凡事都是trade-off，引入这个必然带来消费延时。

消息格式变更：--0.11引入

增加最新的magic值：增加了header信息。同时为了支持幂等producer和EOS，增加一些与事务相关的字段，使得单个record数据结构体积增加。但因为优化了RecordBatch使得整个batch所占体积反而减少，进一步降低了网络IO开销。

新的分配算法：StickyAssignor：--0.11引入

比range和round-robin更加平衡的分配算法。指定partition.assignment.strategy= org.apache.kafka.clients.consumer.StickyAssignor可以尝尝鲜。不过根据我的经验，分配不均匀的情况通常发生在每个consumer订阅topic差别很大的时候。比如consumer1订阅topic1, topic2, topic4, consumer2订阅topic3, topic4这种情况

controller重设计：--0.11引入

Controller原来的设计非常复杂，使得社区里面的人几乎不敢改动controller代码。老版本controller的主要问题在我看来有2个：1. controller需要执行1，2，3，4，5，6步操作，倘若第3步出错了，无法回滚前两步的操作;2. 多线程访问，多个线程同时访问Controller上下文信息。0.11版本部分重构了controller，采用了单线程+基于事件队列的方式。具体效果咱们拭目以待吧~~

支持EOS：--0.11引入

EOS是流式处理实现正确性的基石。主流的流式处理框架基本都支持EOS(如Storm Trident, Spark Streaming, Flink)，Kafka streams肯定也要支持的。0.11版本通过3个大的改动支持EOS：1.幂等的producer(这也是千呼万唤始出来的功能);2. 支持事务;3. 支持EOS的流式处理(保证读-处理-写全链路的EOS)

新增了用于查看运行时活跃任务的 API（KIP-130）：--1.0引入

https://cwiki.apache.org/confluence/display/KAFKA/KIP+130%3A+Expose+states+of+active+tasks+to+KafkaStreams+public+API

用于聚合分区的 cogroup API（KIP-150）：--1.0引入

https://cwiki.apache.org/confluence/display/KAFKA/KIP-150+-+Kafka-Streams+Cogroup

新增了大量用于健康监测的度量指标（KIP-188）：--1.0引入

https://cwiki.apache.org/confluence/display/KAFKA/KIP-188+-+Add+new+metrics+to+support+health+checks

提供了集群的 GloabalTopicCount 和 GlobalPartitionCount 度量指标（KIP-168）：--1.0引入

https://cwiki.apache.org/confluence/display/KAFKA/KIP-168%3A+Add+GlobalTopicCount+and+GlobalPartitionCount+metrics+per+cluster

支持 Java 9

磁盘容错（KIP-112）：--1.0引入

更优雅地处理磁盘错误，单个 JBOD 上的磁盘错误不会导致整个集群崩溃
https://cwiki.apache.org/confluence/display/KAFKA/KIP-112%3A+Handle+disk+failure+for+JBOD