Kafka 原理详解（详解在注释里面，图片加载需要时间）思维导图模板

消息队列实现方式

点对点模式：一对一

发布/订阅模式：一对多

push（推）模式

pull（拉）模式（kafka采用该方式）

架构图

组件构成

broker

一台 kafka 服务器就是一个 broker

一个kafka集群由多个 broker 组成

一个 broker 可以容纳多个 topic的多个partition

Topic（主题）

kafka将消息以topic为单位进行归类

在kafka集群中，可以有无数的主题

生产者和消费者消费数据一般以主题为单位。更细粒度可以到分区级别

一个topic 可以划分为多个partition，分布到多个 broker上管理

Partition（分区）

特征

topic是逻辑的概念，partition是物理的概念

每个partition由一个kafka broker服务器管理（即一个broker包含一个或多个partition）

partition 中的每条消息都会被分配一个递增的id（offset），每个 partition 是一个有序的队列，kafka 只保证按一个 partition 中的消息的顺序，不保证一个 topic 的整体（多个 partition 间）的顺序

每个partition都可以有多个副本

partition的表现形式就是一个一个的文件夹

每一个分区会有一个编号，编号从0开始

Partition的副本数

目的

保障 partition 的高可用

特征

leader replica分布

轮询算法

默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，否则报错，一般情况下等于broker的个数

follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）

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

follower通过拉的方式从leader同步数据

消费者和生产者都是从leader读写数据，不与follower交互

好处

对于 kafka 集群

实现topic数据的负载均衡

对于消费者

提高并发度，提高效率

Segment

特征

一个partition当中由多个segment文件组成

每个segment文件，包含两部分，一个是.log文件，另外一个是.index文件。

.log文件包含了发送的数据存储，.index文件记录的是.log文件的数据索引值，以便于加快数据的查询速度；

索引文件与数据文件的关系

索引文件中元数据指向对应数据文件中message的物理偏移地址

消息Message

字段的含义

Producer（生产者）

Consumer

Consumer Group

特征

同一个消费者组里的所有消费者不能同时消费消息，只能有一个消费者去消费

同一个消费者组里面是不会重复消费消息的

同一个消费者组的一个消费者不是以一条一条数据为单元的，是以分区（partition）为单元，就相当于消费者和分区建立某种socket，进行传输数据，所以，一旦建立这个关系，这个分区的内容只能是由这个消费者消费

模式转换

队列模型

发布-订阅模型

消息分流

注意

消费者数目及partition数目对应关系

partition数目 > 消费者数目

partition数目 = 消费者数目

partition数目 < 消费者数目

两个或多个消费者组

Group Coordinator

cluster、broker、topic、partition、消费者、费者组 关系

线程安全

Metadata

MetadataCache

topic 的详细信息

概括

元数据的作用

客户端

可以通过元数据获取服务地址，进行通信。（类似于服务发现）

服务端

可以通过元数据共享集群状态，一旦出现状态变化能够快速感知到，并且让各个 broker 快速更新元数据去保持一致。

Producer Metadata 的更新策略

1、 周期性的更新

2、失效检测，强制更新

如何触发

在 NetworkClient 的 poll() 方法调用时，就会去检查这两种更新机制，只要达到其中一种，就行触发更新操作

Metadata更新时特点

异步发送

负载选择

生产者

生产者缓存架构

主线程的逻辑

Sender 线程的逻辑

生产者拦截器 ProducerInterceptor

分类

生产者拦截器

自定义拦截器

序列化（Serializer）

分区器（Partitioner）

分区策略

分区作用

解决水平扩展的问题

解决消息顺序读取的问题

解决负载均衡的问题

键（key）的作用

ProducerRecord对象

key的作用

作为消息的附加信息

用来决定消息被写到主题的哪个分区中。拥有相同键的消息会被写到同一个分区中。

情况分类

情况一：键为空，不指定分区器

情况二：键为空，指定了分区器

partition方法

情况三：键不为空，指定了分区器

情况四：键不为空，没有指定分区器

分区策略

Partitioner接口

策略分类

BuiltInPartitioner（内置的默认分区器）：随机

nextPartition方法

DefaultPartitioner（默认分区器）- 已废弃

DefaultPartitioner核心逻辑

