Kafka 知识点总结

Serializer序列化器

changes

Broker 3id: 2

Segment

broker 1

Broker 关键参数：acks：消息可靠性保证retries：retries 生产者发送失败后的重试次数。enable.idempotence = true（幂等性）：开启后，生产者会自动重试，并保证单分区、单会话内消息不重复。max.in.flight.requests.per.connection（最大未确认请求数），保证幂等性设为 1。log.segment.bytes(日志段 Segment 大小)log.retention.hours(数据保留时间)，默认 7 天。

同步发送 (Synchronous Send)机制：生产者发送一条消息后，会立即阻塞当前线程，等待 Kafka 服务器（Broker）返回确认应答（ACK）。只有在收到成功的应答后，线程才会继续运行，发送下一条消息。示例：producer.send(record).get()。异步发送 (Asynchronous Send)机制：生产者将消息放入一个内存中的缓冲队列后便立即返回，不会阻塞线程，可以持续不断地发送下一条消息。发送操作在后台由专门的 Sender 线程批量处理。

/log_dir_event_notification

/controller

0

Sticky

分区分配策略 [ 默认：Range + Sticky ]

Broker 参数与调优

Consumer-0

分区目录下的文件示例

_transaction_state

Dqueue

seqid

partition-2

缓存数据去重

partition-0

Kafka 事务是其实现 \"精确一次\"（Exactly-Once）语义的核心机制，尤其适用于需要跨分区、跨主题保证消息原子性写入的场景。font color=\"#ec7270\

3

HW

Consumer-1

批次发送条件判断Sender 线程会不断地检查 RecordAccumulator，判断是否满足发送条件。图中提到了两个关键条件，满足任一即可触发发送：batch.size(批次大小已满)：某个分区的消息累积量达到了配置的批次大小阈值（例如 16KB）。linger.ms(等待超时)：即使批次未满，但最先进入批次的消息等待时间已经超过了配置的延迟时间（例如 5ms）。

/admin

Consumer-2

broker 4

拉取数据

范围分配策略（RangeAssignor） - 默认策略之一工作机制：首先，将所有分区按名称排序，所有消费者按名称排序。计算每个消费者应分配的分区数：分区总数 / 消费者数量。将排序后的分区范围依次分配给排序后的消费者。如果有余数，那么排在前面的消费者将会多分配 1 个分区。缺点：如果只有一个 Topic，不均匀度（C0比C2多1个分区）影响不大。但如果订阅了 N 个 Topic，那么每个 Topic 都会发生这种不均匀分配。最终导致 C0 比 C2 多消费了 N 个分区，负载不均衡会被放大，从而产生“偏差”。

TopicA

拉取模式 (Pull)：消费者采用 “拉” 的模式从 Broker 获取消息，这样可以按自己的处理能力控制消费速度，避免被压垮。

重试发送该批次

成功？

TopicA-Partition 0

2

Follower

Kafka Cluster

发送

partition-3

LEO

消费者组 (Consumer Group)核心规则：一个分区只能被同一个消费者组内的一个消费者实例消费。一个消费者实例可以同时消费多个分区。工作流程：所有消费者实例启动后，会通过组协调器（Group Coordinator） 完成重平衡（Rebalance），公平地分配分区。重平衡后，每个实例知道自己该消费哪些分区，然后开始独立地从指定的分区拉取（Pull） 消息进行消费。重平衡 (Rebalance)：当消费者组内的实例数量发生变化（如实例宕机或新增实例）时，会触发重平衡，重新分配分区，以保证负载均衡和高可用性。

轮询分配策略（RoundRobinAssignor）工作机制：将所有 Topic 的所有分区拉平，并按哈希值排序。将所有消费者排序。以轮询的方式，依次将每个分区分配给每个消费者。这种方式在所有 Topic 的整体上看，比 Range 更均衡。缺点：它的均衡性依赖于所有消费者订阅的 Topic 列表都相同这一前提。如果组内消费者订阅的 Topic 不同，则可能无法达到全局均衡。

Controller

Kafka 调优参数

Partioner分区器

