简介
Apache kafka 是一个分布式的基于push-subscribe的消息系统，它具备快速、可扩展、可持久化的特点。它现在是Apache旗下的一个开源系统，作为hadoop生态系统的一部分，被各种商业公司广泛应用。它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/spark流式处理引擎。
特性
高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒
可扩展性：kafka集群支持热扩展
持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
高并发：支持数千个客户端同时读写
架构组件
Kafka中发布订阅的对象是topic。我们可以为每类数据创建一个topic，把向topic发布消息的客户端称作producer，从topic订阅消息的客户端称作consumer。Producers和consumers可以同时从多个topic读写数据。一个kafka集群由一个或多个broker服务器组成，它负责持久化和备份具体的kafka消息。
Topic：消息存放的主题
Producer：生产者，负责push消息到指定的Broker的Topic中
Consumer：消费者
Broker：Kafka的服务实例，主要负责创建Topic，存储Producer所发布的消息，记录消息处理过程，先将消息保存到内存中，再落地到磁盘
Replication-factor：复制因子（kafka容错机制），即副本数量，一般与Broker数量保持一致
Partitions：分区（每个分区只能被同一个消费者组内的一个消费者消费）
Leaders：选举partition中的副本为leader，负责处理读写
Follower: 未被选举为leader的副本为follower，负责备份数据
Zookeeper：注册消息，用于保存broker节点信息，维护ISR和OSR队列，partition的offset等（ZK在kafka2.8版本之后移除，offset保存在本地）
副本同步机制
kafka 0.8以后，提供了HA机制，就是replica副本机制。每个partition的数据都会同步到其他机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。
[图片上传失败...(image-6f7b38-1743417387765)]
Kafka 生产者ack机制
-
ack=0：
意义：生产者在成功将消息发送给服务端之后不等待任何确认
结果：生产者不知道消息是否成功到达服务端，容易造成消息丢失
-
ack=1：
意义：生产者在成功将消息发送给服务端之后，等待leader的确认
结果：意味着leader节点成功接收数据，但是不一定同步了其他副本
-
ack=all 或 ack=-1：
意义：生产者在成功将消息发送给服务端之后，等待所有partition的副本确认
结果：当所有副本都接收到数据之后，才认为消息被成功提交
Kafka 如果设置了ack（ack!=0），需要设置超时时间(retry.backoff.ms)和重试次数（retries）
ack过程中出现网络问题，导致生产者重复发送消息怎么处理？
重复产生的核心原因
-
超时与重试机制 当 Producer 发送消息后，若在
request.timeout.ms（默认 30 秒）内未收到 Broker 的ack确认，Producer 会认为消息发送失败并触发重试（retries参数控制重试次数）。 风险场景：Broker 实际已成功写入消息，但
ack响应因网络延迟未及时到达 Producer。Producer 重试时，Broker 会再次写入相同的消息（若未启用幂等性），导致消息重复。
Broker 的写入机制 Kafka 的 Partition 日志是仅追加（append-only）的，即使消息内容相同，重试时也会被当作新消息写入（除非开启幂等性）。
避免重复的解决方案
(1) 启用 Producer 幂等性
配置方式： 在 Producer 中设置
enable.idempotence=true（需同时满足acks=all和retries > 0）。-
原理：
Producer 为每个消息分配唯一
PID（Producer ID）和序列号。Broker 根据
PID + 分区号 + 序列号去重，拒绝重复消息。
适用场景： 单 Producer 实例内保证 Exactly-Once 语义，避免因重试导致的重复。
(2) 使用 Kafka 事务
-
配置方式：
- 设置
transactional.id并调用initTransactions()、beginTransaction()、commitTransaction()。
- 设置
-
原理：
事务机制结合幂等性，确保跨多个 Partition 和 Consumer 的原子性操作。
Broker 会记录事务状态，中断的事务自动回滚。
适用场景： 需要跨多个消息或“读-处理-写”链路的 Exactly-Once 语义（如 Kafka Streams）。
(3) 业务端去重
-
实现方式：
在消息中携带唯一标识（如 UUID 或业务主键）。
消费者端根据唯一标识去重（如写入数据库时检查主键冲突）。
适用场景： 无法启用幂等性或事务的旧版本 Kafka，或需要兼容其他消息系统的场景。
ISR 机制
Kafka 服务端根据副本同步的情况，分成了三个集合：
AR（Assigned Replicas）：包括ISR和OSR
ISR（In-sync Replicas）：和leader保持同步的副本集合，可以认为是可靠数据（leader故障之后会在这个集合重新选举）
OSR（Out-sync Replicas）：和leader副本同步失效的副本集合（副本还会继续同步数据，同步成功之后会进入ISR）
Kafka 数据持久化机制
Kafka 默认使用操作系统的页缓存（page cache）机制，将消息写入内存中的页缓存，而非立即刷盘（高吞吐的原因）
默认情况下，Kafka 通过以下两个参数控制主动刷盘：
log.flush.interval.messages：累计多少条消息后触发刷盘（默认Long.MAX_VALUE，即不主动触发）log.flush.interval.ms：间隔多少毫秒后触发刷盘（默认null，即不主动触发） 实际默认行为：依赖操作系统后台线程（如 Linux 的pdflush）自动刷盘，通常延迟约 30 秒
Broker 端配置
-
强制刷盘 修改
log.flush.interval.messages和log.flush.interval.ms，例如：log.flush.interval.messages=1 # 每条消息都刷盘（极端情况，性能极低）
log.flush.interval.ms=1000 # 每秒刷盘一次
此配置会显著降低吞吐量，仅适用于对数据丢失零容忍的场景。
Kafka 数据模型与消息存储机制
[图片上传失败...(image-4d351-1743417387765)]
在同一个Topic下，一个partition对应一个唯一的文件夹，在文件夹下，kafka 消息是采用 Segment File的存储方式进行存储
Segment File：Segment由.index文件和.log文件组成，将大文件拆分成小文件来存储（加快IO加载）
.index文件：索引文件，以key-value格式存储，key-表示索引文件的第几条消息；value-表示这条消息在log file中的物理偏移量
.log文件：数据存储文件
如何通过 offset 找到 某一条消息呢？
首先会根据 offset 值去查找 Segment 中的 index 文件，因为 index 文件是以上个文件的最大 offset 偏移命名的所以可以通过二分法快速定位到索引文件。
找到索引文件后，索引文件中保存的是 offset 和对应的消息行在 log 日志中的存储行号，因为 Kafka 采用稀疏矩阵的方式来存储索引信息，并不是每一条索引都存储，所以这里只是查到文件中符合当前 offset 范围的索引。
拿到 当前查到的范围索引对应的行号之后再去对应的 log 文件中从 当前 Position 位置开始查找 offset 对应的消息，直到找到该 offset 为止。
每一条消息的组成内容有如下字段：
Copy
offset: 4964(逻辑偏移量)
position: 75088(物理偏移量)
CreateTime: 1545203239308(创建时间)
isvalid: true(是否有效)
keysize: -1(键大小)
valuesize: 9(值大小)
magic: 2
compresscodec: NONE(压缩编码)
producerId: -1
producerEpoch: -1(epoch号)
sequence: -1(序号)
isTransactional: false(是否事务)
headerKeys: []
payload: message_0(消息的具体内容)
Kafka pull & push
pull是指consumer来拉取消息（默认）；push是指kafka主动推送消息给consumer
pull模式：根据consumer的消费能力进行数据拉取，可以批量拉或者单条拉；可以设置不同的提交方式实现不同的传输语义
缺点：如果kafka没有数据会导致consumer空循环（可以通过设置拉取数据为空或没达到一定数量阻塞来解决）
push模式：不会导致consumer循环等待
缺点：速率固定、忽略consumer的消费能力，可能导致拒绝服务或网络拥堵等情况
kafka常见问题
1、消息幂等性（重复消费）
重复消费只针对消费者端而言，消费者要保证消息的幂等性，一般要结合业务场景进行，主要有两种解决方案：
1）redis：消费数据后把消息的唯一键存到redis中，每次消费的时候去redis查一下key是否存在
2）mysql：消费数据后把消息的唯一键存到mysql中，每次消费的时候查mysql
2、数据丢失
消费者：消费者自动提交offset的时候会有数据丢失的情况，改为手动提交offset可解决，极端情况下数据处理完后提交offset的时候挂了，可通过加幂等性操作解决
kafka：kafka某个broker宕机，重新选举leader时有数据未同步时会有消息丢失的情况，可通过设置参数（保证数据写入到每个副本后才算写入成功）解决
生产者：设置acks=all即可避免丢失数据
3、顺序性
生产者：生产者没有顺序性问题
kafka：partition内部有序，多个partition时无法保证顺序，对需要顺序消费的数据指定到同一个partition即可保证顺序
消费者：同一个partition时，当消费者内部启用多线程时会导致顺序错乱，可在消费者内部启用内存队列来保证多线程的顺序
4、kafka 高性能高吞吐原因
-
磁盘顺序读写：
Kafka 将消息按顺序追加（Append）到 Partition 日志文件末尾，避免机械硬盘磁头频繁寻道
消费者按偏移量（Offset）顺序读取消息，充分利用操作系统的磁盘预读
页缓存（page cache）：消息直接写入内存页缓存，由操作系统异步刷盘，读操作优先访问缓存，减少物理磁盘 I/O
-
零拷贝：
传统数据拷贝流程： 磁盘文件 → 内核缓冲区 → 用户空间缓冲区 → Socket 缓冲区 → 网卡 4 次上下文切换 + 2 次 CPU 拷贝
Kafka 优化（
sendfile系统调用）： 磁盘文件 → 内核缓冲区 → 网卡 2 次上下文切换 + 0 次 CPU 拷贝，减少 50% 以上 CPU 消耗
-
分区分段+索引：分区是指partition，分段是指segment文件，索引是指segment里的.index索引
-
分区（Partition）机制
数据分片：每个 Topic 划分为多个 Partition，分布在不同 Broker 上。
并行读写：生产者和消费者可同时向多个 Partition 写入/读取数据，充分利用集群资源。
扩展性：通过增加 Partition 和 Broker，线性提升吞吐量。
-
生产者负载均衡
-
分区策略：
默认轮询（Round Robin）或按 Key 哈希，确保数据均匀分布。
自定义策略支持业务特化路由。
-
-
消费者组（Consumer Group）
并行消费：同一消费者组内多个消费者实例分别消费不同 Partition，提升消费速度。
水平扩容：增加消费者数量即可扩展消费能力（需 Partition 数量 ≥ 消费者数量）。
-
-
批量处理（Batching）
-
生产者端：
消息积累到
batch.size（默认 16KB）或linger.ms（默认 0ms）后批量发送，减少网络请求次数。压缩（Compression）：支持 GZIP、Snappy、LZ4、Zstandard，降低网络传输量（尤其文本类消息）。
-
Broker 端：
- 批量写入磁盘，减少磁盘寻址次数。
-
消费者端：
- 批量拉取消息（
max.poll.records控制单次拉取数量）。
- 批量拉取消息（
-
直接操作页缓存（page cache）：消息直接写入内存页缓存，由操作系统异步刷盘，读操作优先访问缓存，减少物理磁盘 I/O
