1 of 87

Apache Kafka

(Kafka 简介)

Introduction of Kafka

2 of 87

Introduction

3 of 87

What Will We Cover Today?

What is Kafka (5 min)

Introduction
History

Why is Kafka (5 min)

linkedin team's initial problem

How does Kafka work (1hr)

Kafka Architecture Overview

Produce a message into Topic
Kafka, Partition
Consume a message from Topic
Zookeeper Overview

Q & A (20 min)

4 of 87

What Will We NOT Cover Today?

Kafka Installation
Kafka Configuration
Running Kafka
Details about Zookeeper

5 of 87

Future Goals

Deep Discussion of Each Kafka Components
Build a Real Kafka Project offline

6 of 87

Kafka: The Definitive Guide: Real-Time Data and Stream Processing at Scale

by : Neha Narkhede (Author),

Gwen Shapira (Author),

Todd Palino (Author)

https://www.amazon.com/dp/1491936169

7 of 87

Getting Started with Apache Kafka

by : Ryan Plant

https://www.pluralsight.com/courses/apache-kafka-getting-started

8 of 87

Kafka全套教程从源码到面试真题by海波

by : 尚硅谷IT培训学校

https://www.youtube.com/watch?v=HLSQDk2asjY&list=PLmOn9nNkQxJEDjzl0iBYZ3WuXUuUStxZl

9 of 87

Thanks

东哥IT笔记 https://donggeitnote.com/category/kafka/
尚硅谷IT培训学校 https://www.youtube.com/watch?v=19dzMtsV9pg
Kafka架构及基本原理简析 https://mp.weixin.qq.com/s/7ZT31OhDjn0kOkYZS_z0oA
Kafka: The Definitive Guide by Neha Narkhede Gwen Shapira Todd Palino
Getting Started with Apache Kafka https://www.pluralsight.com/courses/apache-kafka-getting-started
APACHE KAFKA QUICKSTART https://kafka.apache.org/quickstart
Kafka: Build, Deploy, and Monitor Your First Real-world Application https://www.pluralsight.com/courses/kafka-build-deploy-monitor-real-world-application
LinkedIn定制Kafka，每天处理7万亿条消息 https://blog.51cto.com/u_15057858/2680785
Kafka in a Nutshell https://sookocheff.com/post/kafka/kafka-in-a-nutshell/
Kafka学习笔记--kafka 概述、快速入门，架构深入 https://blog.51cto.com/u_15290941/3049322
Kafka Architecture and Its Fundamental Concepts https://data-flair.training/blogs/kafka-architecture/
Understanding about Kafka https://ducmanhphan.github.io/2020-05-15-Understanding-about-Kafka/
Top 10 Problems When Using Apache Kafka https://pandio.com/blog/top-10-problems-when-using-apache-kafka/
What is Apache Kafka https://www.youtube.com/watch?v=FKgi3n-FyNU
Why Kafka Is so Fast https://medium.com/swlh/why-kafka-is-so-fast-bde0d987cd03

10 of 87

Terminology

Distribution System, stream, Message, Queue, Event, Pub, Sub, Producer, Consumer, Topic, Broker, Partitions, Cluster, Consumer Group(CG), Leader follower, replica, offset, Zookeeper, MirrorMaker, controller, Serialization or Deserialization, Zero Copy

Producer：消息生产者，就是向 kafka broker 发消息的客户端；

Consumer：消息消费者，向 kafka broker 取消息的客户端；

Consumer Group(CG)：消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。同一个组的消费者之间时竞争关系，一个 partition 被一个消费者消费了，就不会被组内另一个消费者消费；

Broker：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。

Topic：可以理解为一个队列，生产者和消费者面向的都是一个 topic；

Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；分区提高 topic 并发，提高负载均衡能力；

Replica：副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。

leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。

follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 follower。

11 of 87

Question so far … ?

12 of 87

What is Kafka?

13 of 87

What is Kafka?

"Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications."

https://kafka.apache.org/

14 of 87

What is Kafka (Continue)?

LinkedIn Initial Development (2010)
Originally, Kafka was developed with Scala, but soon after, it switched to Java
now, Kafka is an Open Source project (under the Apache License, current stable version is 3.0.0)
The name "Kafka" is from Franz Kafka (a German-speaking Bohemian (波西米亚) novelist and short-story writer), nothing related kafka development. 卡夫卡的代表作品《变形记》

15 of 87

2010

LinkedIn Initial Development

2012

Apache License

2015 - now

Netflix, Uber, Spotify, etc.

2017

Apache Kafka 1.0

2018

Apache Kafka 2.0