消费者 (Consumer)参数与调优

partitions

/isr_change_notification

1

Leader副本故障处理细节（Leader Failover），当Leader副本宕机时的处理流程：故障发生与选举：Leader副本发生故障（如broker0宕机）。集群的Controller会立即从当前的ISR列表中选举出一个新的Leader（例如broker1）。保证数据一致性：新Leader上任后，其他存活的Follower副本（例如broker2）会将自己的日志截断至与新Leader相同的HW处。这一步至关重要，它确保了所有副本都回滚到上一个已达成一致的状态点，然后从该点开始同步新Leader的数据，从而防止了数据不一致。恢复正常：所有Follower从新Leader开始同步数据。故障的旧Leader恢复后，会作为Follower重复上述“故障恢复”流程，截断日志并重新同步。

Follower副本故障处理，Kafka利用 HW (High Watermark) 机制来保证数据一致性。故障发生：某个Follower副本（例如broker1）发生故障，Leader会将其从ISR（In-Sync Replicas）列表中移除。此时ISR集合缩小。故障恢复与追赶：当该Follower副本恢复后，它会读取本地磁盘记录的HW。它将本地日志中所有高于HW的消息全部截断删除。因为HW之后的消息可能尚未被所有ISR副本确认，其状态是不确定的。然后，该Follower从HW的位置开始，向Leader发起同步请求，拉取消息，追赶进度。重新加入ISR：当该Follower的 LEO (Log End Offset) 追赶并大于等于当前分区的HW 时，表明它已重新与Leader保持同步。此时，Leader会将其重新加入ISR列表，恢复其同步副本的身份。此过程的核心思想是：以HW为界，任何副本恢复后都必须从公认的、已达成一致的数据点（HW）开始同步，从而严格保证数据一致性，避免出现数据分歧。

TopicA-Partition 1

Kafka 存储单元分区（Partition）是基础单位：一个 Topic 的每个分区在物理上对应一个目录。分段（Segment）是管理策略：每个分区目录下的数据不会被存储为一个巨大的文件，而是被切分为多个顺序的、大小接近的 Segment 文件。这是一种“分治”策略，便于数据管理和清理。索引（Index）是加速器：每个 Segment 都对应两个物理文件：.log文件：存储实际的消息数据。.index文件：存储对应 .log文件的稀疏索引，用于快速定位消息。Segment 文件（包括 .log 和 .index）的命名规则是：“当前 Segment 所包含的第一条消息的偏移量（Offset）”，并用 20 位数字填充（如 00000000000000000010.log）。这使得根据 Offset 查找目标 Segment 文件变得非常高效。

users

消费者组

topic

事务协调器：每个有效的 transactional.id会通过哈希计算映射到 Kafka 内部主题 __transaction_state的某个特定分区。该分区的 Leader副本所在的Broker，即成为管理这个 transactional.id所有事务的协调器。职责：PID与Epoch管理；事务状态机管理（_transaction_state）协调两阶段提交（2PC）;元数据管理。

brokers

生产者 (Producer) 参数与调优

Selector

ids

分区器 (Partitioner) - 核心决策环节功能：这是决定一条消息将被发送到指定 Topic 的哪个具体分区的核心组件。有几个分区，生产端就有几个对应的缓冲队列。分区策略（默认由 DefaultPartitioner实现）：① 指定分区优先：如果在构造 ProducerRecord时显式指定了 partition号，则直接发送到该分区。② 有 Key 则哈希：如果未指定分区但设置了消息的 key，则对 key 进行哈希运算，然后对分区总数取余，根据余数选择分区。这确保了相同 key 的消息总是被写入同一个分区，从而保证分区内的顺序性。③ 无分区无 Key 则使用粘性分区：如果既未指定分区也没有 Key，则采用粘性分区器（Sticky Partitioner）。它会随机选择一个分区，并在一段时间内（非一条消息） 尽可能将所有消息都发送到这个分区，直到满足特定条件（如：该分区的批次已满、或 linger.ms延迟时间到达）后，才会“粘性”地切换到另一个随机选择的分区。这是一种重要的性能优化策略，因为避免了频繁切换分区带来的开销，能显著提升吞吐量。

