kafka知识点总结

大家好，欢迎来到IT知识分享网。

Kafka基础架构

1. 1. Producer：消息生产者，就是向 Kafka broker 发消息的客户端。
2. 2. Consumer：消息消费者，向 Kafka broker 取消息的客户端。
3. 3. Consumer Group（CG）：消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
4. 4. Broker：一台 Kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个broker 可以容纳多个 topic。
5. 5. Topic：可以理解为一个队列，生产者和消费者面向的都是一个 topic。
6. 6. Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。
7. 7. Replica：副本。一个 topic 的每个分区都有若干个副本，一个 Leader 和若干个Follower。
8. 8. Leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 Leader。
9. 9. Follower：每个分区多个副本中的“从”，实时从 Leader 中同步数据，保持和Leader 数据的同步。Leader 发生故障时，某个 Follower 会成为新的 Leader。

应用场景

• • 缓冲和削峰：有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况
• • 解耦和扩展性：允许独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束
• • 异步通信：把一个消息放入队列，但并不立即处理它，然后在需要的时候再去处理它们
• • 发布订阅：可以有多个topic，每个topic被不同消费者使用，且消费者相互独立

生产者发送流程

1. 1. 配置客户端：在开始发送消息之前，需要对 Kafka 生产者客户端进行必要的配置
2. 2. 创建消息：生产者创建要发送的消息，每条消息由键（Key）、值（Value）和可选的分区信息组成
3. 3. 序列化消息：序列化的目的是为了在网络中高效传输数据
4. 4. 分区选择：根据消息的键和分区策略，生产者决定将消息发送到主题的哪个分区。分区选择的方式有以下几种：
5. • 指定分区：在创建 消息 时指定了分区号
6. • 轮询分区：如果消息的键为 null，使用轮询的方式依次将消息发送到各个分区
7. • 基于键的哈希分区：如果消息的键不为 null，对键进行哈希计算，根据哈希值选择对应的分区。保证具有相同键的消息被发送到同一个分区，便于消息的顺序处理
8. 5. 消息累加器（RecordAccumulator）
9. • 消息在发送之前会先被存储在消息累加器中。将多个小的消息合并成一个大的批次，减少网络请求的次数。
10. • 根据分区将消息分组，每个分区对应一个 RecordBatch。当 RecordBatch 达到一定的大小或者达到一定的时间间隔时，会触发消息的发送
11. 6. 网络客户端（NetworkClient）
12. • 与 Broker 建立连接，并将 RecordBatch 发送到相应的分区领导者副本
13. • 在发送消息之前，从 ZooKeeper 或 Broker 获取最新的元数据信息，确保将消息发送到正确的 Broker 和分区
14. 7. 消息确认（Acks）: 生产者根据 acks 配置决定是否等待 Broker 的确认
15. • acks=0：生产者不等待任何确认，消息可能会丢失
16. • acks=1：生产者等待 Leader Broker 的确认，消息可能会丢失（如果 Leader 应答完成后故障，还没来得及同步副本）
17. • acks=all(-1)：生产者发送过来的数据，Leader和ISR队列里面的所有节点收齐数据后应答。如果发送失败，生产者会根据 retries 和 retry.backoff.ms 配置进行重试。
18. 8. 回调处理（可选）：生产者在发送消息时可以指定一个回调函数，当消息发送成功或失败时，会调用该回调函数

补充说明：

• • ISR：Leader维护了一个动态的in-sync replica set（ISR），意为和Leader保持同步的Follower+Leader集合(leader：0，isr:0,1,2)。如果Follower长时间未向Leader发送通信请求或同步数据，则该Follower将被踢出ISR
• • 幂等性：Producer不论向Broker发送多少次重复数据，Broker端都只会持久化一条，保证不重复。
• • 具有<PID, Partition, SeqNumber>相同主键的消息提交时，Broker只会持久化一条。其中PID是Kafka每次重启都会分配一个新的；Partition 表示分区号；Sequence Number是单调自增的
• • 幂等性只能保证的是在单分区单会话内不重复
• • 事务支持：Kafka 支持事务机制，生产者可以将多条消息封装在一个事务中，确保这些消息要么全部成功，要么全部失败，避免部分消息重复