Apache Kafka 3.0

History

2021

16 of 87

ource: https://www.pluralsight.com/courses/apache-kafka-getting-started

17 of 87

Why is Kafka?

18 of 87

source: https://www.pluralsight.com/courses/apache-kafka-getting-started

19 of 87

Pre-2010 3 High(高量值, 高峰值, 品种繁多)

High Volume:

Over 1.4 trillion messages per day
175 terabytes per day
650 terabytes of messages consumed per day
Over 433 million users

High Velocity:

Peak 13 million messages per second
2.75 gigabytes per second

High Variety:

Multiple RDBMS (Oracle, MySQL, etc.)
Multiple NoSQL (Espresso, Voldemort)
Hadoop, Spark, etc.

source: https://www.pluralsight.com/courses/apache-kafka-getting-started

20 of 87

4 Problems

Database Replication and Log Shipping

RDBMS to RDBMS only : Database-specific Tight coupling (schema)
Performance challenges (log shipping). etc …

Extract, Transform, and Load (ETL)

Typically proprietary and costly
Lots of custom development
Scalability challenged
Performance challenged
Often times requires multiple instances

source: https://www.pluralsight.com/courses/apache-kafka-getting-started

21 of 87

4 Problems (Continue)

Messaging

Scalability challenged
Smaller messages
Requires rapid consumption
Not fault-tolerant (application)

Middleware

Increasingly complex : Lots of custom development
Consistency concerns
Potentially expensive

source: https://www.pluralsight.com/courses/apache-kafka-getting-started

22 of 87

a Better Solution?

To move data around:

Cleanly
Reliably
Quickly
Autonomously

That’s What LinkedIn Asked in 2010…

23 of 87

Yes, Kafka

24 of 87

source: https://www.pluralsight.com/courses/apache-kafka-getting-started

25 of 87

source: https://www.pluralsight.com/courses/apache-kafka-getting-started

26 of 87

source: Kafka: https://www.pluralsight.com/courses/apache-kafka-getting-started

DB (example)

27 of 87

Better Solution

Kafka is a Better Solution

解耦
冗余
扩展性
灵活性 & 峰值处理能力
可恢复性
顺序保证 (Kafka 保证一个 Partition 内的消息的有序性)
缓冲
异步通信

28 of 87

How does Kafka work?

Kafka Architecture Overview

29 of 87

Kafka 详细架构图

source: https://www.youtube.com/watch?v=19dzMtsV9pg

1

2

3

4

1)Producer :消息生产者，就是向 kafka broker 发消息的客户端;

2)Consumer :消息消费者，向 kafka broker 取消息的客户端;

3)Consumer Group (CG):消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费;消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

4)Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。

5)Topic :可以理解为一个队列，生产者和消费者面向的都是一个 topic;

6)Partition:为了实现扩展性，一个非常大的 topic 可以分布到多个 broker(即服务器)上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列;

7)Replica:副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。

8)leader:每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。

9)follower:每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 follower

30 of 87

Message Queue

传统消息队列的应用场景

同步处理
异步处理

31 of 87

传统消息队列的应用场景

source: https://www.youtube.com/watch?v=19dzMtsV9pg

使用消息队列的好处

1)解耦允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

2)可恢复性系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

3)缓冲有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。

4)灵活性 & 峰值处理能力在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

5)异步通信很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们

32 of 87

Message Queue

消息队列实现原理

点对点模式 (一对一) ，消费者主动拉取数据，消息收到后消息清除
发布/订阅模式(一对多) ，数据生产后，推送给所有订阅者.

Kafka : 发布 producer / 订阅 Consumer

33 of 87

消息队列的2种模式(点对点模式)

source: https://www.youtube.com/watch?v=19dzMtsV9pg

34 of 87

消息队列的2种模式(发布/订阅模式)

source: https://www.youtube.com/watch?v=19dzMtsV9pg

35 of 87

Kafka 详细架构图

source: https://www.youtube.com/watch?v=19dzMtsV9pg

1

2

3

4

1)Producer :消息生产者，就是向 kafka broker 发消息的客户端;

2)Consumer :消息消费者，向 kafka broker 取消息的客户端;

3)Consumer Group (CG):消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费;消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

4)Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。

5)Topic :可以理解为一个队列，生产者和消费者面向的都是一个 topic;

6)Partition:为了实现扩展性，一个非常大的 topic 可以分布到多个 broker(即服务器)上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列;

7)Replica:副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。

8)leader:每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。

9)follower:每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 follower

36 of 87

Kafka 详细架构图

4 parts