消费者调优旨在最大化消费速度、避免重复消费或消息丢失，并维持消费组的稳定。fetch.min.bytes：默认 1(字节)，单次拉取的最小数据量，增大（如 1MB） 可减少网络请求次数，提高吞吐量，但可能增加延迟。fetch.max.wait.ms：默认 500，等待 fetch.min.bytes达到的最大时间，增大（如 500ms） 可与 fetch.min.bytes配合，鼓励拉取更多数据。max.poll.records：默认 500，单次 poll()返回的最大消息数，根据处理能力调整。过大可能导致处理超时，触发重平衡。enable.auto.commit：默认 true，是否自动提交位移，建议设为 false，采用手动提交，以确保消息处理完成后再提交位移，避免丢失。auto.offset.reset：默认 latest，无位移或位移失效时的策略，earliest：从最早开始，可能重复消费。latest：从最新开始，可能丢失数据。根据业务场景选择。max.poll.interval.ms：默认 5 min，两次 poll 调用的最大间隔，根据消息处理逻辑的耗时调整。处理逻辑耗时较长时需增大此值，避免被误认为消费失败而触发重平衡。isolation.level：默认 read\\_uncommitted，消息隔离级别，事务场景下需设置为 read\\_committed，以跳过未提交的事务消息。调优分析：高吞吐场景可增大拉取参数和单次拉取量；低延迟场景则需减小这些值并缩短等待时间；强一致性场景务必启用手动提交 (enable.auto.commit=false) 和 read\\_committed隔离级别。

KafkaChannel

Leader

数据目录下log

Producer

正确且安全地使用 acks=-1，必须进行以下组合配置：replication.factor：至少设置为 2，生产环境推荐为 3。这确保了每个分区数据有多个备份。min.insync.replicas：这是另一个至关重要的配套参数。它定义了 ISR 中最小可用副本数。建议设置：min.insync.replicas = 2（当 replication.factor=3时）

通过时间戳查找流程

通过偏移量查找流程

main 线程

clients

span style=\

生产者事务 (Producer-side Transaction) & 事务协调器目标：实现 Producer 端的“精确一次”发送语义，保证发送到多个分区的消息具有原子性（全部成功或全部回滚）。前提条件：开启生产者事务，必须首先开启幂等性 (enable.idempotence=true)。幂等性是实现事务的基础。核心组件：Transaction Coordinator (事务协调器)。这是一个运行在 Kafka Broker 上的特殊角色，负责管理事务的整个生命周期。它将其状态持久化在一个内部的 __transaction_state Topic 中。关键配置：transactional.id。生产者必须配置一个唯一的、稳定的 transactional.id。它的作用至关重要：       故障恢复：即使生产者客户端崩溃后重启，只要使用相同的 transactional.id，它就能连接到相同的事务协调器，并恢复之前未完成的事务状态，从而确保“精确一次”语义。       映射协调器：Kafka 根据 transactional.id的哈希值来确定由哪个事务协调器实例来管理该生产者的事务。事务流程：  初始化事务：生产者向事务协调器发起请求，初始化一个新事务。  获取 PID：事务协调器为生产者分配一个唯一的 Producer ID (PID)，这是幂等性的基础。  发送消息：生产者在事务内发送消息。这些消息会被标记为“未提交”状态，对普通消费者不可见。  提交或中止：    提交事务：生产者向协调器发起提交请求。协调器会：           将事务的最终状态（已提交）持久化到 __transaction_stateTopic 中。           向所有涉及到的消息分区发送“提交标记”，使这些消息对所有消费者可见。    中止事务：生产者发起中止请求。协调器会记录状态并确保所有在事务内发送的消息被丢弃，对消费者不可见。

broker 0

