kafka概述 01 0.10之后的kafka版本有哪些有意思的feature？【kafka技术图谱 1/50】
kafka概述 01 0.10之后的kafka版本有哪些有意思的feature？【kafka技术图谱 1/50】
kafka概述 01 0.10之后的kafka版本有哪些有意思的feature？【kafka技术图谱 1/50】
# **kafka release reviews: what happen from kafka 0.10 to 2.6*
此篇是笔者整理了下 kafka0.10版本之后的kafka版本有哪些有意思的特性。
kafka已经发展了很多年了，kafka0.8版本对 Zookeeper有着很大的依赖，在0.10版本kafka消息队列的基本功能，基本架构，以及被确定，并一直沿用至今 【2.6】
在这篇文章里，我整理了下0.10 - 2.6版本的 commit信息，看下有哪些有意思的特性
重点关注服务自身的性能特性 kafka connect, stream部分也有很多feature 但是我不太感兴趣，直接跳过了， 如果有遗漏的，欢迎留言讨论
【大数据事务所】专注大数据知识领域，深耕大数据平台中的各种技术。
目前笔者在一线互联网公司中，从事数据平台相关建设工作。
概述- 简短版文章
整理了本文的核心内容，可以只读这一部分，后续的全文因为信息杂乱，可能阅读体验不佳
Kafka1.0.0版本
加大了对JBOD磁盘的支持，可以继续思考，以及kafka是否有必要使用RAID？
以及权衡RAID vs JBOD在生产环境的特性，另外在v1.1.0的KIP-113添加了对日志目录之间副本移动的支持，以实现与JBOD的数据平衡。
Kafka2.0.0版本
增加了对connect异常处理的优化，Connect允许用户配置在处理记录的所有阶段中如何处理故障，诸如某些外部组件不可用之类的某些故障可以通过简单地重试来解决，而其他错误应被记录下来，而问题记录将被跳过，并提供死信topic，我们将在转换或转换步骤中失败的原始记录 写入可配置的Kafka topic，
如何高效的完成不同版本之间的数据转换
2.0.0中优化了这么一个场景：在一个多客户端组群的环境下，客户端与服务器端的版本不匹配是常见现象，如何高效的完成不同版本之间的数据转换？
早在 0.10.0 版本中，Kafka 已经加入了允许不同版本客户端与服务器交互的功能，即高版本的 Kafka 客户端依然可以与低版本的服务器进行数据传导，反之亦然。然而当低版本的消费者客户端和高版本的服务器进行交互时，服务器有时需要将数据向下转换（format down-conversion）成为低版本客户端可以认知的格式后才能发回给消费者。
数据格式向下转换有两个缺点：
- 丢失了 Kafka 数据零拷贝（zero-copy）的性能优势；
- 向下转换需要额外的大量内存，在极端情况下甚至会导致内存溢出。
- 前者无法避免，但是后者依然可以改进：在即将发布的 2.0 版本中，我们使用了一种新的基于分块（chunking）的向下转换算法，使得需要同时占据的内存需求大幅缩减。这使得高低版本的客户端与服务器之间的交互变得更加有效。
KIP-223：加入消费者客户端的领先指标
2.0.0中的另一个优化 KIP-223：加入消费者客户端的领先指标
【用来检测出可能会造成丢数据的重要延迟】
在此前， Kafka 消费者客户端已经加入了对每一个消费分区的延迟指标（lag metrics），定义为当前消费者在分区上的位置与分区末端（log-end-offset）的距离。
当此指标变大时，代表消费者逐渐跟不上发布的速度，需要扩容。
我们发现，当分区 renteion 时间很短而导致消费者跌出可消费范围时（out-of-range），此指标不能完全针对潜在的危险为用户报警。
因此在即将发布的 2.0 版本中，我们加入了另一个“领先”指标（lead metrics），定义为分区首端（log-start-offset）与消费者在分区上的位置距离，当此指标趋近于零时，代表消费者有跌出可消费范围因而丢失数据的危险。
Kafka 2.3.0版本
Kafka Connect 支持 incremental cooperative rebalancing.
在有任务加入kafka connect集群后，可能会造成整个集群的rebalance情况
Kafka 2.4.0版本
2.4.0 consumer也支持incremental cooperative rebalancing. 这
可以改善kafka的rebalance问题 cooperative协议将一次全局重平衡，改成每次小规模重平衡，直至最终收敛平衡的过程。避免大规模全局rebalance，运维过大规模kafka的人知道，这个情况多么的讨厌。
黏性分区策略（Sticky Partitioning Strategy）
这个版本还实现了黏性分区策略（Sticky Partitioning Strategy）来实现生产者发送数据分区优化。
kafka producer发送数据并不是一个一个消息发送，而是取决于两个producer端参数。一个是`linger.ms`，默认是0ms，当达到这个时间后，kafka producer就会立刻向broker发送数据。另一个参数是`batch.size`，默认是16kb，当产生的消息数达到这个大小后，就会立即向broker发送数据。
按照这个设计，从直观上思考，肯定是希望每次都尽可能填满一个batch再发送到一个分区。
但实际决定batch如何形成的一个因素是分区策略（partitioner strategy）。
在Kafka2.4版本之前，在producer发送数据默认的分区策略是轮询策略（没指定keyd的情况。如果多条消息不是被发送到相同的分区，它们就不能被放入到一个batch中。
所以如果使用默认的轮询partition策略，可能会造成一个大的batch被轮询成多个小的batch的情况。鉴于此，kafka2.4的时候推出一种新的分区策略，即Sticky Partitioning Strategy，Sticky Partitioning Strategy会随机地选择另一个分区并会尽可能地坚持使用该分区——即所谓的粘住这个分区。
鉴于小batch可能导致延时增加，之前对于无Key消息的分区策略效率很低。社区于2.4版本引入了黏性分区策略（Sticky Partitioning Strategy）。该策略是一种全新的策略，能够显著地降低给消息指定分区过程中的延时。 使用Sticky Partitioner有助于改进消息批处理，减少延迟，并减少broker的负载。
2.4.0的另一个新功能:static membership功能
成员加入或成员离组是最常见的触发重平衡的情况。
新成员加入这个场景必然发生重平衡，没办法优化（针对初始化多个消费者的情况有其他优化，即延迟进行重平衡），但消费者崩溃离组却可以优化。
因为一个消费者崩溃离组通常不会影响到其他{partition - consumer}的分配情况。 因此在 kafka 2.3~2.4 推出一项优化，即此次介绍的
[Static Membership](https://link.zhihu.com/?target=https%3A//kafka.apache.org/26/documentation/%23static_membership)功能和一个consumer端的配置参数`group.instance.id`。
一旦配置了该参数，成员将自动成为静态成员，否则的话和以前一样依然被视为是动态成员。
静态成员的好处在于，其静态成员ID值是不变的，因此之前分配给该成员的所有分区也是不变的。
即假设一个成员挂掉，在没有超时前静态成员重启回来是不会触发Rebalance的**（超时时间为`session.timeout.ms`，默认10 sec）。
在静态成员挂掉这段时间，broker会一直为该消费者保存状态（offset），直到超时或静态成员重新连接。
2.4.0 允许使用者从最近的副本（非leader）中获取。
kafka能够从follower副本读数据了,这个功能并不是为了提供读取性能
在早先kafka的设计中，为了使consumer读取数据能够保持一致，是只允许consumer读取leader副本的数据的。
即follower replica只是单纯地备份数据的作用。
那推出follower replica fetch功能的背景是什么呢？ 举个比较常见的场景，kafka存在多个数据中心，不同数据中心存在于不同的机房，当其中一个数据中心需要向另一个数据中心同步数据的时候，由于只能从leader replica消费数据，那么它不得不进行跨机房获取数据，而这些流量带宽通常是比较昂贵的（尤其是云服务器）。即无法利用本地性来减少昂贵的跨机房流量。 所以kafka推出这一个功能，就是帮助类似这种场景，节约流量资源。这种功能还可以和新推出的mirror maker2相互配合，实现多个数据源的数据同步。
正文Kafka - Version 0.11.0.0版本
17年6月发布kafka 0.11版本，
- - [[KAFKA-3487](https://issues.apache.org/jira/browse/KAFKA-3487)] - KIP-146: Support per-connector/per-task classloaders in Connect 在Connect中支持每个连接器/每个任务的类加载器
- - [[KAFKA-4208](https://issues.apache.org/jira/browse/KAFKA-4208)] - Add Record Headers
- - [[KAFKA-4586](https://issues.apache.org/jira/browse/KAFKA-4586)] - Add purgeDataBefore() API in AdminClient
提供deleteRecordsBefore接口，主动删除kafka topic数据
从流处理作业生成的中间数据量会占用Kafka中的大量磁盘空间。重要的是我们必须在下游应用程序使用完这些数据后立即删除这些数据，否则我们必须为购买kafka集群的磁盘购买大量磁盘以保留这些数据。
但是，Kafka没有提供任何机制来删除下游作业使用的数据。它仅提供基于时间和基于大小的日志保留策略，这两种方法都与消费者的行为无关。如果我们为中间数据设置小的基于时间的日志保留，则即使在下游作业使用数据之前，也可能会删除该数据。如果设置基于时间的大型日志保留，则数据将长时间占用大量磁盘空间。这两种解决方案都不适合Kafka用户。
为了解决此问题，我们建议添加一个新的admin API，用户可以调用该API删除不再需要的数据。 用户应用程序确定每个分区可以删除的数据的最大偏移量。该信息以 `deleteRecordsBefore()` Map
[[KAFKA-4743](https://issues.apache.org/jira/browse/KAFKA-4743)]
- Add a tool to Reset Consumer Group Offsets kafka-consumer-groups.sh 提供了可以把offset设置到指定位置。
[[KAFKA-4923](https://issues.apache.org/jira/browse/KAFKA-4923)] - Add Exactly-Once Semantics to Streams 开始支持精确一次语意 【！！！！！！！！！】
正文Kafka - Version 1.0.0版本
支持Java 9，从而使TLS和CRC32C的实现大大加快。在线加密现在将更快，启用加密后计算成本会降低。
针对Streams API做出很多优化的大版本
Kafka更好的支持JBOD存储配置。从历史上看，不建议使用JBOD存储配置，但是该体系结构一直很诱人：毕竟，为什么不依靠Kafka自己的复制机制来防止存储故障而不是使用RAID？
使用KIP-112，Kafka现在可以更优雅地处理磁盘故障。JBOD代理中的单个磁盘故障不会使整个代理崩溃。相反，代理将继续提供功能磁盘上保留的所有日志文件。** **JBOD（just a bunch of disks，简单磁盘，或有时称简单驱动捆绑）是一个不太正规的术语，官方术语称作“Spanning”，它用来指还没有根据RAID（独立磁盘冗余阵列）系统配置以增加容错率和改进数据访问性能的电脑硬盘。**
[[KAFKA-4602](https://issues.apache.org/jira/browse/KAFKA-4602)] - KIP-72 Allow putting a bound on memory consumed by Incoming requests
引入了一个新的服务器配置参数，**`queued.max.request.bytes`**它将指定对可以保存在内存中的请求数量的限制。此配置参数将与现有参数共存**`queued.max.requests`**（代码将同时遵守两个界限，并且在任何一个被点击时都不会接收新的请求）。 LinkedIn上发生了几次-Hadoop作业中非常大的请求批次（每个请求1000个请求）突然激增，导致生产集群上的OOM异常。 -
正文Kafka - Version 1.1.0 版本
Kafka 1.1.0包含许多重要的新功能。以下是一些重要更改的摘要：
- Kafka 1.1.0包括对Kafka Controller的重大改进，可加快受控关机的速度。
- ZooKeeper会话过期边缘的情况也已作为此工作的一部分进行了修复。
- 控制器的改进还使单个群集上可以支持更多分区。
KIP-227引入了增量提取请求，当分区数量很大时，可以提供更有效的复制。
KIP-113添加了对日志目录之间副本移动的支持，以实现与JBOD的数据平衡*。
- Kafka Connect已添加了几个新功能，包括标头支持（KIP-145），Connect REST接口中的SSL和Kafka群集标识符（KIP-208和KIP-238），连接器名称验证（KIP-212）和支持用于接收器连接器（KIP-215）中的主题正则表达式。此外，Connect worker的默认最大堆大小已增加到2GB。
Kafka Streams API已添加了一些改进，包括减少重新分区主题分区的占用空间，针对生产失败的可自定义错误处理以及增强的对代理不可用性的恢复能力。有关详细信息，请参见KIP 205、210、220、224和239。
正文Kafka - Version 2.0.0版本
- KIP-290添加了对前缀ACL的支持，从而简化了大型安全部署中的访问控制管理。现在可以使用单个规则来授予对主题，消费者组或带有前缀的交易ID的批量访问权限。用于主题创建的访问控制也已得到改进，以允许授予访问权限以创建特定主题或带有前缀的主题。
- KIP-255添加了用于使用OAuth2承载令牌向Kafka代理进行身份验证的框架。SASL / OAUTHBEARER实现可使用回调进行自定义，以进行令牌检索和验证。
- 现在默认情况下为SSL连接启用了主机名验证，以确保默认的SSL配置不受中间人攻击。您可以根据需要禁用此验证。
- 现在，您可以动态更新SSL信任库，而无需重新启动代理。您还可以在启动代理之前在ZooKeeper中为代理侦听器配置安全性，包括SSL密钥库和信任库密码以及SASL的JAAS配置。使用此新功能，您可以将加密的敏感密码配置以加密形式存储在ZooKeeper中，而不是以明文形式存储在代理属性文件中。
复制协议改进
复制协议已得到改进，可避免在快速领导者故障转移期间领导者与跟随者之间的日志分歧。通过减少消息下转换的内存占用，我们还提高了代理的弹性。通过使用消息分块，减少了内存使用和内存引用时间，以避免代理中的OutOfMemory错误。 https://issues.apache.org/jira/browse/KAFKA-6361
- 启用配额后，在应用任何限制之前，现在会通知Kafka客户端限制。当超出配额时，这使客户端可以区分网络错误和较大的限制时间。
- 我们为Kafka使用者添加了一个配置选项，以避免在使用者中无限期地阻塞。 - 我们放弃了对Java 7的支持，并删除了先前不推荐使用的Scala生产者和使用者。
Kafka Connect包括许多改进和功能
*https://cwiki.apache.org/confluence/display/KAFKA/KIP-298%3A+Error+Handling+in+Connect - Connect中有多个位置可能会发生故障。在Kafka Connect中反序列化，转换，处理或读取记录的任何失败都可能导致任务失败。
尽管可以使用检查格式错误的数据的转换或自定义转换器来解决某些错误，但通常很难确保正确和有效的数据或告诉Connect跳过有问题的记录。
Connect应该允许用户配置在处理记录的所有阶段中如何处理故障。某些故障，例如缺少某些外部组件的可用性，可以通过重试来解决，而应该记录其他错误，而跳过问题记录。在可能的情况下，Connect应该能够记录错误，并可以选择包括问题记录和连接器，转换和转换器的配置状态。由于没有一个单一的解决方案适用于所有人，因此所有这些错误处理行为都应该是可配置的。
该提案旨在更改Connect框架，以使其在处理Connector中的记录时能够自动处理错误。默认情况下，连接将在发生错误时立即失败，这是以前的连接行为。因此，必须明确启用所有新行为。
[[KAFKA-6576](https://issues.apache.org/jira/browse/KAFKA-6576)] - Configurable Quota Management (KIP-257) Kafka broker支持配额，这些配额强制限定执行速率，以防止客户端使网络饱和或垄断broker资源。`Fetch`/`Produce`配额可以配置为限制网络带宽使用，`Request`配额可以配置为限制CPU使用（网络和I / O线程时间）。
正文Kafka - Version 2.0.0 版本
- KIP-295 Add Streams Config for Optional Optimization ## KIP-283：降低信息格式向下转换时的内存消耗
在一个多客户端组群的环境下，客户端与服务器端的版本不匹配是常见现象。早在 0.10.0 版本中，Kafka 已经加入了允许不同版本客户端与服务器交互的功能，即高版本的 Kafka 客户端依然可以与低版本的服务器进行数据传导，反之亦然。然而当低版本的消费者客户端和高版本的服务器进行交互时，服务器有时需要将数据向下转换（format down-conversion）成为低版本客户端可以认知的格式后才能发回给消费者。
向下转换有两个缺点： 1. 丢失了 Kafka 数据零拷贝（zero-copy）的性能优势； 2. 向下转换需要额外的大量内存，在极端情况下甚至会导致内存溢出。 前者无法避免，但是后者依然可以改进：
在即将发布的 2.0 版本中，我们使用了一种新的基于分块（chunking）的向下转换算法，使得需要同时占据的内存需求大幅缩减。这使得高低版本的客户端与服务器之间的交互变得更加有效。
## KIP-223：加入消费者客户端的领先指标 在此前， Kafka 消费者客户端已经加入了对每一个消费分区的延迟指标（lag metrics），定义为当前消费者在分区上的位置与分区末端（log-end-offset）的距离。当此指标变大时，代表消费者逐渐跟不上发布的速度，需要扩容。我们发现，当分区 renteion 时间很短而导致消费者跌出可消费范围时（out-of-range），此指标不能完全针对潜在的危险为用户报警。 因此在即将发布的 2.0 版本中，我们加入了另一个“领先”指标（lead metrics），定义为分区首端（log-start-offset）与消费者在分区上的位置距离，当此指标趋近于零时，代表消费者有跌出可消费范围因而丢失数据的危险。
正文Kafka - Version 2.1.0 版本
[[KAFKA-7027](https://issues.apache.org/jira/browse/KAFKA-7027)] - Overloaded StreamsBuilder Build Method to Accept java.util.Properties 考虑到拓扑优化，用户调用StreamsBuilder.build（）方法，我们不再立即构建物理计划，而是返回一个拓扑实例 在Kafka Streams进行StreamsBuilder.build（）调用期间制定和优化拓扑的物理计划
Kafka 2.1.0包含许多重要的新功能。以下是一些重要更改的摘要：
- Java 11支持 - 支持Zstandard，可实现与gzip相当的压缩，具有更高的压缩率，尤其是解压缩速度（KIP-110）
避免使活动的消费者组（KIP-211）的承诺偏移量过期
如果活动的使用者为主题分区提交了偏移量以来已经过了相应的保留期或更长时间，则将从使用者组元数据中删除该已提交的偏移量。
如果这样，则会出现重新平衡，或者使用方重新启动，将找不到该主题分区的最后提交的偏移量，并且使用方被迫从日志的开头或结尾开始（取决于`auto.offset.reset` 配置的值），从而导致潜在的重复消耗或丢失记录
关`OffsetCommit` 协议不同版本当前偏移到期如何工作的概述
- 版本0：偏移量存储在ZooKeeper中。基于ZooKeeper的偏移量存储不在此KIP范围内
- 版本1：一个可选的提交时间戳与请求中的每个主题分区相关联。将代理的代理`offsets.retention.minutes`添加到提交时间戳，以确定分区的到期时间戳。在这种情况下，客户端无法覆盖代理强制执行的默认保留。
- 第2版，第3版：与第1版类似，不同之处在于每个分区没有明确的提交时间戳。`retention_time` 请求中的字段将替换代理的偏移量保留配置值，以计算过期时间戳。 - 对于版本1-3，一旦达到到期时间戳记，则无论组状态如何，都会从偏移缓存中删除偏移（在下一次清理期间）。
[KAFKA-4682](https://issues.apache.org/jira/browse/KAFKA-4682)报告了与此偏移量过期有关的问题，即使（`Stable`）组中仍存在活动但很少提交的使用者，也会删除已提交的偏移量。
如果偏移量保留到过期时间戳之外（如果组仍处于`Stable` 状态），则可以避免这种情况。 解决方案 Kafka将删除早于offsets.retention.minutes的已提交偏移量 如果在低流量分区上有活动的使用者，则Kafka可能会删除该使用者的已提交偏移量。
偏移量一旦删除，该使用者的重新启动或重新平衡将导致该使用者找不到任何已提交的偏移量，并且最早/最新开始消耗（取决于auto.offset.reset）。我不确定，但是代理故障转移可能还会导致您从auto.offset.reset开始读取（由于代理重新启动或协调器故障转移）。
我认为，**Kafka应该只为不活动的消费者删除偏移量。只有在使用者组不活动之后，计时器才应启动**。例如，如果某个消费者组不活动，则在1周后，删除该消费者组的偏移量； 2.1.0版本比较不容易出现 offset比数据先到期的情况。 （） 一旦达到到期时间戳记，则无论组状态如何，都会从偏移缓存中删除偏移（在下一次清理期间）
- 在生产者中提供直观的用户超时（KIP-91）【挺有意思的，但是有些复杂没完全搞懂】 - Kafka的复制协议现在支持改进的僵尸防护。以前，在某些罕见情况下，如果代理从Zookeeper而不是集群的其余部分中进行了分区，则在最坏的情况下，复制分区的日志可能会分散并导致数据丢失（KIP-320）。
正文Kafka - Version 2.2.0 版本
Kafka 2.2.0包含许多重要的新功能。以下是一些重要更改的摘要：
- 添加了对自定义主体名称的SSL支持
- 允许SASL连接定期重新认证 - 命令行工具`bin/kafka-topics.sh`添加了AdminClient支持
- 改进的使用者组管理：默认`group.id`为`null`空字符串 - API改进：
【这也能是大版本？】
正文Kafka - Version 2.3.0 版本
Release Notes - Kafka - Version 2.3.0
Kafka 2.3.0包含许多重要的新功能。以下是一些重要更改的摘要：
- Kafka Connect REST API进行了一些改进。
- Kafka Connect now supports incremental cooperative rebalancing. - Kafka Streams现在支持内存中的会话存储和窗口存储。
- AdminClient现在允许用户确定他们有权对主题执行哪些操作。 - 有一个新的代理开始时间指标。
- JMXTool现在可以连接到安全的RMI端口。
- 已添加增量式AlterConfigs API。旧的AlterConfigs API已被弃用。
- 现在，我们跟踪低于其最小ISR计数的分区。
- 现在，即使在代理上启用了自动主题创建，消费者也可以选择退出。 - Kafka组件现在可以使用外部配置存储（KIP-421）。
- 遇到错误时，我们已实现了改进的副本获取程序行为。
现在，每个源连接器和接收器连接器都从worker属性继承其客户端配置。在worker属性中，所有带有前缀“生产者”的配置。或“消费者”。分别应用于所有源连接器和接收器连接器。 我们应该允许“生产者”。或“消费者”。根据管理员确定的替代策略进行替代。 - [[KAFKA-8365](https://issues.apache.org/jira/browse/KAFKA-8365)] - Protocol and consumer
正文Kafka - Version 2.4.0 版本
Release Notes - Kafka - Version 2.4.0 Kafka 2.4.0包含许多重要的新功能。【真正的大版本！！！！！！！！！！！！！！】
以下是一些重要更改的摘要：
- 允许使用者从最近的副本中获取。
kafka能够从follower副本读数据了,这个功能并不是为了提供读取性能 在早先kafka的设计中，为了使consumer读取数据能够保持一致，是只允许consumer读取leader副本的数据的。即follower replica只是单纯地备份数据的作用。那推出follower replica fetch功能的背景是什么呢？
举个比较常见的场景，kafka存在多个数据中心，不同数据中心存在于不同的机房，当其中一个数据中心需要向另一个数据中心同步数据的时候，由于只能从leader replica消费数据，那么它不得不进行跨机房获取数据，而这些流量带宽通常是比较昂贵的（尤其是云服务器）。即无法利用本地性来减少昂贵的跨机房流量。 所以kafka推出这一个功能，就是帮助类似这种场景，节约流量资源。这种功能还可以和新推出的mirror maker2相互配合，实现多个数据源的数据同步。 从follower replica读取数据肯定有问题，最可能的问题就是落后节点的问题，从这样的节点读取数据会面临什么样的情况呢？官方给出了几种场景及解决办法。先看看这张
主要有四种可能出现问题的情况，我们分别来看看应该如何解决：
Case 1（uncommitted offset）这个场景是follower接收到数据但还未committed offset，这个时候，若消费者的offet消费到high watemark到log end offset之间的那段（Case 1黄色那段），会返回空数据，而不是一个错误信息。直到这段内容 committed。
case 2（unavailable offset） 这种场景应该发生于慢节点的情况下，慢节点的broker还未接收到实际数据，但已经跟leader通信知道有部分数据committed了（case 2黄色部分）。当遇到这种情况，consumer 消费到时候，会返回 OFFSET_NOT_AVAILABLE 错误信息。
case 3（offset too small） 这种情况可能出现在消费者指定了 offset 的情况。那么在指定不同`auto.offset.reset`的时候有不同的情况。 1. If the reset policy is "earliest," fetch the log start offset of the current replica that raised the out of range error. 2. If the reset policy is "latest," fetch the log end offset from the leader. 3. If the reset policy is "none," raise an exception.
case 4（offset too large） 遇到这种情况，会返回一个 broker 会返回一个 OFFSET_OUT_OF_RANGE 的错误。
但 OFFSET_OUT_OF_RANGE 遇到这种错误的时候也有多种可能，官方给出当 consumer 遇到这种问题的解决思路，
Use the OffsetForLeaderEpoch API to verify the current position with the leader.
- If the fetch offset is still valid, refresh metadata and continue fetching
- 2. If truncation was detected, follow the steps in KIP-320 to either reset the offset or raise the truncation error
- 3. Otherwise, follow the same steps above as in case
sticky partitioner功能
kafka producer发送数据并不是一个一个消息发送，而是取决于两个producer端参数。一个是`linger.ms`，默认是0ms，当达到这个时间后，kafka producer就会立刻向broker发送数据。另一个参数是`batch.size`，默认是16kb，当产生的消息数达到这个大小后，就会立即向broker发送数据。 按照这个设计，从直观上思考，肯定是希望每次都尽可能填满一个batch再发送到一个分区。
但实际决定batch如何形成的一个因素是分区策略（partitioner strategy）。在Kafka2.4版本之前，在producer发送数据默认的分区策略是轮询策略（没指定keyd的情况。如果多条消息不是被发送到相同的分区，它们就不能被放入到一个batch中。 所以如果使用默认的轮询partition策略，可能会造成一个大的batch被轮询成多个小的batch的情况。
鉴于此，kafka2.4的时候推出一种新的分区策略，即Sticky Partitioning Strategy
Sticky Partitioning Strategy会随机地选择另一个分区并会尽可能地坚持使用该分区——即所谓的粘住这个分区。 鉴于小batch可能导致延时增加，之前对于无Key消息的分区策略效率很低。
社区于2.4版本引入了黏性分区策略（Sticky Partitioning Strategy）。该策略是一种全新的策略，能够显著地降低给消息指定分区过程中的延时。 使用Sticky Partitioner有助于改进消息批处理，减少延迟，并减少broker的负载。
Kafka Connect现在支持增量合作平衡
incremental cooperative rebalancing 负载均衡，基本是分布式系统中必不可少一个功能，apache kafka也不例外。为了让消费数据这个过程在kafka集群中尽可能地均衡，kafka推出了重平衡的功能，重平衡能够帮助kafka客户端（consumer client，kafka connect，kafka stream）尽可能实现负载均衡。
但是在kafka2.3之前，重平衡各种分配策略基本都是基于eager协议的（包括RangeAssignor，RoundRobinAssignor等，这部分内容最前面给出的文章有介绍），也就是我们以前熟知的kafka重平衡。eager协议重平衡的细节 值得一提的是，此前kafka就有推出一个重平衡的新分配策略，`StickyAssignor`粘性分配策略，主要作用是保证客户端，比如consumer消费者在重平衡后能够维持原本的分配方案，可惜的是这个分配策略依旧是在eager协议的框架之下，重平衡仍然需要每个consumer都先放弃当前持有的资源（分区）。 在2.x的时候，社区就意识到需要对现有的rebalance作出改变。所以在kafka2.3版本首先在**kafka connect应用cooperative协议**，然后在kafka2.4的时候也在consumer client添加了该协议的支持。
incremental cooperative rebalancing协议解析
https://issues.apache.org/jira/browse/KAFKA-8902 测试 接下来我们介绍cooperative协议和eager协议的具体区别。一句话介绍，
cooperative协议将一次全局重平衡，改成每次小规模重平衡，直至最终收敛平衡的过程
在kafka2.4的时候，社区推出两个新feature来解决重平衡过程中STW的问题。
- Incremental Rebalance Protocol（以下简称cooperative协议）：改进了eager协议（即旧重平衡协议）的问题，避免STW的发生，具体怎么避免，后面介绍
2. static membership：避免重起或暂时离开的消费者触发重平衡
apache kafka2.4 static membership功能
我们知道，当前重平衡发生的条件有三个：
- 成员数量发生变化，即有新成员加入或现有成员离组（包括主动离组和崩溃被动离组）
- 订阅主题数量发生变化
- 订阅主题分区数量发生变化 其中成员加入或成员离组是最常见的触发重平衡的情况。
新成员加入这个场景必然发生重平衡，没办法优化（针对初始化多个消费者的情况有其他优化，即延迟进行重平衡），但消费者崩溃离组却可以优化。因为一个消费者崩溃离组通常不会影响到其他{partition - consumer}的分配情况。 **因此在 kafka 2.3~2.4 推出一项优化，即此次介绍的
[Static Membership](https://link.zhihu.com/?target=https%3A//kafka.apache.org/26/documentation/%23static_membership)功能
和一个consumer端的配置参数** **`group.instance.id`**。一旦配置了该参数，成员将自动成为静态成员，否则的话和以前一样依然被视为是动态成员。 **静态成员的好处在于，其静态成员ID值是不变的，因此之前分配给该成员的所有分区也是不变的。即假设一个成员挂掉，在没有超时前静态成员重启回来是不会触发 Rebalance 的**（超时时间为`session.timeout.ms`，默认10 sec）。在静态成员挂掉这段时间，broker会一直为该消费者保存状态（offset），直到超时或静态成员重新连接。 如果使用了 static membership 功能后，触发 rebalance 的条件如下： - 新成员加入组：这个条件依然不变。当有新成员加入时肯定会触发 Rebalance 重新分配分区 - Leader 成员重新加入组：比如主题分配方案发生变更 - 现有成员离组时间超过了 `session.timeout.ms` 超时时间：即使它是静态成员，
coordinator 也不会无限期地等待它。一旦超过了 session 超时时间依然会触发 Rebalance - Coordinator 接收到 LeaveGroup 请求：成员主动通知 Coordinator 永久离组。 所以使用static membership的两个条件是： 1. consumer客户端添加配置：props.put("group.instance.id", "con1"); 2. 设置`session.timeout.ms`为一个合理的时间，这个参数受限于`group.min.session.timeout.ms`（6 sec）和`group.max.session.timeout.ms`（30 min），即大小不能超过这个上下限。但是调的过大也可能造成broker不断等待挂掉的消费者客户端的情况，个人建议根据使用场景，设置合理的参数。
正文Kafka - Version 2.5.0 版本
- Version 2.5.0 Kafka 2.5.0包含许多重要的新功能。.
以下是一些重要更改的摘要：
- TLS 1.3支持（默认为1.2）
- Kafka Streams的共同小组 - Kafka消费者的增量再平衡 - 新指标可提供更好的运营洞察力
- 将Zookeeper升级到3.5.7 - 弃用对Scala 2.11的支持
## New Feature
- [[KAFKA-6049](https://issues.apache.org/jira/browse/KAFKA-6049)] - Kafka Streams: Add Cogroup in the DSL - [[KAFKA-6144](https://issues.apache.org/jira/browse/KAFKA-6144)] - Allow serving interactive queries from in-sync Standbys -
[[KAFKA-7251](https://issues.apache.org/jira/browse/KAFKA-7251)] - Add support for TLS 1.3 -
[[KAFKA-8843](https://issues.apache.org/jira/browse/KAFKA-8843)] - Zookeeper migration tool support for TLS - [[KAFKA-9352](https://issues.apache.org/jira/browse/KAFKA-9352)] - unbalanced assignment of topic-partition to tasks -
[[KAFKA-9445](https://issues.apache.org/jira/browse/KAFKA-9445)] - Allow fetching a key from a single partition rather than iterating over all the stores on an instance -
[[KAFKA-9487](https://issues.apache.org/jira/browse/KAFKA-9487)] - Followup : KAFKA-9445(Allow fetching a key from a single partition);
Kafka 2.6.0包含许多重要的新功能。
以下是一些重要更改的摘要：
- 默认情况下，已为Java 11或更高版本启用TLSv1.3 - 性能显着提高，尤其是当代理具有大量分区时
- 提高Log.fetchOffsetByTimestamp（）的性能
通过按需初始化索引而不是在broker启动时创建所有索引时执行昂贵的磁盘/内存操作，对索引文件启用了惰性mmap。这有助于减少broker的启动时间。但是，无论是否需要关闭，都仍在关闭的分段上创建分段索引。 理想情况下，我们应该：通过延迟访问偏移量和时间索引来提高关闭性能。
- 在删除或重命名支持段索引的文件时，消除冗余磁盘访问和内存映射操作。
- 防止非法访问封闭段的基础索引，这会由于基础内存映射对象的重新创建而导致内存泄漏。 - 顺利扩展Kafka Streams应用程序 - Kafka Streams支持更改时发出 - 新指标可提供更好的运营洞察力
- 配置为进行连接时，Kafka Connect可以自动为源连接器创建主题 - 改进了Kafka Connect中接收器连接器的错误报告选项 - Kafka Connect中的新过滤器和条件SMT - client.dns.lookup配置的默认值现在是use_all_dns_ips - 将Zookeeper升级到3.5.8 Kafka 2.7.0包含许多重要的新功能。以下是一些重要更改的摘要： - **可配置的TCP连接超时并改善初始元数据获取** - 增强代理范围和每个侦听器的连接创建速率（KIP-612，第1部分） - 节流创建主题，创建分区和删除主题操作 - 将TRACE级别的端到端延迟指标添加到流中 - 添加代理端SCRAM Config API - 支持SSL证书和私钥的PEM格式 - 将RocksDB内存消耗添加到RocksDB指标 - 添加对聚合的滑动窗口支持
参考文献：
终日而思一：什么,kafka能够从follower副本读数据了 —kafka新功能介绍
https://zhuanlan.zhihu.com/p/324497008
Kafka 0.8.2.1版本之后Release Note重点
https://my.oschina.net/u/2433649/blog/1583527