Kafka 工作流程解析：从 Broker 工作原理、节点的服役、退役、副本的生成到数据存储与读写优化

在大数据处理领域，Kafka 作为一款高性能的分布式消息队列系统，扮演着至关重要的角色。它能够高效地处理大规模的实时数据，为众多大数据应用提供了可靠的数据传输和存储基础。本文将深入探讨 Kafka 的核心组件 ------Kafka Broker，包括其工作流程、副本机制、文件存储以及高效读写数据的原理，并分享一些生产环境中的实用经验。

一、Kafka Broker 工作流程

（一）Zookeeper 存储的 Kafka 信息

Kafka 与 Zookeeper 紧密协作，Zookeeper 存储了许多关键的 Kafka 信息。启动 Zookeeper 客户端后，通过ls /kafka命令可以查看相关信息。其中，consumers节点在老版本（0.9 版本之前）存放消费者的偏移量，而在新版本中，偏移量直接存储在集群中。我们还可以借助工具如 "漂亮的 zoo" 通过图形化界面更直观地查看 Zookeeper 中的信息。

通过网盘分享的文件：prettyZoo-win.msi

（二）Kafka Broker 总体工作流程

注册与选举

每一个 Broker 上线时，会在 Zookeeper 中进行注册。每个 Broker 中都有一个 Controller，它们会争先抢占 Zookeeper 中controller节点的注册权，率先抢到的 Broker 中的 Controller 将在选举等事务中拥有决策权。

选举规则以在 ISR（与 Leader 保持同步的 Follower 集合）中存活为前提，按照 AR（分区中的所有副本集合）中排在前面的优先。例如，对于ar[1,0,2]，isr[1,0,2]，Leader 会按照1，0，2的顺序进行轮询选举。选举出来的新节点会注册到 Zookeeper 中，并将信息记录下来，其他 Controller 则同步 Zookeeper 中的信息，假定broker中的leader挂掉了，会进行重新的选举。

数据处理

客户端发送消息给 Leader，Leader 负责记录数据并落盘形成 Log。Log 底层采用 Segment 机制，每一个 Segment 大小为 1G，为了实现数据的快速查找，在 1G 内的数据又分成了log和index两个文件。

二、生产经验 ------ 节点服役和退役

（一）服役新节点

新节点准备

（1）关闭 bigdata03，进行一个快照，并右键执行克隆操作。

（2）开启 bigdata04，并修改 IP 地址。

bash 复制代码

vi /etc/sysconfig/network-scripts/ifcfg-ens33

修改完记得重启网卡：
systemctl restart network

（3）在 bigdata04 上，修改主机名称为 bigdata04。

bash 复制代码

hostname bigdata04    # 临时修改

$root@bigdata04 \~$ # vim /etc/hostname

bigdata04

还要记得修改 /etc/hosts文件，并进行同步

bash 复制代码

修改bigdata01的hosts 文件，修改完之后，记得同步一下

192.168.52.11 bigdata01
192.168.52.12 bigdata03
192.168.52.13 bigdata02
192.168.52.14 bigdata04

xsync.sh /etc/hosts
scp -r /etc/hosts root@bigdata04:/etc/

（4）重新启动 bigdata03、bigdata04。

（5）修改 bigdata04 中 kafka 的 broker.id 为 3。

bash 复制代码

进入bigdata04的kafka中，修改里面的配置文件   config/server.properties

（6）删除 bigdata04 中 kafka 下的 datas 和 logs。

bash 复制代码