日志清理策略 (Log Cleanup Policy)Delete (日志删除)：根据保留时间（log.retention.hours）或日志大小（log.retention.bytes）直接删除整个过期的日志段（Segment）。以Segment为单位删除。图中思考题解答：如果一个Segment中部分数据过期，另一部分未过期，Kafka会等待整个Segment过期后一并删除，而不是只删除部分消息。Compact (日志压缩)：对于有Key的消息，保留每个Key的最新版本值，删除旧的重复版本。类似于数据库的“压缩”操作。log.cleanup.policy = compact / delete

准备与发送：一旦满足条件，Sender 线程会从 RecordAccumulator 中取出一个或多个已准备好的 RecordBatch (记录批次)。这些批次被转换成客户端请求，并通过 Selector (网络选择器) 组件，以非阻塞 I/O 的方式被批量发送到对应的 Kafka Broker。

分区 (Partition) 的核心价值：存储角度 (水平扩展)：分区允许将 Topic 的数据分散存储在集群中多个 Broker 的磁盘上。通过增加分区数，可以突破单机磁盘容量限制，实现海量数据存储。计算角度 (并行处理)：分区是 Kafka 并行处理的基本单位。多个消费者可以同时从不同分区读取数据（例如，一个消费者组内的不同消费者实例），从而极大提升了数据消费的吞吐量。

集群中会有一个 Broker 被选举为 Controller Leader。集群状态监听（Broker 的上下线状态）分区副本管理（Topic 的分区副本分配）Leader 选举

Sender 线程

/latest_producer_id_block

Round Robin

_consumer_offsetsKafka 中的内部主题，默认50 个分区，专门用于存储和管理所有消费者组（Consumer Group）的消费位移（Offset）信息。核心作用：持久化保存消费者组的消费进度。它记录每个消费者组对每个主题的每个分区消费到的位置（Offset）。这样，在消费者重启或发生故障时，能够从该位置恢复消费，避免消息丢失或重复消费。消息格式：该主题中的消息采用 Key-Value 格式。Key: 是一个三元组，包含 group.id（消费者组ID）、topic（主题名称）和 partition（分区号）。这唯一标识了一条位移信息属于哪个消费者组的哪个主题的哪个分区。Value: 包含实际的位移值（offset）、元数据（metadata）、提交时间戳（commit_timestamp）和过期时间戳（expire_timestamp）等信息。位移提交机制：自动提交：设置 enable.auto.commit = true（默认）。后台定期（间隔由 auto.commit.interval.ms控制，默认5秒）自动提交位移。手动提交：设置 enable.auto.commit = false。显式调用 commitSync()（同步阻塞）或 commitAsync()（异步无阻塞）方法来提交位移。

Kafka 高效读写数据的三大机制分布式架构（横向扩展）：分区（Partition）机制：将一个 Topic 的数据分散到多个 Broker 上存储和处理，实现了数据的分布式存储和计算的并行化。消费者组模型：允许多个消费者实例并行消费同一个 Topic，每个实例只消费部分分区，极大地提升了整体的消费能力。顺序写磁盘（Sequential Writes）：Kafka 持久化消息时，是将消息追加（Append）到日志文件末尾。这种顺序写入的方式充分利用了磁盘的物理特性，其速度甚至比内存的随机写还要快，这是 Kafka 高吞吐量的根本保证。零拷贝技术（Zero-Copy）：在消费者读取数据时，Kafka 利用 sendfile等系统调用，使得数据可以直接从磁盘文件经由网卡发送出去，无需经过应用程序内存（用户空间）。这减少了多次不必要的数据拷贝和上下文切换，极大降低了 CPU 开销和网络延迟，显著提升了消费性能。

处理服务端响应：请求发出后，Sender 线程会异步地等待并接收来自 Broker 的响应。成功响应：如果 Broker 成功处理了请求并返回 ACK，对应的 RecordBatch 会被标记为成功，并从累积器中移除，同时可能触发用户设置的回调函数 (Callback)。失败或超时响应：如果请求失败或超时，且未达到配置的 retries (重试次数) 上限，Sender 线程会自动重试发送该批次。这保证了在可恢复的错误（如网络抖动、Broker 短暂负载高）发生时，消息不会丢失。

state