Producer 生产消息
Kafka 管理消息
Consumer 消费消息
Zookeeper 注册消息

37 of 87

Producer, Consumer, Broker, Cluster, Message, Topic

Producer :消息生产者，就是向 kafka broker 发消息的客户端; (生产消息)
Consumer :消息消费者，向 kafka broker 取消息的客户端; (消费消息)
Broker : 一台 kafka 服务器就是一个 broker. ( 1 physic server can have more than 1 broker) (管理消息)
Cluster : 一个集群由多个 broker 组成。(一个 broker 可以容纳多个 topic;) (管理消息)
Message：通过Kafka集群进行传递的对象实体，存储需要传送的信息。
Topic: 每条发送到Kafka集群的消息都需要有一个指定的Topic

Producer :消息生产者，就是向 kafka broker 发消息的客户端;�Consumer :消息消费者，向 kafka broker 取消息的客户端;

Broker : 一台 kafka 服务器就是一个 broker。

Cluster : 一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic;

需要多少个broker ? ( we have a slide to talk about it)

Zookeeper : has metadata information

Message：通过Kafka集群进行传递的对象实体，存储需要传送的信息。

Topic：消息的类别，主要用于对消息进行逻辑上的区分，每条发送到Kafka集群的消息都需要有一个指定的Topic，消费者根据Topic对指定的消息进行消费。 Partition：消息的分区，Partition是一个物理上的概念，相当于一个文件夹，Kafka会为每个topic的每个分区创建一个文件夹，一个Topic的消息会存储在一个或者多个Partition中。 Segment：一个partition当中存在多个segment文件段（分段存储），每个Segment分为两部分，.log文件和 .index 文件，其中 .index 文件是索引文件，主要用于快速查询.log 文件当中数据的偏移量位置； .log文件：存放Message的数据文件，在Kafka中把数据文件就叫做日志文件。一个分区下面默认有n多个.log文件（分段存储）。一个.log文件大默认1G，消息会不断追加在.log文件中，当.log文件的大小超过1G的时候，会自动新建一个新的.log文件。 .index文件：存放.log文件的索引数据，每个.index文件有一个对应同名的.log文件。

38 of 87

source: https://www.pluralsight.com/courses/apache-kafka-getting-started

message

39 of 87

Kafka 详细架构图

source: https://www.youtube.com/watch?v=19dzMtsV9pg

1

2

3

4

消费者组是逻辑上的一个订阅者

1)Producer :消息生产者，就是向 kafka broker 发消息的客户端;

2)Consumer :消息消费者，向 kafka broker 取消息的客户端;

3)Consumer Group (CG):消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费;消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

4)Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。

5)Topic :可以理解为一个队列，生产者和消费者面向的都是一个 topic;

6)Partition:为了实现扩展性，一个非常大的 topic 可以分布到多个 broker(即服务器)上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列;

7)Replica:副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。

8)leader:每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。

9)follower:每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 follower

40 of 87

Kafka 工作流程(管理消息)

消费者组是逻辑上的一个订阅者

source: https://www.youtube.com/watch?v=19dzMtsV9pg

2

消费者组是逻辑上的一个订阅者

41 of 87

Kafka 文件存储机制

source: https://www.youtube.com/watch?v=19dzMtsV9pg

这些文件位于一个文件夹下

该文件夹的命名规则为:topic 名称+分区序号

逻辑上的区分

物理概念，相当于一个文件夹

由于生产者生产的消息会不断追加到 log 文件末尾，为防止 log 文件过大导致数据定位效率低下，Kafka 采取了分片和索引机制，将每个 partition 分为多个 segment。每个 segment 对应两个文件——“.index”文件和“.log”文件。这些文件位于一个文件夹下，该文件夹的命名规则为:topic 名称+分区序号。例如，first 这个 topic 有三个分区，则其对应的文件夹为 first- 0,first-1,first-2。Message：通过Kafka集群进行传递的对象实体，存储需要传送的信息。 Topic：消息的类别，主要用于对消息进行逻辑上的区分，每条发送到Kafka集群的消息都需要有一个指定的Topic，消费者根据Topic对指定的消息进行消费。 Partition：消息的分区，Partition是一个物理上的概念，相当于一个文件夹，Kafka会为每个topic的每个分区创建一个文件夹，一个Topic的消息会存储在一个或者多个Partition中。 Segment：一个partition当中存在多个segment文件段（分段存储），每个Segment分为两部分，.log文件和 .index 文件，其中 .index 文件是索引文件，主要用于快速查询.log 文件当中数据的偏移量位置； .log文件：存放Message的数据文件，在Kafka中把数据文件就叫做日志文件。一个分区下面默认有n多个.log文件（分段存储）。一个.log文件大默认1G，消息会不断追加在.log文件中，当.log文件的大小超过1G的时候，会自动新建一个新的.log文件。 .index文件：存放.log文件的索引数据，每个.index文件有一个对应同名的.log文件。Partition全局的第一个Segment从0开始，后续每个segment文件名为上一个Partition的最大offset（Message的offset，非实际物理地偏移地址，实际物理地址需映射到.log中，后面会详细介绍在.log文件中查询消息的原理）。数值最大为64位long大小，由20位数字表示，前置用0填充。

