这是我参与「第五届青训营」伴学笔记创作活动的第8天。本篇为第五届字节跳动青训营-寒假专场-后端基础课程的笔记。

基本认识

一个典型的 Kafka 体系架构包括若干 Producer、若干 Broker、若干 Consumer，以及一个 ZooKeeper 集群

概念解读

生产者，也就是发送消息的一方。生产者负责创建消息，然后将其投递到 Kafka 中。

消费者，也就是接收消息的一方。消费者连接到 Kafka 上并接收消息，进而进行相应的业务逻辑处理。

服务代理节点。对于 Kafka 而言，Broker 可以简单地看作一个独立的 Kafka 服务节点或 Kafka 服务实例。大多数情况下也可以将 Broker 看作一台 Kafka 服务。

Kafka 中的消息以 topic 题为单位进行归类，生产者负责将消息发送到特定的 topic ==(发送到 Kafka 集群中的每一条消息都要指定一个主题)==，而消费者负责订阅主题并进行消费。

分区。相较于topic只是逻辑上的概念，partition则是一个更加细化的划分。

主题是一个逻辑上的概念，它还可以细分为多个分区，一个分区只属于单个主题，很多时候也会把分区称为主题分区（Topic-Partition）。

在==存储层面==，分区可视为一个可以在后续进行追加的Log文件。消息在被追加到分区日志文件的时候都会分配一个特定的==分区内偏移量==（offset）。

当消息发送到broker前，会根据分区规则选择存储到哪个具体分区，如果规则合理，所有的消息都可以均匀地分配在不同的分区中。反之，会集中数据到一个分区中导致文件==所在的机器 I/O 将会成为这个主题的性能瓶颈==

每个消费者都有一个对应的消费组。当消息发布到主题后，只会被投递给订阅它的每个消费组中的一个消费者。

Pasted image 20230209222335.png

主题和分区都是提供给上层用户的抽象，Log 层面才有实际物理上的存在。

同时，分区引入了多副本机制（Replica）以容灾。一个分区对应的多个副本保存着不同的信息，呈现 one leader - multi followers 的结构。

leader 副本负责处理读写请求，follower 副本只负责与 leader 副本的消息同步。副本处于不同的 broker 中，当 leader 副本出现故障时，从 follower 副本中重新选举新的 leader 副本对外提供服务。

为了防止 Log 过大， Kafka 又引入了LogSegment 。

对应关系：

每次传输信息都要发生 IO，过于频繁会导致系统性能下降，可以通过批量传输的方式。
批量传输的数据会使得消息体大，此时可以通过压缩来减少信息大小。（支持多种压缩方案）
根据Broker 偏移量查找数据的时候采用的是二分法，直接找小于目标offset的对应日志文件。
broker 零拷贝：磁盘--内核态--用户态，这是传统拷贝必经过程，这样导致需要使用不同的buffer，同时也增加了不必要的传输，如果直接在内核的ReadBuffer读到数据后直接写网卡Buffer在让消费者消费，这将大大提升IO效率。