Kafka2.0.0发布信息可参考https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=80448820
1.发布时间
KIP Freeze时间：2018年5月22日
Feature Freeze时间：2018年5月29日
Code Freeze时间：2018年6月12日
Release时间：2018年6月26日
2.版本需求
Kafka2.0.0版本对以下40个特性进行了开发。
KIP-86: Configurable SASL callback handlers
KIP-118: Drop Support for Java 7
KIP-174 - Deprecate and remove internal converter configs in WorkerConfig
KIP-176: Remove deprecated new-consumer option for tools
KIP-186: Increase offsets retention default to 7 days
KIP-219 - Improve quota communication
KIP-222 - Add Consumer Group operations to Admin API
KIP-223 - Add per-topic min lead and per-partition lead metrics to KafkaConsumer
加入消费者客户端的领先指标
在此前， Kafka 消费者客户端已经加入了对每一个消费分区的延迟指标（lag metrics），定义为当前消费者在分区上的位置与分区末端（log-end-offset）的距离。当此指标变大时，代表消费者逐渐跟不上发布的速度，需要扩容。我们发现，当分区 renteion 时间很短而导致消费者跌出可消费范围时（out-of-range），此指标不能完全针对潜在的危险为用户报警。
因此在即将发布的 2.0 版本中，我们加入了另一个“领先”指标（lead metrics），定义为分区首端（log-start-offset）与消费者在分区上的位置距离，当此指标趋近于零时，代表消费者有跌出可消费范围因而丢失数据的危险。值得称赞的是，这个新特性是由国内的社区贡献者完成的。
KIP-237: More Controller Health Metrics
加入更多 Kafka 控制器的健康指标
在完成了针对增强 Kafka 控制器性能的全面重设计之后，我们认为现在 Kafka 已经可以支持千台机器，百万分区级别的集群。在此之前，这样规模集群的一个阻碍就是 Kafka 控制器本身处理各种 admin 请求，诸如主本迁移、话题扩容、增加副本等等时的时间消耗。在完成了这个重设计之后，我们也相应地加入了更多和新设计相关的健康指标，包括控制器内部请求队列的长度，请求处理速率等等。
KIP-244: Add Record Header support to Kafka Streams Processor API
KIP-245: Use Properties instead of StreamsConfig in KafkaStreams constructor
KIP-249: Add Delegation Token Operations to KafkaAdminClient
KIP-251: Allow timestamp manipulation in Processor API
KIP-255 OAuth Authentication via SASL/OAUTHBEARER
更全面的数据安全支持
KIP-255 里面添加了一个框架，我们可以使用OAuth2 bearer tokens 来对访问 Kafka Brokers 进行权限控制。
最后，也是最近一段时间被讨论最多的，就是数据安全的重要性：在云计算大行其道的今天，多租户方案已成为潮流。而许多数据保护条例的实施，比如 GDPR，更是让“保证数据不泄漏”成为一个标准流数据平台的基本要求。这项要求包括从写入，到处理，到导出的一些系列措施，包括认证、访问控制及授权、端到端加密等等。
举个例子，如果一个 Kafka 集群可以被一个企业里面的多个部门所共享，如何控制哪些部门可以读取或写入哪些主题、哪些部门可以创建或删除哪些主题、谁可以看见别人创建的主题、以及与 Kafka 相关的其他服务和客户端，比如应该如何保护Zookeeper、谁可以直接读写、哪些 Kafka Streams 或者 Kafka Connect 应用程序可以发起哪些管理请求等，都需要提供足够的控制手段。
KIP-257 - Configurable Quota Management
KIP-261: Add Single Value Fetch in Window Stores
KIP-265: Make Windowed Serde to public APIs
KIP-266: Fix consumer indefinite blocking behavior
KIP-267: Add Processor Unit Test Support to Kafka Streams Test Utils
KIP-268: Simplify Kafka Streams Rebalance Metadata Upgrade
简化了 Kafka Streams 升级过程
Kafka Streams 利用 Consumer Rebalance 协议里面的元数据字符串编码诸如任务分配、全局查询、版本升级相关的信息。然而，当编码版本本身改变的时候，就需要进行离线升级。比如之前从 0.10.0 版本像更高级的版本升级的时候，用户就需要将所有的 Streams 程序下线，换上新的 Kafka 版本号，然后在全部重启。
KIP-268 利用 version prob 可以使得旧版本的任务分配者告知其他高版本的成员暂时使用旧版本的 Rebalance 元数据编码，这样就可以让用户依然能够通过 rolling bounce 在线升级 Kafka Streams 的版本。而当所有参与的成员全部升级完毕之后，最后一次 rebalance 会自动切换回新版本的元数据编码。
KIP-270 - A Scala Wrapper Library for Kafka Streams
KIP-272: Add API version tag to broker's RequestsPerSec metric
进一步加强了 Kafka 的可见性
KIP-274: Kafka Streams Skipped Records Metrics
KIP-276 Add StreamsConfig prefix for different consumers
KIP-277 - Fine Grained ACL for CreateTopics API
KIP-278 - Add version option to Kafka's commands
KIP-279: Fix log divergence between leader and follower after fast leader fail over
修补多次 Kafka 分区主本迁移时的日志分歧问题
在升级 Kafka 版本或者做定期系统维护的时候，用户往往需要进行连续的多次 Kafka 分区迁移。在这次发布中我们修补了一个在此过程中可能会出现的一个会导致日志分歧发生的边缘情况。具体方案就是将此前版本中已经加入的主本 epoch 信息扩散到 OffsetForLeaderEpochResponse。如此所有主副本就可以清晰知道自己到底处于当前分区备份的哪一个阶段，从而杜绝因为消息不对等而可能导致的日志分歧。
KIP-281: ConsumerPerformance: Increase Polling Loop Timeout and Make It Reachable by the End User
KIP-282: Add the listener name to the authentication context
现在，我们可以在不重启 Broker 的情况下动态更新 SSL 信任库（ SSL truststores）。我们还可以在启动 Broker 之前在 ZooKeeper 中为 Broker 侦听器（broker listeners）配置安全性，包括 SSL 密钥库和信任库密码以及 SASL的JAAS配置。 使用此新功能，您可以在 ZooKeeper 中以加密形式存储敏感密码配置，而不是在 Broker 属性文件中以明文形式存储。
KIP-283: Efficient Memory Usage for Down-Conversion
降低信息格式向下转换时的内存消耗
在一个多客户端组群的环境下，客户端与服务器端的版本不匹配是常见现象。早在 0.10.0 版本中，Kafka 已经加入了允许不同版本客户端与服务器交互的功能，即高版本的 Kafka 客户端依然可以与低版本的服务器进行数据传导，反之亦然。然而当低版本的消费者客户端和高版本的服务器进行交互时，服务器有时需要将数据向下转换（format down-conversion）成为低版本客户端可以认知的格式后才能发回给消费者。向下转换有两个缺点：
丢失了 Kafka 数据零拷贝（zero-copy）的性能优势；
向下转换需要额外的大量内存，在极端情况下甚至会导致内存溢出。
前者无法避免，但是后者依然可以改进：在即将发布的 2.0 版本中，我们使用了一种新的基于分块（chunking）的向下转换算法，使得需要同时占据的内存需求大幅缩减。这使得高低版本的客户端与服务器之间的交互变得更加有效。
KIP-284: Set default retention ms for Streams repartition topics to Long.MAX_VALUE
KIP-285: Connect Rest Extension Plugin
KIP-290: Support for Prefixed ACLs
增加了前缀通配符访问控制(ACL)的支持，这样我们可以更加细粒度的进行访问控制。
在 2.0 以前，很多 Kafka 自身的访问控制（access control list）机制还是粗粒度的。比如对“创建话题”这一访问方式的控制，只有“全集群”这一种范围。也就是说，对于任何一个用户来说，我们只能或者给予其在一个集群内创建任何话题的权限——比如说，这个 Kafka 集群的运维或者可靠性工程团队（Devops or SRE），或者不给予任何话题的创建权限。但是在一个多租户环境下，我们很可能会出现需要更细粒度的控制机制。比如一个 Kafka Streams 客户端，除了读取给予的源话题之外，还需要实时创建一下内部用于 data shuffling 和 change logging 的话题，但是给予其一个“全集群”的话题创建权限又太危险。
因而在 2.0 版本中，我们进一步细粒度化了很多权限，比如 KIP-290 就加入了前缀通配符（prefix wildcard）的范围，而 KIP-227 就将这种范围加入到了单个或多个话题创建的权限中。在这个机制下，用户可以被赋予单独一个话题基于其话题名的创建权限（literal topic），也可以被赋予多个话题基于其话题名前缀匹配的创建权限，比如可以创建所有名字开头为“team1-”的话题，等等。
KIP-292: Add transformValues() method to KTable
KIP-294 - Enable TLS hostname verification by default
现在，SSL连接默认启用主机名验证（Host name verification），以确保默认 SSL 配置不受中间人攻击的影响。 如果需要，您可以禁用此验证。
KIP-295: Add Streams Configuration Allowing for Optional Topology Optimization
KIP-297: Externalizing Secrets for Connect Configurations
KIP-298: Error Handling in Connect
KIP-303: Add Dynamic Routing in Streams Sink
KIP-305: Add Connect primitive number converters