Kafka源码分析(一) - 概述

系列文章目录

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

一. 实际问题

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

  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. 源码地址

2. 目录结构

Kafka核心目录如下:

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

六. 总结

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,509评论 6 504
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,806评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,875评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,441评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,488评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,365评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,190评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,062评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,500评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,706评论 3 335
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,834评论 1 347
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,559评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,167评论 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,779评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,912评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,958评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,779评论 2 354