42 of 87

Kafka Segment .index 和 .log文件

source: https://www.youtube.com/watch?v=19dzMtsV9pg

物理磁盘上面实际的物理地址便宜量Position

“.index”文件存储大量的索引信息，“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中 message 的物理偏移地址。Kafka里面每一条消息都有自己的逻辑offset（相对偏移量）以及存在物理磁盘上面实际的物理地址便宜量Position，也就是说在Kafka中一条消息有两个位置：offset（相对偏移量）和position（磁盘物理偏移地址）在kafka的设计中，将消息的offset作为了Segment文件名的一部分。Segment文件命名规则为：Partition全局的第一个Segment从0开始，后续每个segment文件名为上一个Partition的最大offset（Message的offset，非实际物理地偏移地址，实际物理地址需映射到.log中，后面会详细介绍在.log文件中查询消息的原理）。数值最大为64位long大小，由20位数字表示，前置用0填充。

43 of 87

保存消息( Broker)

source: https://www.youtube.com/watch?v=19dzMtsV9pg

存储策略无论消息是否被消费，kafka 都会保留所有消息 inside broker。

存储方式

物理上把topic分成一个或多个 partition(对应 server.properties中的num.partitions配置)，每个partition物理上对应一个文件夹(该文件夹存储该 partition的所有消息.log 和索引文件 .index)

两种策略删除旧数据:

1)基于时间:log.retention.hours=168�2)基于大小:log.retention.bytes=1073741824�

需要注意的是，因为 Kafka 读取特定消息的时间复杂度为 O(1)，即与文件大小无关,所以这里删除过期文件与提高Kafka性能无关。

1)Producer :消息生产者，就是向 kafka broker 发消息的客户端;�2)Consumer :消息消费者，向 kafka broker 取消息的客户端;

3)Topic :可以理解为一个队列;�4)Consumer Group(CG):这是 kafka 用来实现一个 topic 消息的广播(发给所有的 consumer) 和单播(发给任意一个 consumer)的手段。一个 topic 可以有多个 CG。topic 的消息会复制 (不是真的复制，是概念上的)到所有的 CG，但每个 partion 只会把消息发给该 CG 中的一个 consumer。如果需要实现广播，只要每个 consumer 有一个独立的 CG 就可以了。要实现单播只要所有的 consumer 在同一个 CG。用 CG 还可以将 consumer 进行自由的分组而不需要多次发送消息到不同的 topic;�5)Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic;�6)Partition:为了实现扩展性，一个非常大的 topic 可以分布到多个 broker(即服务器)上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的 id(offset)。kafka 只保证按一个 partition 中的顺序将消息发给 consumer，不保证一个 topic 的整体(多个 partition 间)的顺序;

44 of 87

Kafka 生产过程分析(写入方式)

source: https://www.youtube.com/watch?v=19dzMtsV9pg

Producer 采用推(push)模式将消息发布到 Broker
每条消息都被追加(append)到分区(Partition)中，
属于顺序写磁盘(顺序写磁盘效率比随机写内存要高，保障 kafka 吞吐率)。

45 of 87

Producer写入流程

source: https://www.youtube.com/watch?v=19dzMtsV9pg

顺序写磁盘

零复制技术

46 of 87

Kafka 高效读写数据

顺序写磁盘
零复制技术

47 of 87

Why is kafka fast

Append-log to the disk : 顺序写磁盘, Kafka 的 producer 生产数据要写入到 log 文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到 600M/s，而随机写只有 100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

https://kafka.apache.org/081/documentation.html

48 of 87

Why is kafka fast (Continue)?

Zero Copy

49 of 87

Kafka 零复制技术

source: https://www.youtube.com/watch?v=19dzMtsV9pg

50 of 87

Replicas

Replica : 为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower
Leader : 生产者发送数据的对象，以及消费者消费数据的对象都是 leader
Followers : 实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 leader

51 of 87

Kafka 数据可靠性保证

