1. 什么是Kafka
1.1 分布式事件流平台
Apache Kafka是一个开源的、分布式的事件流平台（event-streaming platform）。这个定义比“消息队列”更为精准，因为它涵盖了Kafka的三大核心能力 ：
发布与订阅事件流：类似于消息队列，允许应用程序实时地生产和消费事件流。
持久化存储事件流：能够以容错、持久的方式存储事件流，存储周期可按需配置，甚至永久保存。
实时处理事件流：能够在事件发生时或回溯历史事件进行实时处理。
Kafka被设计用于处理海量数据，能够应对每天数万亿级别的事件处理需求，并广泛应用于构建实时数据管道和流式处理应用 。
1.2 以日志为中心的架构
Kafka最核心的抽象概念是一个分布式的、分区的、多副本的提交日志（commit log）。这正是它与传统消息队列（如RabbitMQ）的根本区别所在。
传统消息队列通常在消息被消费后即将其删除，其主要职责是消息的“传递” 。而Kafka的持久化模型将数据视为一个连续不断、只进不出（append-only）的、可重放的日志流 。这种设计带来了几个革命性的优势：
数据解耦与持久化：数据一旦写入Kafka，便可被长期保存。这使得多个完全独立的消费端应用可以根据各自的需求和节奏，反复消费同一份数据流，而互不影响。例如，一个流用于实时监控面板，另一个用于离线分析，还有一个用于训练机器学习模型 。
事件溯源（Event Sourcing）：Kafka的日志可以作为系统状态变更的“事实来源（source of truth）”。任何服务的当前状态都可以通过重放其相关的事件日志来重建。
高吞吐性能：这种以日志为中心的设计，结合了对磁盘的顺序读写（sequential I/O）和零拷贝（zero-copy）等操作系统层面的优化，是Kafka能够实现惊人吞吐量的关键原因 。
1.3 Kafka与RabbitMQ对比
Kafka的核心是一个分布式的、持久化的提交日志（commit log）。它被设计为一个事件流平台，而不仅仅是消息队列。其设计理念是“笨拙的代理/智能的消费者”（dumb broker/smart consumer）。Broker的主要职责是高效地存储海量日志数据，而消费者则自己负责追踪读取进度（位移/offset）。这种设计使得Kafka极易水平扩展，并天然支持消息重放。
RabbitMQ是一个遵循AMQP（高级消息队列协议）的传统消息代理 。它的设计理念是“智能的代理/笨拙的消费者”（smart broker/dumb consumer）。Broker本身非常强大，负责消息的精细化路由、状态追踪和投递，支持复杂的消息交换模式 。
以下是Kafka和RabbitMQ的关键差异：
性能与吞吐量：这是两者最显著的区别。Kafka专为高吞吐量而生，通过顺序I/O、零拷贝、批处理和端到端压缩等技术，能够处理每天数万亿级别的事件 。RabbitMQ虽然在消息量不大的情况下能提供微秒级的延迟，但其吞吐能力远不及Kafka，一旦负载增高，延迟也会随之恶化 。
数据保留与消费模式：Kafka将数据视为可重放的日志流，消息在消费后不会被删除，而是根据配置的保留策略（retention policy）留存 。这使得多个不同的消费应用可以独立地、在不同时间、以不同速度消费同一份数据，实现了生产者和消费者之间彻底的时间和空间解耦 。 RabbitMQ则更像一个传统的邮局，其主要职责是“传递”消息。一旦消息被消费者成功处理，就会从队列中移除 。这种模式不支持消息重放。
消息路由的灵活性：这是RabbitMQ的强项。其强大的Exchange机制允许开发者实现非常精细和复杂的路由逻辑，例如根据消息的某个属性（routing key）将其发送到一个或多个队列，或者广播给所有队列 。 Kafka的路由则相对简单，主要依赖于生产者将消息发送到指定的Topic分区。虽然可以通过自定义分区器实现一些定制化路由，但其灵活性远不及RabbitMQ 。
1.4 Kafka为什么吞吐量高
顺序I/O与日志结构存储：Kafka将每个分区（Partition）都设计成一个只进不出（append-only）的日志文件。当生产者发送消息时，数据被顺序地追加到日志文件的末尾。这种操作模式是顺序磁盘写入，其速度远超随机写入，在传统机械硬盘和现代SSD上都能获得极高的性能。同样，消费者通常也是按顺序读取数据，这同样是一种高效的I/O模式。通过将可能随机的消息写入请求转换为顺序的磁盘操作，Kafka从根本上避免了磁盘寻道带来的巨大性能开销。
对操作系统页缓存（Page Cache）的利用：Kafka并没有在JVM应用层面实现复杂的缓存机制，而是巧妙地将缓存工作交给了操作系统内核的页缓存（Page Cache）。
写入时：数据被写入到内核的页缓存中，这个过程非常快。操作系统会负责在后台异步地将页缓存中的数据（脏页）刷写到物理磁盘。
读取时：如果消费者请求的数据恰好在页缓存中（这在“追赶读”的场景下很常见），数据将直接从内存中提供，完全避免了物理磁盘的读取操作。 这种设计不仅避免了JVM堆内缓存带来的对象开销和垃圾回收（GC）压力，还能利用到服务器上所有可用的空闲内存作为缓存，极大地提升了读写性能。
零拷贝（Zero-Copy）技术：这是Kafka性能优化的另一个“杀手锏”。在数据从Broker传输给消费者的过程中，Kafka使用了零拷贝技术。传统的数据传输需要将数据从内核空间的页缓存复制到应用程序的用户空间，然后再从用户空间复制回内核空间的套接字缓冲区（Socket Buffer），最后才发送到网络。零拷贝通过sendfile等系统调用，允许操作系统将数据直接从页缓存发送到网络接口（NIC），完全绕过了应用程序的用户空间，避免了两次不必要的数据拷贝和上下文切换，从而显著降低了CPU和内存的开销，提升了数据传输效率。
批处理（Batching）：为了减少网络开销，Kafka在客户端和服务器端都广泛使用批处理。
生产者端：生产者客户端会将发往同一分区的多条消息收集成一个批次（Batch），然后再统一发送给Broker。这大大减少了网络请求的次数，降低了网络往返的开销。batch.size和linger.ms这两个参数就是用来控制批处理行为的，允许在延迟和吞吐量之间进行权衡。
消费者端：消费者也是批量地从Broker拉取（fetch）数据，而不是一条一条地请求。
端到端压缩（End-to-End Compression）：Kafka允许生产者在发送数据前对整个消息批次进行压缩。支持的压缩算法包括Gzip、Snappy、LZ4和Zstd。数据以压缩的形式被写入Broker的日志并存储，也以压缩的形式传输给消费者，最后由消费者进行解压。这种端到端的压缩机制极大地减少了网络传输的数据量和Broker的磁盘存储空间，从而有效提升了整体吞吐量。由于压缩作用于整个批次，因此高效的批处理也能带来更高的压缩比。
2. Kafka的核心组件及其交互
2.1 Broker、集群与Controller
Broker：一个Kafka Broker就是一台运行Kafka服务的服务器实例 。
集群（Cluster）：一个或多个Broker共同组成一个Kafka集群，协同对外提供服务 。集群化部署是实现高可用和高扩展性的前提。
Controller：在整个Kafka集群中，会有一个Broker被选举为Controller 。这是一个至关重要的角色，其职责是管理整个集群的状态。具体包括：
监听Broker的上下线状态。
负责创建、删除Topic，以及分区数量的变更。
在Broker宕机时，负责为受影响的分区选举新的Leader。
这种单Controller的设计，使得集群级别的管理操作得以集中处理，简化了分布式环境下的协调逻辑，提高了管理效率。
2.2 Topic、Partition与Offset
Topic：Topic是Kafka中消息的逻辑分类或订阅单元，生产者将消息发布到特定的Topic，消费者通过订阅Topic来接收消息 。
Partition（分区）：这是Kafka实现水平扩展和高并发的核心机制。每个Topic可以被划分为一个或多个Partition 。每个Partition在物理上是一个独立的、有序的、不可变的记录序列，即一个小型日志文件 。通过将一个Topic的多个Partition分布到不同的Broker上，Kafka将存储和读写负载分散到了整个集群，从而实现了水平扩展 。
Offset（位移）：在每个Partition内部，每条消息都被赋予一个唯一的、顺序递增的整数ID，这个ID就是Offset 。Offset不仅唯一标识了Partition内的一条消息，更重要的是，它代表了消费者在该Partition中的消费位置。消费者通过提交自己已经消费到的Offset来记录进度。
2.3 Producer（生产者）
Producer是负责向Kafka Topic发布（写入）消息的客户端应用程序 。生产者在发送消息时，需要决定将消息发送到Topic的哪个Partition。这个决策可以基于消息的Key，也可以采用轮询等策略。
2.4 Consumer（消费者）与Consumer Group（消费组）
Consumer：Consumer是负责从Kafka Topic订阅（读取）消息的客户端应用程序 。
Consumer Group：在实际应用中，多个Consumer实例通常会组成一个Consumer Group来共同消费一个或多个Topic，它们共享同一个group.id 。Kafka通过Consumer Group机制实现了消费端的负载均衡和容错。其核心规则是：
在一个Consumer Group内部，一个Topic的每个Partition在同一时间只能被一个Consumer实例消费 。
负载均衡：如果一个Topic有10个Partition，一个拥有10个Consumer实例的Group可以实现完全的并行消费，每个Consumer负责一个Partition。
容错：如果Group中的某个Consumer宕机，它所负责的Partition会被自动重新分配给Group内其他存活的Consumer。
3. Kafka生产者
3.1 生产者的流程
调用producer.send()方法是一个异步操作 。当应用程序调用此方法时，记录（Record）并不会立即通过网络发送出去，而是进入一个精密的内部处理流水线 。
内部流水线
拦截器（Interceptors）：在消息被序列化之前，可以经过一系列用户自定义的拦截器。这些拦截器可以用来在不修改业务代码的情况下，对消息进行检查、修改或实现一些通用逻辑（如埋点、追踪）。
序列化器（Serializer）：Kafka Broker只接受字节数组（byte array）格式的消息。序列化器的作用就是将生产者应用程序中的对象（如Java对象、JSON字符串等）的Key和Value转换为字节数组 。
分区器（Partitioner）：分区器根据消息的Key或其它逻辑，为这条消息决定一个目标Topic Partition。
记录累加器与批处理
在确定了目标分区后，消息并不会被立刻发送，而是被放入一个名为RecordAccumulator的内存缓冲区中 。这个累加器会把发往同一个分区的消息组织成批次（Batch）。批处理是Kafka实现高吞吐的核心优化之一。
batch.size：该参数控制了单个批次的最大字节数。当一个分区的待发送消息累积到这个大小时，这个批次就准备好被发送了 。
linger.ms：该参数为批处理引入了时间维度的控制。它设定了生产者在发送一个批次前，愿意等待多长时间（毫秒）以期望收集更多的消息，即使batch.size还未达到 。这以增加少量延迟为代价，换取了发送更大、更高效批次的机会。如果 linger.ms设置为0，表示消息需要被立即发送（在可能的情况下）。
Sender线程
生产者客户端内部有一个后台I/O线程，称为Sender线程。它的职责是从RecordAccumulator中取出那些已经满了（达到batch.size）或者等待超时（达到linger.ms）的批次，并将它们通过网络请求发送给目标分区的Leader Broker 。Sender线程还负责处理Broker返回的响应（ACKs），并在必要时触发重试逻辑 。
生产者这种异步、批处理的设计，是一个经过深思熟虑的权衡，它明确地将整体吞吐量置于单条消息延迟之上。理解这一权衡是正确调优生产者的关键。批处理通过将多次零散的网络请求合并为一次大的请求，极大地减少了网络往返和Broker端的处理开销，从而实现了更高的总吞吐量 。
linger.ms参数直接控制着这个延迟与吞吐量的天平。较高的linger.ms值增加了形成大批次的可能性，这不仅提升了吞吐量，还提高了压缩效率（因为压缩是作用于整个批次的）。然而，这也意味着一条在时间点产生的消息，在被发送之前最多会延迟 linger.ms的时间，直接增加了端到端的延迟 。
3.2 分区策略
Kafka客户端自带了默认实现，同时也允许用户通过实现 。默认分区器的行为逻辑取决于消息本身的内容 ：
指定分区：如果生产者在创建ProducerRecord时显式地指定了分区号，那么分区器将直接使用该分区。这种方式给予了开发者完全的控制权，但在实践中较少使用。
基于Key的分区：如果消息提供了Key（且未显式指定分区），默认分区器会对Key进行哈希运算（使用一种非加密的murmur2算法），然后将哈希值映射到一个分区上 。此策略最关键的保证是： 所有具有相同Key的消息，总是会被发送到同一个分区 。这是Kafka实现消息有序性保证的基础。
无Key的分区：如果消息的Key为null，其分区行为与Kafka的版本相关。
轮询（Round-Robin）：在Kafka 2.4及其之前版本中，无Key的消息会以简单的轮询（Round-Robin）方式被均匀地分发到Topic的所有可用分区中 。这种方式能保证负载的绝对均衡，但缺点是会产生大量的小批次，降低了发送效率。
粘性分区（Sticky Partitioning）：从Kafka 2.4版本开始，默认采用了“统一粘性分区器”（Uniform Sticky Partitioner）。当Key为 null时，生产者会“粘”在一个分区上，将后续的所有无Key消息都发送到这个分区，直到该分区的批次满了或者linger.ms超时。之后，它会随机选择一个新的分区再次“粘”住。这种策略在宏观上依然能保证消息在所有分区间的均匀分布，但在微观上通过生成更大的批次，显著降低了延迟并提升了吞-吐量 。
对于一些高级应用场景，开发者可以实现Partitioner接口来定义自己的分区逻辑。例如，可以根据消息体中的某个业务字段（如用户所在地理区域）来路由消息，以实现数据的地理位置亲和性，方便后续的本地化处理 。
数据倾斜
对分区Key的选择，是一项关键的数据建模决策，其影响深远，关乎系统的可扩展性、消息顺序以及潜在的故障模式，绝非一个简单的技术细节。所有具有相同Key的消息都会被路由到同一个分区，这一机制为需要按序处理的场景（例如，某个用户的所有操作记录）提供了保证 。然而，这也埋下了隐患：如果某个Key产生了远超其他Key的消息量（即“热点Key”），就会导致数据倾斜（Data Skew） 。
数据倾斜的后果是连锁性的。首先，这个“热点分区”所在的Broker将承受比其他Broker高得多的CPU、磁盘和网络负载。其次，负责消费该分区的Consumer实例将面临巨大的处理压力，极易产生严重的消费延迟（Consumer Lag） 。最后，该分区的Follower副本可能因难以跟上Leader的高速写入而频繁地被踢出同步副本列表（ISR），即发生“ISR收缩”，从而削弱了分区的高可用性 。
在设计系统时，必须对潜在的Key分布进行分析。如果预见到数据倾斜的可能，就需要考虑采用复合Key（如user_id + session_id）或实现自定义分区器来更均匀地分散负载，即便这意味着要牺牲掉对user_id的严格全局有序性。
3.3 保障持久性
acks机制
acks（Acknowledgements）是生产者配置中用于控制数据持久性（Durability）的最重要参数。它决定了生产者在认为一次写入成功之前，需要等待多少个Broker副本的确认 。
acks=0（发送即忘）：生产者发送消息后，不等待来自Broker的任何响应。一旦消息被写入客户端的Socket缓冲区，就认为发送成功。这种模式提供了最低的延迟和最高的吞-吐量，但持久性最弱。如果Broker在收到消息后立即宕机，或者网络出现问题，消息将会丢失，而生产者对此一无所知 。此模式仅适用于可以容忍部分数据丢失的场景，如非关键的指标或日志收集 。
acks=1（Leader确认）：这是Kafka 3.0版本之前的默认设置 。生产者会等待分区的Leader副本成功将消息写入其本地日志后，再认为发送成功。这种模式在持久性和性能之间取得了很好的平衡 。然而，数据丢失的风险依然存在：如果Leader在发送确认给生产者之后、且在Follower副本同步数据之前宕机，那么这条消息就会丢失 。
acks=all（或-1）：这是Kafka 3.0版本及之后的默认设置，提供了最高级别的数据持久性保证 。生产者会等待Leader副本以及所有同步副本（In-Sync Replicas, ISR）都成功写入消息后，才认为发送成功 。这确保了只要至少还有一个同步副本存活，消息就不会丢失 。当然，这种强保证是以牺牲延迟为代价的 。
min.insync.replicas的角色
这是一个Broker端或Topic级别的配置参数，它与生产者的acks=all设置紧密配合，共同构成了Kafka的强持久性保障。它规定了当生产者使用acks=all时，一个分区必须拥有的最小同步副本数量，写入请求才会被接受 。
如果一个分区的可用同步副本数（ISR的大小）低于此配置值，那么Broker将拒绝来自生产者的acks=all写入请求，并返回NotEnoughReplicas或NotEnoughReplicasAfterAppend异常。
对于一个副本因子（replication.factor）为3的Topic，一个常见且健壮的配置是min.insync.replicas=2。这意味着，要成功写入一条消息，集群中至少要有2个副本是存活且同步的。这样的配置可以容忍一个Broker的故障，而不会丢失数据，也不会中断写入服务 。
一个最关键且经常被误解的知识点是：单独设置acks=all并不能完全保证数据不丢失。只有将生产端的acks=all与Broker端的min.insync.replicas > 1相结合，才能真正抵御Broker故障导致的数据丢失。
以下面的场景为例，假设一个Topic的replication.factor=3，生产者的acks=all，但Broker端的min.insync.replicas保留默认值1。现在，集群中的两个Broker相继宕机，导致该Topic某个分区的ISR列表收缩到只剩下一个成员（即Leader本身）。此时，一个生产者发送了一条消息。由于当前ISR的数量（1）大于等于min.insync.replicas的值（1），Leader接受了这个写入请求。因为Leader是ISR中唯一的成员，它无需等待任何Follower的确认，便立即向生产者返回了成功的ACK。生产者认为消息已安全持久化。紧接着，最后一个承载Leader的Broker也宕机了。结果是什么？数据永久丢失了。生产者收到了成功的确认，但数据从未被复制到任何其他机器上。
这个例子揭示了acks=all的真正含义：它只保证消息被复制到了当前ISR列表中的所有成员。而min.insync.replicas参数才强制要求写入操作必须满足一个最低的冗余水平。当集群健康状况恶化，ISR数量低于这个阈值时，Kafka会选择牺牲可用性（Availability）来保证一致性（Consistency），主动拒绝写入请求，从而避免了上述场景中的“假成功”和数据丢失。
4. Kafka消费者
4.1 消费者组与重平衡协议
消费组（Consumer Group）是一组共享同一个group.id的消费者实例，它们协同工作，共同消费一个或多个Topic的数据 。Kafka实现消费端可扩展性的关键在于，它会将一个Topic的所有分区均匀地分配给一个消费组内的所有成员。核心规则是： 在任何时刻，一个分区只能被组内的一个消费者实例所消费 。这个机制带来了两大好处：
负载均衡：你可以通过向消费组中添加更多的消费者实例来横向扩展消费能力。如果一个Topic有N个分区，你最多可以启动N个消费者实例来实现完全的并行处理 。
容错：如果组内某个消费者实例崩溃或离开，它之前负责的分区会被Kafka自动重新分配给组内其他存活的消费者，从而保证消费过程不中断。
组协调器
在Kafka集群中，每个消费组都会被分配一个特定的Broker来作为其组协调器（Group Coordinator）。协调器的职责是管理该消费组的状态，包括：追踪组成员列表、负责分区的分配、以及在组成员发生变化时触发和管理重平衡过程 。消费者实例启动后会首先找到自己的协调器，并与之建立心跳连接，以表明自己处于存活状态 。
重平衡的触发
重平衡（Rebalance）是指将分区的所有权在消费组的成员之间进行重新分配的过程 。它在以下几种情况下被触发 ：
有新的消费者实例加入消费组。
有现有的消费者实例离开消费组（无论是正常关闭还是因心跳超时而被协调器判定为死亡）。
订阅的Topic分区数量发生变化。
重平衡协议
经典（Eager）重平衡：Kafka最初的重平衡协议是“渴望式”的，通常被称为“停止世界”（Stop-the-World）。在重平衡期间，该消费组的所有消费者都会停止处理消息，并撤销对自己所有分区的所有权。然后，由组内的Leader消费者（一个由协调器指定的消费者）根据分配策略重新为所有成员分配全部分区。这个过程非常具有破坏性，因为它会导致整个应用的消费处理暂停，即使对于那些分区分配本无需改变的消费者也是如此 。
协作式（Cooperative）重平衡：为了解决上述问题，较新版本的Kafka引入了协作式重平衡协议（也称为增量式重平衡）。在这种协议下，重平衡期间，消费者只会放弃那些需要被移动到其他消费者的分区的所有权，而对于那些仍然分配给自己的分区，它们可以继续处理消息。这极大地缩短了“停止世界”的暂停时间，使得重平衡过程的干扰性大大降低，对于部署在Kubernetes等动态、弹性环境中的应用尤为重要 。
分区分配策略
重平衡期间，分区具体如何分配是由partition.assignment.strategy配置项决定的。常见的策略包括 ：
Range：将每个Topic的分区按数字排序，然后将连续的分区段（Range）分配给每个消费者。当分区数不能被消费者数整除时，容易导致分配不均。
RoundRobin：将所有订阅Topic的所有分区平铺开来，然后以轮询的方式逐一分配给每个消费者。这种策略通常能带来更均衡的负载分配 。
Sticky：此策略的目标是在重平衡时，尽可能地保持原有的分区分配不变。它会尽量避免分区的跨消费者移动，从而最小化重平衡带来的“缓存”失效等代价。这是最高效的策略之一，特别是与协作式重平衡结合使用时 。
CooperativeSticky：当启用协作式重平衡协议时，这是默认的分区分配器 。
从“渴望式”到“协作式”重平衡的演进，是Kafka为适应现代云原生、弹性计算环境而做出的直接回应。它代表了一种设计理念的转变，即在常规的集群运维事件中，优先保障应用的持续可用性。在传统的、静态的物理机部署环境中，消费者实例可能是长期运行的，重平衡事件相对稀少，因此“停止世界”带来的短暂中断或许可以接受。然而，在以Kubernetes为代表的云原生环境中，消费者实例（通常是Pod）的生命周期是短暂且动态的。部署、自动扩缩容、节点故障等都会频繁地导致消费者加入和离开消费组，使得重平衡成为一种常态化的运维事件，而非异常。
4.2 位移管理
位移是一个唯一标识分区内消息位置的整数 。消费者的消费状态，本质上就是它正在消费的每个分区的位移集合，这个集合记录了它已经处理到哪里 。Kafka将所有消费组提交的位移信息，持久化存储在一个名为__consumer_offsets的内部、高可用的特殊Topic中 。当一个消费者提交位移时，它实际上是向其组协调器发送一个请求，协调器再将这个位移信息作为一条消息写入到这个内部Topic。这种设计使得位移的存储也是持久且容错的。
自动提交 vs. 手动提交位移
消费者配置中的一个关键选择是自动提交/手动提交位移，这直接决定了消息处理的可靠性语义。
自动提交 (enable.auto.commit=true)：这是默认行为。消费者客户端会在每次poll()调用后，按照auto.commit.interval.ms（默认5秒）配置的时间间隔，自动提交上一次poll()返回的最大位移 。这种方式使用方便，但可能导致数据丢失或重复处理。
至多一次（At-Most-Once）风险：如果消费者自动提交了位移，但在处理完相应的消息之前崩溃，那么重启后它将从新的位移开始消费，导致已提交但未处理的消息丢失 。
至少一次（At-Least-Once）风险：如果消费者处理完消息，但在下一次自动提交发生之前崩溃，那么重启后它将从上一次提交的位移开始，导致部分消息被重复处理 。
手动提交 (enable.auto.commit=false)：这种模式下，开发者可以完全控制位移提交的时机，是实现可靠数据处理的基石 。
同步提交 (commitSync())：此调用会阻塞，直到位移提交请求被Broker确认。它会在遇到可恢复的错误时自动重试，但其阻塞特性会影响吞吐量 。
异步提交 (commitAsync())：此调用是非阻塞的，发送提交请求后立即返回。它通过回调函数来处理成功或失败的响应。它提供了更高的吞吐量，但管理起来更复杂，因为后一次的异步提交可能会在之前失败的提交重试成功前完成，导致位移覆盖错误 。
auto.offset.reset 策略
这个告诉消费者在两种特定情况下应该从哪里开始消费：1）当一个全新的消费组第一次启动时（在Kafka中没有任何已提交的位移）；2）当一个之前提交的位移在Broker上已经失效时（例如，数据因保留策略已被删除）。
latest (默认值)：从分区的末尾开始消费。消费者只会看到在它启动之后新产生的消息 。
earliest：从分区的起始位置开始消费。消费者会处理该分区中所有可用的历史消息 。
none：如果没有找到有效的已提交位移，则向消费者抛出异常。这强制要求应用程序必须显式地处理这种情况 。
手动位移管理是构建与外部系统交互的可靠数据处理应用的基石。它允许开发者将Kafka的类事务性保证延伸至其他数据库或服务。设想一个消费应用，它需要读取Kafka消息，进行处理，然后将结果写入一个外部数据库（如MySQL）。如果使用自动提交，位移可能在数据库写入之前就被提交了。若此时应用崩溃，消息在Kafka中被视为“已消费”，但其处理结果却在数据库中丢失，破坏了系统间的一致性。
通过禁用自动提交（enable.auto.commit=false），我们可以实现一个健壮的处理模式：
通过poll()获取一批消息。
对这批消息进行业务处理。
在外部数据库中开启一个事务。
将处理结果写入数据库。
调用consumer.commitSync()，同步提交Kafka的位移。
提交外部数据库的事务。
在这个流程中，无论在哪个步骤发生崩溃，状态都是可恢复的。如果在Kafka位移提交前崩溃，消息会被重新消费。如果在Kafka位移提交后、数据库事务提交前崩溃，数据库事务会回滚，消息同样会被重新消费（这会导致对数据库的重复写入尝试，因此数据库端的写入操作必须设计成幂等的，例如使用UPSERT）。
5. Kafka 高可用与一致性机制
5.1 复制协议
Leader与Follower副本
为了实现容错，Kafka中的Topic数据是可复制的。在创建Topic时，可以指定一个副本因子（replication.factor），例如，设置为3表示每个分区都会有3个物理副本，分布在不同的Broker上 。对于每个分区，其多个副本中会有一个被选举为Leader，其余的则成为Follower 。
Leader的角色：Leader副本负责处理该分区所有的读写请求。它是该分区数据的唯一权威来源 。
Follower的角色：Follower副本被动地从Leader那里拉取最新的数据以进行同步。它们通常不直接服务于客户端的读写请求（尽管较新版本支持配置从Follower读取），其主要职责是作为Leader的热备份 。
同步副本列表
这是Kafka可用性故事中最关键的概念之一。ISR是一个分区所有副本的子集，这个子集中的成员被认为是与Leader“完全同步”的 。
“同步”的定义：一个Follower被认为是同步的，需要满足两个条件：1）它必须与Leader保持着活跃的连接；2）它不能落后Leader太多。这个“太多”是由参数replica.lag.time.max.ms（默认30秒）定义的。如果一个Follower在这么长时间内没有向Leader发起过fetch请求，或者fetch了但没有追上Leader的最新数据，它就会被认为是“不同步”的 。
动态性：ISR列表是动态变化的。如果一个Follower落后太多或与Leader失联，Leader会将其从ISR中移除（称为“ISR收缩”）。当这个Follower重新追上进度后，可以被重新加入ISR（称为“ISR扩张”）。
Leader选举过程
触发：当集群的Controller检测到某个承载分区Leader的Broker发生故障时（例如，通过与ZooKeeper或KRaft Quorum的会话丢失），就会触发Leader选举 。
选举：Controller会为所有失去Leader的分区发起新Leader的选举。关键的规则是：新的Leader必须从该分区当前的ISR列表中选举产生 。这是保证已提交数据不丢失的核心。因为新Leader是从一个已完全同步的副本中选出的，所以它必然拥有所有已被确认提交的数据。
非清洁Leader选举（Unclean Leader Election）：一个极端情况是，如果一个分区的所有ISR成员（包括Leader）都宕机了怎么办？默认情况下（unclean.leader.election.enable=false），Kafka会选择等待，直到ISR中的某个副本恢复上线，并选举它为新Leader。这个选择优先保证数据一致性（Consistency）而非可用性（Availability） 。如果将此参数设置为true（强烈不推荐），Kafka会从所有存活的副本（即使是那些已经落后很多的）中选举一个作为新Leader。这能更快地恢复分区的可用性，但代价是可能会丢失那些尚未被这个旧副本同步到的数据 。这是一个明确的C/A权衡。
与许多采用静态多数派投票（Static Quorum）的共识算法（如Raft、Paxos）不同，那些算法通常要求写入必须得到大多数节点的确认。在有部分副本暂时缓慢或网络延迟高的情况下，这可能会拖慢整个系统的性能。Kafka的ISR模型当生产者使用acks=all时，写入请求只需要得到ISR列表中的副本确认即可。如果某个副本变慢了，它会被动态地从ISR中移除，这样生产者就不必再等待它，从而使得集群即使在存在少数慢节点的情况下也能保持高性能。这个动态法定人数的设计，带来了性能优势，但其代价是增加了运维的关注点。频繁的ISR变动是一个关键的健康预警信号，它可能预示着网络问题、Broker过载或磁盘I/O瓶颈，这些问题正妨碍Follower及时地从Leader同步数据 。
5.2 消息语义
Kafka在客户端与Broker之间提供了三种可配置的“投递语义”（Delivery Semantics），即关于消息如何被投递的保证等级 。
At-Most-Once（至多一次）：消息可能会丢失，但绝不会被重复投递 。这种语义可以通过将生产者的重试次数 retries设为0，或者让消费者在处理消息之前就提交位移来实现 。它优先考虑性能，牺牲了可靠性。
At-Least-Once（至少一次）：消息绝不会丢失，但可能会被重复投递 。这是Kafka的默认保证。它通过生产者在发送失败时进行重试，以及消费者在处理完消息之后再提交位移来实现 。这种模式要求消费端的应用程序必须是幂等的（Idempotent），即能够处理重复的消息而不会导致系统状态错误 。
Exactly-Once（精确一次，EOS）：每条消息都被精确地投递和处理一次，即使在发生故障的情况下也不会丢失或重复 。这是最强的保证，也是实现起来最复杂的。
Kafka的EOS并非通过单一设置实现，而是依赖于自0.11版本引入的两大核心特性：幂等生产者和事务 。
幂等生产者（Idempotent Producer）
目标：解决因生产者重试而导致的单分区内消息重复问题。
机制：通过在生产者配置中设置enable.idempotence=true来启用 。启用后，每个生产者实例会被分配一个唯一的生产者ID（PID），并且它发送的每条消息都会附带一个针对特定分区的序列号（Sequence Number）。Broker端会为每个（PID, 分区）组合追踪已成功写入的最大序列号。当Broker收到一条消息时，如果其序列号小于或等于已记录的最大值，说明这是一条重复的重试消息，Broker会直接丢弃它，但依然会向生产者返回成功的确认。这样既保证了生产者的重试能够成功，又避免了数据的重复写入 。
隐式配置：启用幂等性会自动将acks设置为all，retries设置为一个非常大的值，并将max.in.flight.requests.per.connection设置为一个安全的值（1或5），以确保消息的顺序和持久性 。
原子事务（Atomic Transactions）
目标：允许一个应用原子性地向多个Topic或分区发送消息（要么全部成功，要么全部失败），并将消息的生产与消费位移的提交绑定在同一个原子操作中。这是实现真正的端到端EOS，特别是对于“读-处理-写”类型应用的关键 。
机制：生产者需要配置一个全局唯一的transactional.id。应用程序通过调用beginTransaction()、send()和commitTransaction()（或abortTransaction()）等API来界定一个事务的边界 。Broker端有一个名为事务协调器（Transaction Coordinator）的组件来管理这些事务的状态。它会在日志中写入特殊的“提交”或“中止”标记消息 。
消费端配合：要消费事务性消息，消费者必须将isolation.level配置为read_committed。这告诉消费者只读取那些已经成功提交的事务中的消息，而忽略那些处于未提交或已中止状态的事务中的消息 。
Kafka中的“精确一次语义”更准确的描述应该是“在Kafka生态系统内部的有效一次流处理”。这个保证主要针对的是“读-处理-写”循环的原子性，其中“写”操作的目标是另一个Kafka Topic。它并不能神奇地让与外部非事务性系统的交互也变成“精确一次”。
EOS的典型应用场景是一个Kafka Streams应用：它从一个输入Topic读取数据，进行有状态的转换，然后将结果写入一个输出Topic 。事务机制确保了消费位移的提交、内部状态存储（其底层也是一个Kafka Topic）的更新、以及向输出Topic生产的消息，这三者作为一个不可分割的原子单元被提交。任何环节的失败都会导致整个事务回滚。下游配置为 read_committed的消费者将永远不会看到这种不完整的、被中止的结果 。
然而，如果“处理”步骤涉及到调用一个外部REST API或向一个非事务性的数据库写入数据，问题就出现了。Kafka事务无法控制这些外部系统的副作用 。如果应用成功调用了外部API，但在commitTransaction()之前崩溃，Kafka事务将会中止。应用重启后，会重新消费这条消息，并再次调用外部API，导致了外部系统的重复操作。
这意味着，要实现涉及外部系统的真正端到端精确一次处理，外部系统本身必须提供某种形式的事务性或幂等性接口，以便与Kafka事务进行协调。例如，应用可能需要实现两阶段提交协议，或者确保对外部系统的写入是幂等的。