Kafka 入门知识，看这一篇就够了（上）_kafka入门，金三银四Linux运维高级工程师面试题整理

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Linux运维全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上运维知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注运维）

正文

最近在学习 Kafka（别问，问就是公司在用 ），将学习过程中的笔记整理出来分享给大家，就当是入入门

01 初识 Kafka

Kafka 最早是由 LinkedIn 公司开发的，作为其自身业务消息处理的基础，后 LinkedIn 公司将Kafka 捐赠给 Apache，现在已经成为 Apache 的一个顶级项目了

Kafka 作为一个高吞吐的分布式的消息系统，目前已经被很多公司应用在实际的业务中了，并且与许多数据处理框架相结合，比如 Hadoop，Spark 等

与传统的消息队列相比（RaabitMQ、RocketMQ等）除了异步、消峰、解耦三大经典场景之外，Kafka 有着更多的适用场景：

1. Kafka 被设计为一个分布式系统，便于向外拓展
2. Kafka 支持高吞吐量
3. Kafka 可以将消息持久化到磁盘，因此可以用于批量消费

Kafka 角色

• 生产者（producer）：也叫发布者，负责创建消息
• 消费者（consumer）：也叫订阅者，负责消费（读取）消息
• Kafka server（broker）：producer 和 consumer 都是 Kafka 的 客户端，Kafka 服务端通常被称作 broker

02 topic & partition

Kafka 是发布/订阅模型，消息以 topic 来分类，每一个 topic 都对应一个消息队列，订阅这个 topic 的 consumer 都会能够消费到对应的消息

为了提高吞吐量，实现 topic 的负载均衡，Kafka 在 topic 下又引用了分区（partition）的概念，能够大大提高消费速率

例如某个 topic 下有 n 个队列，那么这个 topic 的并发度就提高 n，同时可以支持 n 个 consumer 并行消费该 topic 中的消息

对于每一个 topic ，Kafka 会维护其 partition 下的 log，如下图所示

每一个 patition 都是一个顺序的、不可变的消息队列，并且可以持续地添加。patition 中的消息都被分配了一个唯一的序列号，也叫做偏移量（offset）

这就会导致 Kafka 是没有办法删除消息的，Kafka 会保持所有的消息，无论消息是否被消费，保持到它们过期

实际上 consumer 只是拥有 offset，正常情况当 consumer 消费消息的时候，offset 也线性的的增加，consumer 可以将 offset 重置为更老的一个 offset，重新读取消息

因为每一个 consumer 对应一个 partition，所以不会影响其他 consumer 的操作

PS：topic 是逻辑上的概念，消息真正是存储到 partition 中去的

03 Kafka 分布式

Kafka 一开始就被设计成了分布式的架构，有集群（cluster）的概念

一个 Kafka 服务器被称为 broker，broker 接收 producer 的消息并存入磁盘，consumer 连接 broker 消费消息

若干个 broker 组成一个 cluster，集群内某个 broker 会成为集群控制器（cluster controller），负责管理集群，包括分配分区给 broker，监控 broker 等

在 cluster 中，一个分区由一个 broker 负责，这个 broker 是这个分区中的 leader，当然一个分区可以被复制到多个 broker 上实现冗余

当broker出现故障时还可以将其分区重新分配到其他的broker上，保证高可用性

Kafka是如何实现数据冗余的呢？

为了实现数据冗余，保证业务的高可用性，Kafka 引入了副本的概念

在 Kafka 集群里，副本有两种角色：

1、对外提供读写服务的称之为 leader；

2、不对外提供读写服务的称之为 follower，follower 会去同步 leader 的数据以此来保证数据一致性

Kafka 会尽量的把 partition 的副本均分在不同的 broker 上，并从中挑选一个作为 leader 副本

如上图所示：每个 broker 有两个主题，每个主题有两个分区，每个分区有一个副本，分别在不同的 broker 上

只要还存在一个副本，那么 producer 提交的数据就不会丢失，如果某些副本落后于 leader 副本，那么落后的副本就会被移出

如果 leader 副本所在的主机宕机，那么集群就会从剩余的 follower 副本中重新挑选一个副本作为新的 leader 副本，但不是所有的 follower 都有资格去竞选 leader 的（有些数据落后于 leader 太多的 follower 是不能参加竞选的）

为了能够更好地管理副本，Kafka 引入了 ISR——Kafka 动态维护的一组同步副本集合

每个 topic 下的 partition 都有自己的 ISR 列表，ISR 中所有的 follower 都与 leader 保持同步状态，而且 leader 也在 ISR 列表中，只有在自己 ISR 列表中的副本才能参与 leader 竞选

ISR 中的副本是如何保持同步的呢？

每个 partition 的副本中都会维护三个位移量：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注运维）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
注运维）**
[外链图片转存中…(img-fyhbfq9Z-1713340973948)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！