Zookeeper中存储的Kafka 信息

从 Kafka 0.9 版本开始，消费者偏移量默认存储在 Kafka 内部的 __consumer_offsets 主题中

Zookeeper 在 Kafka 中的作用：

• • Broker 注册：Zookeeper 存储 Kafka Broker 的注册信息，包括 Broker ID、主机名、端口等
• • Topic 和 Partition 元数据：Zookeeper 存储 Topic 和 Partition 的元数据，包括 Partition 的分配、副本信息、Leader 选举等
• • Consumer Group 管理：Zookeeper 存储 Consumer Group 的元数据，包括 Group 的成员信息、Offset 等
• • 控制器选举：Kafka 集群中的控制器（Controller）负责 Partition 的 Leader 选举和其他管理任务，Zookeeper 用于选举控制器
• • 动态配置：Zookeeper 存储 Kafka 的动态配置信息，如 Topic 配置、Broker 配置等

Broker 工作流程

文件存储

1. 目录结构

1. 1. 日志文件（.log）
2. • 存储消息的实际数据，包括消息的 Key、Value、Offset、时间戳等
3. • 消息按顺序追加写入，不可修改
4. • 文件大小达到配置的阈值（log.segment.bytes）后，会创建新的 Log Segment
5. 2. 索引文件（.index）
6. • 存储消息的 Offset 到物理位置的映射
7. • 索引文件是稀疏索引，只记录部分消息的 Offset 和物理位置
8. 3. 时间索引文件（.timeindex）
9. • 存储消息的时间戳到 Offset 的映射
10. • 支持按时间戳查找消息
11. 4. Leader Epoch 检查点文件（leader-epoch-checkpoint）
12. • 存储 Partition 的 Leader Epoch 信息
13. • 用于副本同步和故障恢复

2. 核心机制

• • 顺序写入：将消息顺序追加到日志文件中，避免了随机写入的开销（省去了大量磁头寻址的时间），从而提高了写入性能
• • 页缓存（Page Cache）：使用操作系统的页缓存（Page Cache），将消息先写入内存中的页缓存，然后由操作系统异步地将数据刷新到磁盘。当读操作发生时，先从PageCache中查找，如果找不到，再去磁盘中读取
• • 分段存储：日志文件会被分割成多个日志段（Log Segment），便于日志文件的清理和压缩，提高消息查找的效率
• • 稀疏索引：只记录部分消息的 Offset 和物理位置，查找时先定位到最近的索引点，然后顺序扫描日志文件
• • 零拷贝（Zero-Copy）：将消息从磁盘直接传输到网络，避免了数据在用户空间和内核空间之间的复制
• • 数据压缩：支持对消息进行压缩（如 GZIP、Snappy、LZ4），减少存储空间和网络传输开销
• • 日志清理：Kafka 支持两种日志清理策略：
• • 删除（Delete）：根据时间或大小删除旧的 Log Segment
• • 压缩（Compact）：保留每个 Key 的最新消息，删除旧的消息

数据积压

消费者如何提高吞吐量？

1. 1. 如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数= 分区数
2. 2. 如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间 < 生产速度），使处理的数据小于生产的数据，也会造成数据积压

保证数据不丢失

• • 生产者层面
• • 消息确认机制（acks 配置），acks = all（或 acks = -1）
• • 重试机制，生产者在发送消息失败时，可以配置重试次数
• • Broker 层面
• • 多副本机制：Kafka 主题的每个分区可以有多个副本，这些副本分布在不同的 Broker 上
• • 数据持久化：将消息持久化到磁盘
• • 消费者层面
• • 手动提交 Offset
• • 消费位置重置

保证数据不重复

• • 生产者层面
• • 幂等性（Idempotence）：生产者可以启用幂等性
• • 事务（Transactions）：多条消息封装在一个事务中，确保这些消息要么全部成功，要么全部失败
• • Broker 层面
• • 序列号验证：生产者启用了幂等性，Broker 会检查每条消息的序列号，拒绝重复的消息
• • 消费者层面
• • 消费者事务：Kafka消费端将消费过程和提交offset 过程做原子绑定
• • 消费者端的幂等处理：根据消息的唯一标识（如消息 ID）判断该消息是否已经处理过