Broker 是 Kafka 的服务端，其调优在于集群整体稳定性、吞吐能力和存储效率。num.partitions：默认 1，创建 Topic 时的默认分区数，分区是并行度的单位。建议设置与消费者数量匹配，通常每个 Broker 承载 100-200 个分区为宜。default.replication.factor：默认 1，默认副本因子，生产环境建议 ≥3，以提高数据可靠性和可用性。min.insync.replicas：默认 1，最小 ISR 副本数，配合 acks=all使用。设置为 2 可在容忍一个副本宕机的同时保证数据强一致性（前提是副本因子≥3）。log.retention.hours：默认 168 (7天)，日志保留时间，根据磁盘容量和业务需求合理设置，避免磁盘写满。num.io.threads：默认 8，处理磁盘 I/O 的线程数，建议设置为磁盘数量的 2-3 倍，以充分利用多磁盘 I/O 能力。num.network.threads：默认 3，处理网络请求的线程数，可根据 CPU 核心数适当增加（如 8-16）。unclean.leader.election.enable：默认 false，是否允许非 ISR 副本选举为 Leader，强烈建议保持默认的 false，防止数据丢失，优先保证一致性。调优分析：Broker 调优需综合考虑数据可靠性（副本数、ISR）、磁盘 I/O（线程数、日志分段）和资源管理（日志保留）。

Send

font color=\"#e74f4c\

Push vs. Pull：Push（推）模式：由 Broker 决定消息发送速率。缺点是难以适应所有消费者的处理能力。若 Broker 以 50 msg/s 的速率推送，而消费者只能处理 10 msg/s，则会导致消费者过载、消息堆积甚至崩溃。Pull（拉）模式：由 Consumer 主动向 Broker 请求数据。优点是消费者可以根据自身处理能力自主控制消费速率，实现背压（Backpressure） 机制，这是 Kafka 高可靠性的基石。Pull 模式的优化：为了解决“无数据时空轮询”的问题，Kafka 消费者在拉取请求中可以设置一个 timeout 参数。如果当前没有数据，消费者连接会在此超时时间内保持阻塞等待状态，直到有新数据到达或超时，从而避免了无效的空转和资源浪费。

broker 3

稀疏索引（Sparse Index）索引文件（.index）中的每条记录都是一个 font color=\"#e74f4c\

DQueue：用于存储着 ProducerBatch对象（消息批次）。当生产者发送消息时，消息会根据 topic-partition 被添加到对应的 Deque 中（通常添加到队尾）。在 Kafka 生产者中，RecordAccumulator 使用双端队列来按 topic-partition 组织消息，实现高效的消息累积和发送。Deque 允许在队头和队尾操作，支持 FIFO（先进先出）或 LIFO（后进先出）行为，适用于消息批次的管理。

b style=\

/consumer

工作流程

粘性分配策略（StickyAssignor） - 2.4+版本后默认策略设计目标：解决上述两种策略的两个痛点：1) 分配不均； 2) 重平衡时开销大。工作机制分为两步：首次分配：尽力追求绝对的、公平的负载均衡。它的分配结果会比 RoundRobin 更均匀。重平衡（Rebalance）：当消费者组内成员发生变化（如某个消费者崩溃退出）时，Sticky 策略会尽量保持原有的分配方案不变，仅将失效消费者原本负责的分区重新分配给剩余的消费者。核心优势：均衡性：分配结果比 Range 和 RoundRobin 更公平。减少重平衡开销：这是其最大价值。在发生重平衡时，大部分分区都无需更换消费者，从而：避免了因分区迁移导致的重复消费（非粘性策略需要将分区分配给新消费者，该消费者需要从头开始拉取数据）。减少了缓存失效和恢复状态带来的性能抖动，使得系统更稳定。

Broker 1id: 0

delete_topic

Zookeeper

幂等性

ProducerPID=1000

