数据工匠记

在上一篇文章中，已经介绍了初始化 KafkaProducer 基本流程。当客户端对 KafkaProducer 完成完成后，可以调用 send() 方法将数据发送至kafka broker集群。图中描述了当客户端调用#send方法后的一系列逻辑处理。本文将主要对客户端发送消息的主要流程进行梳理，核心区域（元数据获取、分区操作、Re cordAccumlator、Sender线程唤醒）等核心代码会在后续的文章中单独分析。获取集群元数据当向broker中发送数据时，极其重要的一步是获取到集群的元数据信息

我们都知道kafka生产者Send一条记录并没有直接发送到kafka服务端，而是先将它保存到内存 (RecordAccumulator) 中，用于压缩之后批量发送，这里内存的创建和释放是比较消耗资源的，为了实现内存的高效利用，基本上每个成熟的框架或者工具都有一套内存管理机制，kafka的生产者使用 BufferPool 来实现内存 (ByteBuffer) 的复用。红色和绿色的总和代表 BufferPool 的总量，用totalMemory表示(由buffer.memory配置)；绿色代表可使用的空间，

kafka源码对 java 和 gradle 版本有适配要求，否则导入源码会编译不通过，笔者引用各版本如下。Kafka源码3.0java版本11grade版本7.4.1图解KafkaProducer流程源代码分析上图对 kafka 生产者初始化的整体流程进行了简单的梳理，接下来我们从代码层面对整体流程进行一个复原。源码导入idea后都会看到一个example工程包，这个包里面有生产者和消费者的例子，可以作为源码学习的切入口。在初始化生产者之前会设置一些配.

kafka 多副本Kafka 为分区引入了多副本（Replica）机制，通过增加副本数量可以提升容灾能力。同一分区的不同副本中保存的是相同的消息（当然在同一时刻，副本之间可能并非完全一样），副本之间是“一主多从”的关系，其中leader副本负责处理读写请求，follower副本只负责与leader副本的消息同步。副本处于不同的broker中，当leader副本出现故障时，从follower副本中重新选举新的leader副本对外提供服务。Kafka通过多副本机制实现了故障的自动转移，当Kafka集群中某个b

在Kafka2.8之前，Kafka强依赖zookeeper，2.8版本之后Kafka可以采用KRaft（Kafka Raft）模式，逐步去除对zookeeper的依赖（依然兼容）。在zookeeper中存储了很多kafka元数据信息, 例如 「Broker的注册信息」、「Topic的信息」 、 「运维操作临时信息 」、 「配置信息」等等其他信息。/brokers/topics/[topic]： 存储某个topic的partitions所有分配信息{ "version": "版本编号目前固定为数字.