UniformStickyPartitioner（统一粘性分区器）- 已废弃

如何选择新的粘性分区

与DefaultPartitioner不同点

RoundRobinPartitioner（轮询分区器）

逻主要辑源码

不是真的轮询

自定义分区策略

实现Partitioner接口、partition方法

配置自定义分区策略

弃用默认分区器DefaultPartitioner

DefaultPartitioner策略

弃用的原因

分配倾斜

配倾斜出现的原因

linger.ms

举例

对粘性分区策略问题的优化方案

partitioner.class将具有默认值null

改进的主要变化

2.8.0版本的partition()方法逻辑

3.3.0版本partition()方法逻辑

消息累加器（优化点）

构成

结构图

消息缓存模型

ProducerBatch的内存大小

内存分配

ProducerBatch的创建和释放

1、内存16K，缓存池中有可用内存

2、内存16K，缓存池中无可用内存

3、内存非16K，非缓存池中内存够用

4、内存非16K 非缓存池内存不够用

消息累加器作用

减少网络传输的资源消耗

减少磁盘I/O资源消耗

消息累加器的结构

Sender线程

KafkaProducer.send()逻辑

生产者消息产生及发送流程

比较重要的生产者参数

acks

acks=1

acks=0

acks=-1/all

max.request.size

retries和retry.backoff.ms

max.in.flight.requests.per.connection

compression.type

connection.max.idle.ms

linger.ms（优化点）

receive.buffer.bytes&send.buffer.bytes

request.timeout.ms

问题和答案

发送消息的时候, 当Broker挂掉了，消息体还能写入到消息缓存中吗

当最新的ProducerBatch还有空余的内存，但是接下来的一条消息很大，不足以加上上一个Batch中，会怎么办呢？

那么创建ProducerBatch的时候，应该分配多少的内存呢？

消费者、消费者组

消费者组是什么

三个特性

Consumer Group 下可以有一个或多个Consumer 实例

Group ID 是一个字符串， 在Kafka集群中唯一标识Consumer Group

Consumer Group 下所有实例订阅主体的单个分区，只能分配给组内某个Consumer实例消费。同一个分区消息可能被多个Group 消费。

Kafka消费者组解决了哪些问题？（与传统消息系统比较）

消息队列模型伸缩性差

发布/订阅模型下伸缩性差

Consumer Group 之间彼此队里，互不影响

用Consumer Group机制，实现了传统两大消息引擎

分区策略（重点）

设置partition值需要考虑的因素

推荐partition的数量一定要大于等于同时运行的consumer的数量

建议partition的数量大于等于集群broker的数量

分配策略

RangeAssignor（范围）（默认分配策略）

分配

1、以topic为单位

2、先对topic下的partition进行排序

3、再对topic下的consumer进行排序

4、将partition依次分配给consumer

每个topic都会重复上面4步的分配流程

配置参数

如何进行计算分区

解析

举例

缺点

分区数和消费者数无法整除时会造成倾斜

RoundRobin（轮询）

两种情况

如果所有consumer实例的订阅是相同的，那么partition会均匀分布

如果同一消费者组内，所订阅的消息是不相同的，那么在执行分区分配的时候，就不是完全的轮询分配，有可能会导致分区分配的不均匀

配置参数

工作原理：TopicAndPartition组合给consumer均分

举例

由于分配时是按所有Partition来的，所以即使Topic之间Partition的数量是不平均的，分配结果也是基本平均的，克服了RangeAssignor的缺点

缺点

示例

consumer订阅信息不一致时造成分配不平衡

总结

使用RoundRobin策略有两个前提条件

同一个Consumer Group里面的所有消费者的num.streams（ 这个参数就是告诉 MirrorMaker 要创建多少个 KafkaConsumer 实例）必须相等

每个消费者订阅的主题必须相同

StickyAssignor(粘滞策略)

目标

1、分区的分配尽可能的均匀

2、分区的分配尽可能和上次分配保持相同

配置参数

示例一(消费者的订阅信息都是相同)

C1下线

采用RoundRobinAssignor策略

采用StickyAssignor策略

示例二(订阅信息不同的情况)

初始状态

采用RoundRobinAssignor策略

采用StickyAssignor策略

C0下线

采用RoundRobinAssignor策略(重新分配)