source: https://www.youtube.com/watch?v=19dzMtsV9pg

Broker

52 of 87

Kafka 副本数据同步策略

source: https://www.youtube.com/watch?v=19dzMtsV9pg

为保证 producer 发送的数据，能可靠的发送到指定的 topic，topic 的每个 partition 收到 producer 发送的数据后，都需要向 producer 发送 ack(acknowledgement 确认收到)，如果 producer 收到 ack，就会进行下一轮的发送，否则重新发送数据

acks

The number of acknowledgments the producer requires the leader to have received before considering a request complete. This controls the durability of records that are sent. The following settings are allowed:

acks=0 If set to zero then the producer will not wait for any acknowledgment from the server at all. The record will be immediately added to the socket buffer and considered sent. No guarantee can be made that the server has received the record in this case, and the retries configuration will not take effect (as the client won't generally know of any failures). The offset given back for each record will always be set to -1.
acks=1 This will mean the leader will write the record to its local log but will respond without awaiting full acknowledgement from all followers. In this case should the leader fail immediately after acknowledging the record but before the followers have replicated it then the record will be lost.
acks=all This means the leader will wait for the full set of in-sync replicas to acknowledge the record. This guarantees that the record will not be lost as long as at least one in-sync replica remains alive. This is the strongest available guarantee. This is equivalent to the acks=-1 setting.

53 of 87

Kafka Partition

分区的原因
分区的原则

54 of 87

Kafka 生产过程分析(分区 Partition)

�

source: https://www.youtube.com/watch?v=19dzMtsV9pg

消息发送时都被发送到一个 topic，其本质就是一个目录，而 topic 是由一些 Partition Logs(分区日志)组成: 。

我们可以看到，每个 Partition 中的消息都是有序的，生产的消息被不断追加到 Partition log 上，其中的每一个消息都被赋予了一个唯一的 offset 值。

1)Producer :消息生产者，就是向 kafka broker 发消息的客户端;�2)Consumer :消息消费者，向 kafka broker 取消息的客户端;

3)Topic :可以理解为一个队列;�4)Consumer Group(CG):这是 kafka 用来实现一个 topic 消息的广播(发给所有的 consumer) 和单播(发给任意一个 consumer)的手段。一个 topic 可以有多个 CG。topic 的消息会复制 (不是真的复制，是概念上的)到所有的 CG，但每个 partion 只会把消息发给该 CG 中的一个 consumer。如果需要实现广播，只要每个 consumer 有一个独立的 CG 就可以了。要实现单播只要所有的 consumer 在同一个 CG。用 CG 还可以将 consumer 进行自由的分组而不需要多次发送消息到不同的 topic;�5)Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic;�6)Partition:为了实现扩展性，一个非常大的 topic 可以分布到多个 broker(即服务器)上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的 id(offset)。kafka 只保证按一个 partition 中的顺序将消息发给 consumer，不保证一个 topic 的整体(多个 partition 间)的顺序;

55 of 87

Kafka 生产过程分析(分区 Partition 2)

�

source: https://www.youtube.com/watch?v=19dzMtsV9pg

分区的原因

方便在集群中扩展，每个 Partition 可以通过调整以适应它所在的机器，而一个 topic 又可以有多个 Partition 组成，因此整个集群就可以适应任意大小的数据
可以提高并发，因为可以以 Partition 为单位读写了。Partition数量决定了最终并发量，因为一个Partition只能由一个Consumer进行消费。同一个Topic下的Partition数量越多，同一时间可以有越多的Consumer进行消费，消费的速度就会越快，吞吐量就越高

分区的原则

指定了 patition，则直接使用;
未指定 patition 但指定 key，通过对 key 进行 hash 出一个 patition;
patition 和 key 都未指定，使用轮询选出一个 patition。

1)Producer :消息生产者，就是向 kafka broker 发消息的客户端;�2)Consumer :消息消费者，向 kafka broker 取消息的客户端;

3)Topic :可以理解为一个队列;�4)Consumer Group(CG):这是 kafka 用来实现一个 topic 消息的广播(发给所有的 consumer) 和单播(发给任意一个 consumer)的手段。一个 topic 可以有多个 CG。topic 的消息会复制 (不是真的复制，是概念上的)到所有的 CG，但每个 partion 只会把消息发给该 CG 中的一个 consumer。如果需要实现广播，只要每个 consumer 有一个独立的 CG 就可以了。要实现单播只要所有的 consumer 在同一个 CG。用 CG 还可以将 consumer 进行自由的分组而不需要多次发送消息到不同的 topic;�5)Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic;�6)Partition:为了实现扩展性，一个非常大的 topic 可以分布到多个 broker(即服务器)上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的 id(offset)。kafka 只保证按一个 partition 中的顺序将消息发给 consumer，不保证一个 topic 的整体(多个 partition 间)的顺序;