幂等性定义: “Producer不论向broker发送多少次重复数据，broker都只会持久化一条”。实现“精确一次”语义：幂等性 + 至少一次 (At-Least-Once) = 精确一次 (Exactly-Once)。至少一次保证: 通过配置 acks=-1(或 all) 和 min.insync.replicas>=2来实现，确保数据在 Broker 端不丢失。幂等性保证: 解决“至少一次”可能带来的数据重复问题，从而实现“精确一次”的最终效果。配置与局限性:开启方式: 在生产者的配置中设置 enable.idempotence=true。作用范围: 幂等性只能保证单个生产者会话内对单个分区的幂等。它无法保证跨分区的幂等（例如，事务操作需要原子性地写入多个分区）。数据安全: 要保证数据绝对可靠（不丢不重），必须同时满足两个条件：Producer 端开启幂等性。Topic 配置 min.insync.replicas>=2并且 Producer 设置 acks=-1。

消费者只能看到 2

broker 2

消费者事务 (Consumer-side Transaction)目标：实现 Consumer 端的“精确一次”处理语义，确保消息消费与外部业务操作（如数据库写入）的原子性。核心挑战：需要将 Kafka 消息的消费位移（Offset）提交 与 外部数据库的事务（如 MySQL） 绑定在一起，要么同时成功，要么同时回滚。解决方案流程：消费消息：Consumer 从 Kafka 集群（如 broker0上的 TopicA-Part0和 broker1上的 TopicA-Part1）拉取消息。处理消息：Consumer 执行业务逻辑（例如，计算、转换）。纳入事务：将业务逻辑的处理结果（如写入 MySQL 数据库的操作）与 Kafka 消费位移的提交操作，共同纳入一个外部事务（如 MySQL 事务）中。原子提交：如果外部事务成功提交，则意味着业务数据和 Kafka 消费位移被同时持久化。如果外部事务失败回滚，则业务数据和 Kafka 消费位移都不会被更新。

4

/cluster

LEO：当前日志文件中下一条待写入消息的偏移量位置。HW：已成功复制到所有 ISR 副本的消息的偏移量分界点。AR = ISR + OSR

RecordAccumulator（默认 32M）

Interceptors拦截器

partition-4

生产者负责发送消息，其调优核心在于平衡吞吐量、延迟和可靠性。batch.size：默认 16 KB，单个批次的最大字节，，增大批次（如 64KB-1MB） 可减少请求次数，提升吞吐量，但会增加延迟和内存消耗 。linger.ms：默认 0，发送前等待更多消息加入批次的时间，适当增加（如 10-50ms） 有助于组合更大批次，提高吞吐量。对延迟敏感的场景可设为 0。font color=\"#e74f4c\

_consumer_offsets

Range

Kafka

/kafka

Controller: Kafka 集群中会有一个 Broker 被选举为 Controller Leader，它主要负责以下工作：集群状态监听：负责监听和管理集群内所有 Broker 的上下线状态。分区副本管理：负责所有 Topic 的分区副本分配工作。Leader 选举：负责所有分区的 Leader 选举工作。当某个分区的 Leader 副本失效时，Controller 会从 ISR（In-Sync Replicas）列表中选举新的 Leader。

partition-1

Broker 2id: 1

TopicA-Partition 2

KafkaChannel: 指的是一个网络通道（通常基于 NIO），用于客户端（如生产者）与 broker 之间的通信。每个 KafkaChannel 关联一个具体的 broker（即 topic-partition 的 leader），并从 RecordAccumulator 中获取对应 broker 批次数据进行发送。

/config

/brokers

RecordBatch（记录批次）Producer 会将发往同一分区的多条消息在内存中累积成一个 RecordBatch（记录批次），然后一次性批量发送出去，而不是每条消息都发起一次网络请求。批次的大小由生产者参数 batch.size 控制，默认大小约为 16KB。（在生产环境中，可以适当调大此值（例如增加到 32KB），让每次网络请求携带更多的数据，从而显著提升吞吐量）linger.ms（默认为0）。它定义了消息在发送前可以在批次中等待的毫秒数。即使批次未满，只要等待时间达到此阈值，也会被发送。适当调大此参数（如5ms）可以增加批处理的机会，进一步提升吞吐量。

Zookeeper 服务端存储的 Kafka 相关信息

topics