Kafka源码分析(一) - 概述

系列文章目录

https://zhuanlan.zhihu.com/p/367683572

目录

• 系列文章目录
• 一. 实际问题
• 二. 什么是Kafka, 如何解决这些问题的
• 三. 基本原理
  • 1. 基本框架
  • 2. Topic
  • 3. Partition 和 Consumer Group
  • 4. Replica
  • 5. Broker & KafkaController
• 五. 源码结构
  • 1. 源码地址
  • 2. 目录结构
• 六. 总结

---

一. 实际问题

我们在业务开发的过程中，会涉及很多“事件驱动”的场景，比如：

1. 处理IoT设备上报的事件(如红外传感器检测到有人经过、温度传感器检测到温度变化等等)；
2. 实时监控金融用户的行为，识别可疑行为并作拦截处理；
3. 对微服务进行监控，实时上报服务的异常情况；

这些场景有一个共同的模式：有一个“事件源”、需要实时处理“事件序列”。

那么问题来了，事件源通过什么方式上报数据？上报来的事件数据如何存储？如何实时感知新事件的产生并作处理？于是，Kafka应运而生。

二. 什么是Kafka, 如何解决这些问题的

Kafka官方的定义是

Apache Kafka is an open-source distributed event streaming platform.

即一个开源的、分布式的事件流处理平台。起初由LinkedIn公司(没错，就是领英)研发，用于处理数据管道的问题。后LinkedIn将其贡献给了Apache基金会，成为Apache的顶级项目之一。

Kafka采用"Producer -> Server -> Consumer"的业务模型来解决上文提到的实际问题：

1. Producer：生产者，事件源通过该组件上报事件信息；
2. Server：对上报来的事件数据作持久化存储，并通过精心设计的机制保证高吞吐量；
3. Consumer：负责从Server端实时拉取事件数据，以执行相应的业务处理；

三. 基本原理

这里将通过“逐步引入”的方式向诸君阐述Kafka架构中的核心概念(基于Kafka 2.0版本)。更多细节将通过后续文章从源码层面给大家分析。

1. 基本框架

通过上文介绍，我们有了下图：

3类组件的职责不再赘述。

2. Topic

实际应用中，一个Kafka集群会承载很多类别的事件流。那么不同事件流之间如何作区分呢？实际上，Kafka使用"发布订阅模式"组织事件数据，为一类事件流分配一个主题(Topic)。Producer可将事件发到某个Topic下，Consumer可以订阅其感兴趣的Topic，从而可以处理对应的事件流。

3. Partition 和 Consumer Group

对于Kafka的目标场景，"高吞吐"是很必要的。而对于提高吞吐量，增加并行度是很常见的手段。在Kafka业务模型下体现在一个Topic允许多个Consumer同时消费数据。可是并行操作同一份数据的话，就需要完善的同步机制，而同步本身又不利于提高吞吐。所以，Kafka将一个Topic下的数据横向分成了多个"分区"(Partition)，而每个Partition只允许一个Consumer来消费。那么如何决定将一个Partition分给哪个Consumer呢？Kafka引入了ConsumerGroup的概念，即将订阅同一个Topic的多个Consumer打成"组"，然后在将Topic内的Parition通过一定的算法分配给组内的Consumer。

4. Replica

考虑一个问题，如果Parition对应的文件损坏，或者Partition所在机器下线，那是否就意味着这部分数据就丢失了？为了避免这类数据单点问题，Kafka引入了Replica(副本)的概念：

1. 一个Partition的数据会同时保存N份，即N个Replica；
2. Replica之间有"主从"之分，Producer将数据写入主Replica中，从Replica异步到主Replica拉数据以实现同步；
3. Producer在产生数据时可以指定acks参数，表示本次写入需要有多少个从Replica完成同步才视为成功；
4. 当主Replica损坏或宕机时，其中一个从Replica会被选举为主Replica；

5. Broker & KafkaController

到目前为止，我们都是将"服务端"视为一个整体，接下来就介绍下服务端节点组成。Kafka Server端有多个节点组成，每个节点都有一个名字叫Broker。其中一个Broker会被选举称为KafkaController，用于监测所有Broker的状态，发现故障后启动故障转移过程。例如，假设Broker_1上承载两个Replica，分别为Partition_1-1的主Replica和Partition_1-2的从Replica；若Broker_1宕机，KafkaController会将Broker_2上的Partition_1-1的从Replica提升为主Replica，使得集群可以继续对外提供服务。

五. 源码结构

1. 源码地址

• Kafka官方源码地址：https://github.com/apache/kafka
• 我也维护了一个"注释版"Kafka源码镜像，供诸君参考:
  
  https://github.com/Hao1296/kafka (见note-hao分支，基于Kafka 2.0)

2. 目录结构

Kafka核心目录如下：

• clients: 客户端实现源码，包括Producer和Consumer
• core: 服务站实现源码
• connect: connector实现源码，用于执行Kafka数据的导入/导出
• stream: 流式计算相关源码

六. 总结

本文作为Kafka源码分析系列文章的概述，宏观简要介绍了下Kafka的基本原理，没有深入。更多细节会在后续文章中逐个分析。Kafka源码分析系列文章目录: https://www.cnblogs.com/zhanghao2244/p/14701269.html，欢迎诸君随时交流。