采用StickyAssignor策略

自定义分配策略

Coordinator-协调者

请求类型

组协调器

GroupCoordinator 的启动

Coordinator的确定与分区分配

1、确定consumer group位移信息写入__consumers_offsets这个topic的那个分区

2、该分区leader所在的broker就是被选定的coordinator

分区步骤

1、第1步就是找到这个coordinator，对于每1个consumer group，Kafka集群为其从broker集群中选择一个broker作为其coordinator。

2、找到coordinator之后，发送JoinGroup请求。

消费者加入组流程 JoinGroup

3、JoinGroup返回之后，发送SyncGroup，得到自己所分配到的partition

partition的分配策略和分配结果其实是由client决定的

组协调器同步流程 SyncGroup

heartbeat的实现原理

那这个定期发送如何实现呢？

是通过DelayedQueue来实现的

重平衡Rebalance

触发与通知

Rebalance 的触发条件

1、当 Consumer Group 组成员数量发生变化(主动加入或者主动离组，故障下线等)；

2、当订阅主题数量发生变化；

3、当订阅主题的分区数发生变化；

Rebalance 如何通知其他 consumer 进程？

靠 Consumer 端的心跳线程

协议 (protocol) 说明

Heartbeat请求

LeaveGroup请求

SyncGroup请求

JoinGroup请求

DescribeGroup请求

consumer group状态机

核心是 rebalance 操作

重平衡发生在 PreparingRebalance 和 AwaitingSync 状态机中

重平衡所涉及的参数

session.timeout.ms

heartbeat.interval.ms

max.poll.interval.ms

Rebalance Generation

重平衡场景举例

有新的成员加入消费组

消费组成员崩溃

消费组成员主动离开

消费组成员提交位移时

优缺点

优点

给消费者组带来了高可用性和伸缩性。

缺点

再均衡期间消费者无法读取消息，整个群组有一小段时间不可用

partition被重新分配给一个消费者时，消费者当前的读取状态会丢失，有可能还需要去刷新缓存，在它重新恢复状态之前会拖慢应用程序。因此需要进行安全的再均衡和避免不必要的再均衡

kafka 静态消费组成员（优化点）

为什么需要

基本原理

静态消费者情况下重平衡逻辑及注意事项

参数说明

group.instance.id

session.timeout.ms

问题

为什么在一个group内部，1个parition不能被多个consumer拥有？

时序性

offset

如果有多个客户端配置了不同的分配策略, 那么会以哪个配置生效呢？

1、选择所有 Member 都支持的分配策略；

2、在 1 的基础上，优先选择每个partition.assignment.strategy配置靠前的策略。

消费者消费并提交了之后，其他消费者是如何知道我已经消费了，从而不会重新消费的呢？

为什么要在consumer中选一个leader出来，进行分配，而不是由coordinator直接分配呢？

offset管理机制

位移保存

老版本(Kafka0.9版本之前)

保存在 ZooKeeper 中

好处

减少了 Kafka Broker 端的状态保存开销

服务器节点做成无状态的，这样可以自由地扩缩容，实现超强的伸缩性

缺点

ZooKeeper不适合进行频繁的写更新

新版本(从0.9版本开始)

位移保存在 Kafka内部主题的方法，也就是__consumer_offsets

broker无状态

那访问压力去哪了呢？

位移主题(Offsets Topic)

特征

__consumer_offsets 的主要作用是保存 Kafka 消费者的位移信息

它要求这个提交过程不仅要实现高持久性，还要支持高频的写操作

消息格式却是 Kafka 自己定义的，用户不能修改

Kafka Consumer 有 API 帮你提交位移

分区数

消息格式

key

Group ID，主题名，分区号

value

主要保存的是offset 的信息，当然还有时间戳等信息

offset 的分类

LogStartOffset

ConsumerOffset

HighWatermark

特征

在分区高水位以下的消息被认为是已提交消息，反之就是未提交消息。

位移值等于高水位的消息也属于未提交消息。也就是说，高水位上的消息是不能被消费者消费的。

主要作用

定义消息可见性，即用来标识分区下的哪些消息是可以被消费者消费的。

帮助 Kafka 完成副本同步

LogEndOffset

offset内部原理

原理图

位移提交

自动提交