56 of 87

57 of 87

Kafka 详细架构图

source: https://www.youtube.com/watch?v=19dzMtsV9pg

1

2

3

4

1)Producer :消息生产者，就是向 kafka broker 发消息的客户端;

2)Consumer :消息消费者，向 kafka broker 取消息的客户端;

3)Consumer Group (CG):消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费;消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

4)Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。

5)Topic :可以理解为一个队列，生产者和消费者面向的都是一个 topic;

6)Partition:为了实现扩展性，一个非常大的 topic 可以分布到多个 broker(即服务器)上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列;

7)Replica:副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。

8)leader:每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。

9)follower:每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 follower

58 of 87

Kafka Consumer

Consumer Group (CG) : Kafka中的每一个Consumer都归属于一个特定的Consumer Group，如果不指定，那么所有的Consumer都属于同一个默认的 CG
CG 由一个或多个Consumer组成,同一个CG 中的Consumer对同一条消息只消费一次
每个CG 都有一个唯一的ID，即Group ID，也称之为Group Name。
CG 内的所有Consumer协调在一起订阅一个Topic的所有Partition，且每个Partition只能由一个Consuemr Group中的一个Consumer进行消费，但是可以由不同的Consumer Group中的一个Consumer进行消费。

59 of 87

消息消费的并发量

Consumer就对应于Topic下的Partition, CG 中的Consumer数量和Topic下的Partition数量共同决定了消息消费的并发量
Partition数量决定了最终并发量，因为一个Partition只能由一个Consumer进行消费。
同一个Topic下的Partition数量越多，同一时间可以有越多的Consumer进行消费，消费的速度就会越快，吞吐量就越高
当一个Consumer Group中Consumer数量超过订阅的Topic下的Partition数量时，Kafka会为每个Partition分配一个Consumer，多出来的Consumer会处于空闲状态。当Consumer Group中Consumer数量少于当前定于的Topic中的Partition数量是，单个Consumer将承担多个Partition的消费工作。。同时，Consumer Group中的Consumer数量需要控制为小于等于Partition数量，且最好是整数倍：如1，2，4等。

60 of 87

Kafka 详细架构图

source: https://www.youtube.com/watch?v=19dzMtsV9pg

1

2

3

4

1)Producer :消息生产者，就是向 kafka broker 发消息的客户端;

2)Consumer :消息消费者，向 kafka broker 取消息的客户端;

3)Consumer Group (CG):消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费;消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

4)Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。

5)Topic :可以理解为一个队列，生产者和消费者面向的都是一个 topic;

6)Partition:为了实现扩展性，一个非常大的 topic 可以分布到多个 broker(即服务器)上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列;

7)Replica:副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。

8)leader:每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。

9)follower:每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 follower

61 of 87

Apache Zookeeper

Centralized service for maintaining metadata about a cluster of distributed nodes

Configuration information
Health status
Group membership Hadoop, HBase, Mesos, Solr, Redis, and Neo4j

Distributed system consisting of multiple nodes in an “ensemble”

62 of 87

Zookeeper 在 Kafka 中的作用

source: https://www.youtube.com/watch?v=19dzMtsV9pg

处于同步状态的副本叫做in-sync-replicas(ISR)

但不会在其他的broker中，另启动一个副本

Kafka 集群中有一个 broker 会被选举为 Controller，负责管理集群 broker 的上下线，所有 topic 的分区副本分配和 leader 选举等工作。 Controller 的管理工作都是依赖于 Zookeeper 的。

Kafka通过副本因子（replication-factor）控制消息副本保存在几个Broker（服务器）上，一般情况下副本数等于Broker的个数，且同一个副本因子不能放在同一个Broker中。副本因子是以分区为单位且区分角色；主副本称之为Leader（任何时刻只有一个），从副本称之为 Follower（可以有多个），处于同步状态的副本叫做in-sync-replicas(ISR)。 Leader负责读写数据，Follower不负责对外提供数据读写，只从Leader同步数据，消费者和生产者都是从leader读写数据，不与follower交互，因此Kafka并不是读写分离的。同时使用Leader进行读写的好处是，降低了数据同步带来的数据读取延迟，因为Follower只能从Leader同步完数据之后才能对外提供读取服务。如果一个分区有三个副本因子，就算其中一个挂掉，那么只会剩下的两个中，选择一个leader，如下图所示。但不会在其他的broker中，另启动一个副本（因为在另一台启动的话，必然存在数据拷贝和传输，会长时间占用网络IO，Kafka是一个高吞吐量的消息系统，这个情况不允许发生）。如果指定分区的所有副本都挂了，Consumer如果发送数据到指定分区的话，将写入不成功。Consumer发送到指定Partition的消息，会首先写入到Leader Partition中，写完后还需要把消息写入到ISR列表里面的其它分区副本中，写完之后这个消息才能提交offset。

