Kafka是大型架构的必备技能，下面我就重点详解Kafka实现原理@mikechen
Kafka实现原理
Kafka的核心实现，可以概括为“生产 – 存储 – 消费”三阶段。
如下图所示：
消息从生产者（Producer）产生，经过 Kafka 服务节点（Broker）存储，最终被消费者（Consumer）消费。
这三者各自独立又协同运作，构成Kafka高吞吐、高可靠的消息系统。
所以，你想更好的理想Kafka实现原理，就需要更进一步深入背后的技术实现。
Kafka实现原理（生产阶段）
Producer 的作用是将消息高效、可靠地发送到 Kafka 的指定 Topic 中。
其实现原理主要包括以下几个方面：
Producer 首先将应用程序的数据，按照预定的消息格式进行封装。
为了在网络上传输、和在 Broker 端存储，消息需要被序列化成字节流。
Producer 可以选择不同的序列化方式，如 JSON、Avro、Protocol Buffers …等。
然后，Producer 需要决定将消息发送到哪个 Topic 的哪个 Partition。
Kafka 提供了多种分区策略：
- 默认策略（轮询）： 如果消息没有指定 Key，Producer 会采用轮询的方式将消息均匀地发送到 Topic 的各个 Partition。
- 基于 Key 的哈希： 如果消息指定了 Key，Producer 会对 Key 进行哈希运算，然后将结果与 Partition 的数量取模，从而将具有相同 Key 的消息发送到同一个 Partition。
- 自定义分区策略： Producer 可以实现自定义的分区器（Partitioner）接口，根据业务需求实现更复杂的分区逻辑。
为了提高吞吐量，Producer 通常不会为每条消息都建立和发送网络请求，而是将多条消息缓存在内存中，形成一个消息批次（Batch）。
批处理的优势，减少了网络请求的次数，降低了 Broker 端的处理开销，显著提升了发送效率。
Kafka实现原理（存储阶段）
Kafka Broker 是核心服务器组件，负责接收生产者数据、存储日志、处理消费者请求等。
Broker 负责维护集群的元数据信息，包括 ：Topic 的列表、每个 Topic 的 Partition 数量。
以及，每个 Partition 的副本信息以及 Leader 和 Follower 的分配情况。
在传统的 Kafka 版本中，这些元数据存储在 ZooKeeper 中。
而在引入 KRaft 模式后，元数据直接存储在 Broker 内部。
Kafka 将每个 Partition 的消息存储在一个称为 Log 的文件中。
为了方便管理和清理，Log 被分割成多个大小相等的段（Segment），每个 Segment 文件都包含实际的消息数据。
消息在 Segment 文件中按照接收的顺序追加写入（顺序写磁盘），这极大地提高了写入性能。
Kafka实现原理（消费阶段）
Kafka Consumer 负责从 Broker 中拉取消息并处理，是数据消费端的关键组成部分。
如下图所示：
Consumer 总是属于一个 Consumer Group，Kafka 通过 Consumer Group 实现消息的并行消费、和负载均衡。
同一个 Topic 的每个 Partition ，只能被同一个 Consumer Group 内的一个 Consumer 实例消费。
Consumer 通过定期，向分配给自己的 Partition 的 Leader Broker 发送请求来拉取消息。
Broker 会根据 Consumer 的请求，从本地磁盘读取消息并发送给 Consumer。