rm -rf datas/* logs/*

（7）启动 bigdata01、bigdata02、bigdata03 上的 kafka 集群。

先启动zk集群

bash 复制代码

xcall.sh zkServer.sh stop
xcall.sh zkServer.sh start

启动kafka集群（只能启动三台）

bash 复制代码

kf.sh start

（8）单独启动 bigdata04 中的 kafka。

bash 复制代码

bin/kafka-server-start.sh -daemon ./config/server.properties

查看kafka集群first主题的详情：

bash 复制代码
bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --topic first --describe
发现副本数并没有增加。

由于我之前创建first这个主题的时候只有一个副本，不是三个副本，所以呢，演示效果不佳。
bash 复制代码
kafka-topics.sh --bootstrap-server bigdata01:9092 --topic third --create --partitions 3 --replication-factor 3

执行负载均衡操作

（1）在kafka下创建一个要均衡的主题

bash 复制代码

创建一个文件：vi topics-to-move.json
写上如下代码，如果多个topic 可以使用,分隔
{
  "topics": [
    {"topic": "third"}
  ],
  "version": 1
}

（2）生成一个负载均衡的计划

在创建的时候，记得启动bigdata04节点，否则计划中还是没有bigdata04

bash 复制代码

bin/kafka-reassign-partitions.sh --bootstrap-server bigdata01:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2,3" --generate

未来的分区策略拷贝一份：

bash 复制代码

{"version":1,"partitions":[{"topic":"abc","partition":0,"replicas":[2,0,1],"log_dirs":["any","any","any"]},{"topic":"abc","partition":1,"replicas":[3,1,2],"log_dirs":["any","any","any"]},{"topic":"abc","partition":2,"replicas":[0,2,3],"log_dirs":["any","any","any"]}]}

（3）创建副本存储计划（所有副本存储在 broker0、broker1、broker2、broker3 中）。

复制代码

vi increase-replication-factor.json

bash 复制代码

{"version":1,"partitions":[{"topic":"first","partition":0,"replicas":[3,2,0],"log_dirs":["any","any","any"]},{"topic":"first","partition":1,"replicas":[0,3,1],"log_dirs":["any","any","any"]},{"topic":"first","partition":2,"replicas":[1,0,2],"log_dirs":["any","any","any"]}]}
以上这个内容来自于第二步的执行计划。

（4）执行副本存储计划。

bash 复制代码

bin/kafka-reassign-partitions.sh --bootstrap-server bigdata01:9092 --reassignment-json-file increase-replication-factor.json --execute

（5）验证副本存储计划。

bash 复制代码

bin/kafka-reassign-partitions.sh --bootstrap-server bigdata01:9092 --reassignment-json-file increase-replication-factor.json --verify

如果不相信添加成功，可以查看first节点的详情：

（二）退役旧节点

执行负载均衡操作

先按照退役一台节点，生成执行计划，然后按照服役时操作流程执行负载均衡。

（1）创建一个要均衡的主题

bash 复制代码

kafka下添加文件：vim topics-to-move.json
添加如下内容：
{
 "topics": [
 {"topic": "abc"}
 ],
 "version": 1
}

（2）创建执行计划。

bash 复制代码

bin/kafka-reassign-partitions.sh --bootstrap-server bigdata01:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2" --generate

（3）创建副本存储计划（所有副本存储在 broker0、broker1、broker2 中）。

bash 复制代码

添加文件： vi increase-replication-factor.json 
添加如下代码：
{"version":1,"partitions":[{"topic":"first","partition":0,"replicas":[0,2,1],"log_dirs":["any","any","any"]},{"topic":"first","partition":1,"replicas":[1,0,2],"log_dirs":["any","any","any"]},{"topic":"first","partition":2,"replicas":[2,1,0],"log_dirs":["any","any","any"]}]}

（4）执行副本存储计划

bash 复制代码

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop11:9092 --reassignment-json-file increase-replication-factor.json --execute

（5）验证副本存储计划。

bash 复制代码

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop11:9092 --reassignment-json-file increase-replication-factor.json --verify

执行停止命令

在要退役的节点（如bigdata04）上执行bin/kafka-server-stop.sh命令停止 Kafka 服务。

三、Kafka 副本

（一）副本基本信息

（1）Kafka 副本作用：提高数据可靠性。

（2）Kafka 默认副本 1 个，生产环境一般配置为 2 个，保证数据可靠性；太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率。

（3）Kafka 中副本分为：Leader 和 Follower。Kafka 生产者只会把数据发往 Leader，然后 Follower 找 Leader 进行同步数据。

（4）Kafka 分区中的所有副本（包含Leader）统称为 AR（Assigned Repllicas）。

AR = ISR + OSR

ISR ，表示和 Leader 保持同步的 Follower 集合。如果 Follower 长时间未向 Leader 发送通信请求或同步数据，则该 Follower 将被踢出 ISR。该时间阈值由 replica.lag.time.max.ms 参数设定，默认 30s。Leader 发生故障之后，就会从 ISR 中选举新的 Leader。

**OSR，**表示 Follower 与 Leader 副本同步时，延迟过多的副本.

（二）Leader 选举流程

Kafka 集群中有一个 Broker 的 Controller 会被选举为 Controller Leader，负责管理集群 Broker 的上下线、所有 topic 的分区副本分配和 Leader 选举等工作，其信息同步依赖于 Zookeeper。例如，创建一个新的 topic（如bigdata2401），设置 4 个分区和 4 个副本，通过停止某些节点上的 Kafka 进程，可以观察到 Leader 的选举是按照 AR 进行的，而不是 ISR。

（1）创建一个新的 topic，4 个分区，4 个副本

bash 复制代码

bin/kafka-topics.sh --bootstrap-server hadoop11:9092 --create --topic bigdata2401 --partitions 4 --replication-factor 4

（2）查看 Leader 分布情况

（3）停止掉 hadoop13 的 kafka 进程，并查看 Leader 分区情况

bash 复制代码

bin/kafka-server-stop.sh
 bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --describe 
--topic bigdata2305

（4）停止掉 hadoop14 的 kafka 进程，并查看 Leader 分区情况

通过以上演示，大家可以发现，选举是按照AR(跟Replicas一样)进行的，而不是ISR

（三）Leader 和 Follower 故障处理细节

LEO演示-- 每一个副本最后的偏移量offset + 1

HW(高水位线 High Water) 演示：所有副本中，最小的LEO

由于数据同步的时候先进入Leader,随后同步给Follower，假如Follower挂掉了，Leader和其他的Follower 继续往前存储数据，挂掉的节点从ISR集合中剔除，此时挂掉的Follower又重启了，它会先从上一次挂掉的节点的HW开始同步数据，直到追上最后一个Follower为止,此时会重新回归ISR。

（四）分区副本分配

如果 Kafka 服务器只有有限的节点数，在创建 topic 时，分区数和副本数的设置需要合理。例如，创建 16 分区、3 个副本的second主题，Kafka 在初始化时会按照特定算法选举第一 Leader，保障 Leader 不在一个 Broker 里面。

1）创建 16 分区，3 个副本

（1）创建一个新的 topic，名称为 second。

bash 复制代码

bin/kafka-topics.sh --bootstrap-server hadoop11:9092 --create --partitions 16 --replication-factor 3 --topic second

bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --create --topic bigdata230801 --partitions 3 --replication-factor 4

假如你有3个broker ,却创建4个副本，报错！！

Error while executing topic command : Replication factor: 4 larger than available brokers: 3.

$2023-09-13 18:43:47,458$ ERROR

org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication factor: 4 larger than available brokers: 3

bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --create --topic bigdata23 --partitions 4 --replication-factor 2

假如你有3个broker ,却创建4个分区，是可以的。

以上错误的意思是，目前只有2台服务器，却要创建3个副本，创建不了。

（2）查看分区和副本情况

bash 复制代码

bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic second

kafka在进行初始化的时候，选举谁当第一Leader，是有一定的算法的。算法保障了Leader不在一个broker里面。

（五）生产经验 ------ 手动调整分区副本的存储

在生产环境中，由于服务器配置和性能差异，可能需要手动调整分区副本的存储。例如，创建three主题，4 个分区、2 个副本，并将其所有副本存储到broker0和broker1两台服务器上。通过创建副本存储计划并执行kafka-reassign-partitions.sh命令来实现。

（1）创建一个新的 topic，名称为 three。

bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --create --partitions 4 --replication-factor 2 --topic three

（2）查看分区副本存储情况。

bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --describe --topic three

（3）创建副本存储计划（所有副本都指定存储在 broker0、broker1 中）。

vi increase-replication-factor.json

输入如下内容：

bash 复制代码

{ 
  "version":1, 
  "partitions":[{"topic":"three","partition":0,"replicas":[0,1]}, 
    {"topic":"three","partition":1,"replicas":[0,1]}, 
    {"topic":"three","partition":2,"replicas":[1,0]}, 
    {"topic":"three","partition":3,"replicas":[1,0]}] 
}

（4）执行副本存储计划。

bash 复制代码

bin/kafka-reassign-partitions.sh --bootstrap-server bigdata01:9092 --reassignment-json-file increase-replication-factor.json --execute

（5）验证副本存储计划。

bash 复制代码

bin/kafka-reassign-partitions.sh -- bootstrap-server bigdata01:9092 --reassignment-json-file increase-replication-factor.json --verify

（6）查看分区副本存储情况

bash 复制代码

bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --describe --topic three

（六）生产经验 ------Leader Partition 负载平衡

Kafka 通常会自动将 Leader Partition 均匀分散在各个机器上，但在某些 Broker 宕机后可能导致负载不均衡。相关参数如auto.leader.rebalance.enable（默认是true）、leader.imbalance.per.broker.percentage（默认是 10%）和leader.imbalance.check.interval.seconds（默认值 300 秒）控制着 Leader Partition 的平衡机制。在生产环境中，auto.leader.rebalance.enable常被修改为false以避免资源浪费。

（七）生产经验 ------ 增加副本因子

在生产环境中，若某个主题重要性提升，可能需要增加副本。例如创建four主题，初始副本数为 1，之后通过手动创建副本存储计划并执行kafka-reassign-partitions.sh命令来增加副本。需要注意的是，副本创建后不能直接通过命令修改，只能通过这种手动计划的方式增加。

1）创建 topic

bash 复制代码

bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --create --partitions 3 --replication-factor 1 --topic four

通过命令行修改副本是否成功？

分区是可以通过语句修改的，只能改多，不能改少，副本创建以后就不能直接修改了。

bash 复制代码

bin/kafka-topics.sh --bootstrap-server  bigdata01:9092 --alter --partitions 3 --replication-factor 3 --topic four 
没办法使用命令修改的。

2）手动增加副本存储

通过命令查看副本情况

（1）创建副本存储计划（所有副本都指定存储在 broker0、broker1、broker2 中）。

bash 复制代码

vi increase-replication-factor.json

添加如下内容：

bash 复制代码

{"version":1,"partitions":[{"topic":"four","partition":0,"replicas":[0,1,2]},{"topic":"four","partition":1,"replicas":[0,1,2]},{"topic":"four","partition":2,"replicas":[0,1,2]}]}

（2）执行副本存储计划。

bash 复制代码

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop11:9092 --reassignment-json-file increase-replication-factor.json --execute

查看副本情况：

四、文件存储

（一）文件存储机制

Topic 数据存储

Topic 是逻辑概念，partition 是物理概念，每个 partition 对应一个log文件，Producer 生产的数据追加到log文件末端。为防止log文件过大导致数据定位效率低下，Kafka 采用分片和索引机制，将每个 partition 分为多个 segment，每个 segment 包括.index文件、.log文件和.timeindex等文件，这些文件位于以topic名称+分区序号命名的文件夹下，如first - 0。

数据位置查找

启动生产者发送消息后，可以在/opt/installs/kafka3/datas/下对应主题分区文件夹中查看相关文件。直接查看log日志可能是乱码，可通过kafka-run-class.sh kafka.tools.DumpLogSegments命令查看index和log信息。Kafka 使用稀疏索引，这使得数据读取速度较快。

（二）文件清理策略

delete 日志删除

Kafka 中默认的日志（即 Segment）保存时间为 7 天，可通过log.retention.hours（最低优先级小时，默认 7 天）、log.retention.minutes（分钟，设置后小时设置不起作用）、log.retention.ms（最高优先级毫秒，设置后分钟设置不起作用）等参数修改保存时间。log.retention.check.interval.ms负责设置检查周期，默认 5 分钟。

delete 日志删除策略有基于时间（默认打开，以 segment 中所有记录中的最大时间戳作为该文件时间戳）和基于大小（默认关闭，超过设置的所有日志总大小，删除最早的 segment，log.retention.bytes默认等于 - 1，表示无穷大）两种方式。若一个 segment 中有部分数据过期，部分未过期，基于时间的删除策略会根据最大时间戳判断整个 segment 是否过期。

compact 日志压缩

log.cleanup.policy = compact启用压缩策略，对于相同 key 的不同 value 值，只保留最后一个版本。压缩后的 offset 可能不连续，这种策略适用于特殊场景，如消息的 key 是用户 ID，value 是用户资料等。

五、高效读写数据

分区技术与并行度

Kafka 本身是分布式集群，采用分区技术，提高了并行度，能够同时处理多个分区的数据，从而提升整体性能。

稀疏索引与快速定位

读数据采用稀疏索引，可以快速定位要消费的数据。与 MySQL 中索引过多会影响写入速度不同，Kafka 的稀疏索引在保证快速定位数据的同时，不会对写入性能造成过大影响。

顺序写磁盘

Kafka 的 Producer 生产数据时，写入log文件的过程是顺序写，即一直追加到文件末端。由于磁盘的机械结构特点，顺序写能大幅提高写入速度，官网数据表明，同样的磁盘，顺序写能达到 600M/s，而随机写只有 100K/s。

页缓存 + 零拷贝技术

零拷贝技术使得 Kafka 的数据加工处理操作交由生产者和消费者处理，Kafka Broker 应用层不关心存储的数据，无需经过应用层，提高了传输效率。

PageCache 页缓存功能被 Kafka 重度依赖。当有写操作时，操作系统将数据写入 PageCache；读操作时，先从 PageCache 中查找，找不到再从磁盘读取。这相当于将空闲内存作为磁盘缓存使用，进一步提升了读写性能。

六、总结

本文全面深入地探讨了 Kafka Broker 的各个方面，包括其工作流程、节点管理、副本机制、文件存储以及高效读写数据的原理和生产环境中的应用经验。理解这些知识对于在大数据项目中正确使用和优化 Kafka 具有极为重要的意义。无论是在构建实时数据处理管道还是大规模数据存储系统时，Kafka 的这些特性都能为我们提供可靠、高效的解决方案。在实际应用中，我们需要根据具体的业务需求和硬件环境，合理配置 Kafka 的各项参数，以充分发挥其优势，应对复杂的数据处理挑战。