63 of 87

Kafka 详细架构图

source: https://www.youtube.com/watch?v=19dzMtsV9pg

1

2

3

4

1)Producer :消息生产者，就是向 kafka broker 发消息的客户端;

2)Consumer :消息消费者，向 kafka broker 取消息的客户端;

3)Consumer Group (CG):消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费;消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

4)Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。

5)Topic :可以理解为一个队列，生产者和消费者面向的都是一个 topic;

6)Partition:为了实现扩展性，一个非常大的 topic 可以分布到多个 broker(即服务器)上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列;

7)Replica:副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。

8)leader:每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。

9)follower:每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 follower

64 of 87

Q & A

65 of 87

66 of 87

67 of 87

Kafka主要包含四个主要的API组件：

Producer API 应用程序通过Producer API向Kafka集群发送一个或多个Topic的消息。
Consumer API 应用程序通过Consumer API，向Kafka集群订阅一个或多个Topic的消息，并处理这些Topic下接收到的消息。
Streams API 应用程序通过使用Streams API充当流处理器（Stream Processor），从一个或者多个Topic获取输入流，并生产一个输出流到一个或者多个Topic，能够有效地将输入流进行转变后变成输出流输出到Kafka集群。
Connect API 允许应用程序通过Connect API构建和运行可重用的生产者或者消费者，能够把kafka主题连接到现有的应用程序或数据系统。Connect实际上就做了两件事情：使用Source Connector从数据源（如：DB）中读取数据写入到Topic中，然后再通过Sink Connector读取Topic中的数据输出到另一端（如：DB），以实现消息数据在外部存储和Kafka集群之间的传输。

https://mp.weixin.qq.com/s/7ZT31OhDjn0kOkYZS_z0oA

68 of 87

在kafka的设计中，将消息的offset作为了Segment文件名的一部分。Segment文件命名规则为：Partition全局的第一个Segment从0开始，后续每个segment文件名为上一个Partition的最大offset（Message的offset，非实际物理地偏移地址，实际物理地址需映射到.log中，后面会详细介绍在.log文件中查询消息的原理）。数值最大为64位long大小，由20位数字表示，前置用0填充。

https://mp.weixin.qq.com/s/7ZT31OhDjn0kOkYZS_z0oA

Segment 文件命名规则

69 of 87

https://mp.weixin.qq.com/s/7ZT31OhDjn0kOkYZS_z0oA

70 of 87

1.根据需要消费的下一个消息的offset，这里假设是7，使用二分查找在Partition中查找到文件名小于（一定要小于，因为文件名编号等于当前offset的文件里存的都是大于当前offset的消息）当前offset的最大编号的.index文件，这里自然是查找到了00000000000000000000.index。

2.在.index文件中，使用二分查找，找到offset小于或者等于指定offset（这里假设是7）的最大的offset，这里查到的是6，然后获取到index文件中offset为6指向的Position（物理偏移地址）为258。

3.在.log文件中，从磁盘位置258开始顺序扫描，直到找到offset为7的Message。至此，我们就简单介绍完了Segment的基本组件.index文件和.log文件的存储和查询原理。

但是我们会发现一个问题：.index文件中的offset并不是按顺序连续存储的，为什么Kafka要将索引文件设计成这种不连续的样子？这种不连续的索引设计方式称之为稀疏索引，

Kafka中采用了稀疏索引的方式读取索引，kafka每当.log中写入了4k大小的数据，就往.index里以追加的写入一条索引记录。

使用稀疏索引主要有以下原因：

(1)索引稀疏存储，可以大幅降低.index文件占用存储空间大小。

(2)稀疏索引文件较小，可以全部读取到内存中，可以避免读取索引的时候进行频繁的IO磁盘操作，以便通过索引快速地定位到.log文件中的Message

https://mp.weixin.qq.com/s/7ZT31OhDjn0kOkYZS_z0oA

71 of 87

7. Message Message是实际发送和订阅的信息是实际载体，Producer发送到Kafka集群中的每条消息，都被Kafka包装成了一个Message对象，之后再存储在磁盘中，而不是直接存储的。Message在磁盘中的物理结构如下所示:

其中key和value存储的是实际的Message内容，长度不固定，而其他都是对Message内容的统计和描述，长度固定。因此在查找实际Message过程中，磁盘指针会根据Message的offset和message length计算移动位数，以加速Message的查找过程。之所以可以这样加速，因为Kafka的.log文件都是顺序写的，往磁盘上写数据时，就是追加数据，没有随机写的操作。

72 of 87

Partition Replicas

73 of 87

Kafka通过副本因子（replication-factor）控制消息副本保存在几个Broker（服务器）上，一般情况下副本数等于Broker的个数，且同一个副本因子不能放在同一个Broker中。
副本因子是以分区为单位且区分角色；主副本称之为Leader（任何时刻只有一个），从副本称之为 Follower（可以有多个），处于同步状态的副本叫做in-sync-replicas(ISR)。
Leader负责读写数据，Follower不负责对外提供数据读写，只从Leader同步数据，消费者和生产者都是从leader读写数据，不与follower交互，因此Kafka并不是读写分离的。
同时使用Leader进行读写的好处是，降低了数据同步带来的数据读取延迟，因为Follower只能从Leader同步完数据之后才能对外提供读取服务。如果一个分区有三个副本因子，就算其中一个挂掉，那么只会剩下的两个中，选择一个leader，如下图所示。
但不会在其他的broker中，另启动一个副本（因为在另一台启动的话，必然存在数据拷贝和传输，会长时间占用网络IO，Kafka是一个高吞吐量的消息系统，这个情况不允许发生）。
如果指定分区的所有副本都挂了，Consumer如果发送数据到指定分区的话，将写入不成功。Consumer发送到指定Partition的消息，会首先写入到Leader Partition中，写完后还需要把消息写入到ISR列表里面的其它分区副本中，写完之后这个消息才能提交offset。

74 of 87

Distributed Systems

Collection of resources that are instructed to achieve a specific goal or function
Consist of multiple workers or nodes
The system of nodes require coordination to ensure consistency and progress towards a common goal
Each node communicates with each other through messages

75 of 87

76 of 87

77 of 87

78 of 87

79 of 87

80 of 87

81 of 87

需要多少个broker ?

一个 Kafka 集群需要多少个 broker 取决于以下几个因素:

首先，需要多少磁盘空间来保留数据，以及单个 broker 有多少空间可用。如果整个集群需要保留 10TB 的数据，每个 broker 可以存储 2TB，那么至少需要 5 个 broker。
如果启用了数据复制，那么至少还需要一倍的空间，不过这要取决于配置的复制系数是多少。也就是说，如果启用了数据复制，那么这个集群至少需要 10 个 broker。

82 of 87

Why is kafka fast (Continue)?

NO Serialization or Deserialization

83 of 87

Why does a DSP include?

Distributed Streaming Platform
Firstly, it can be used as a messaging system by using the publish/subscribe pattern.(Producers and Consumers ).
Second, Kafka can also be used for storing the data in a distributed way.
The last process is processing the events as they occur in the system by taking benefit of the streaming model. All the incoming events can be processed in almost real time.

84 of 87

Why does a DSP include (Continue)?

Firstly, it can be used as a messaging system by using the publish/subscribe pattern.
Producers create and publish the events to the messaging system
Consumers subscribe to those events and consume them.

85 of 87

Why does a DSP include?

Second, Kafka can also be used for storing the data in a distributed way.
It supports clustering, so data will be uniformly spread across systems, but it can also be replicated in case one of the systems fail, thus ensuring data will not be lost.

86 of 87

kafka vs. Hadoop

从另一个角度来看Kafka，我们会把它看成实时版的Hadoop.
Hadoop可以存储和定期处理大量的数据文件，而Kafka可以存储和持续处理大型的数据流。
从技术角度来看，它们有着惊人的相似之处，很多人将新兴的流式处理看成批处理的超集。
它们之间的最大不同体现在持续的低延迟处理和批处理之间的差异.
Hadoop和大数据主要应用在数据分析上，而Kafka因其低延迟的特点更适合用在核心的业务应用上。

87 of 87

kafka vs. ETL tools

从Kafka与ETL工具或其他数据集成工具之间也可以进行一番比较。
Kafka 和ETL工具都擅长移动数据.
它们最大的不同在于 Kafka 颠覆了传统的思维。Kafka 并非只是把数据从一个系统拆解出来再塞进另一个系统，它其实是一个面向实时数据流的平台。
它不仅可以将现有的应用程序和数据系统连接起来，它还能用于加强这些触发相同数据流的应用。