Kafka常见知识点思维导图模板_ProcessOn思维导图、流程图

kafka是一种分布式消息引擎系统，主要功能是提供一套完整的消息发布和订阅的方案

整体框架

高吞吐，低延迟，高可用的原因

写入OS Cache，异步刷盘

追加文件末尾，顺序写入磁盘

零拷贝

分布式存储

多副本

ISR同步机制

概念

HW

高水位，即各个副本中最小的LEO，HW前的数据才是可以被消费的

LEO

下一条消息写入的偏移量

ISR

和Leader数据保持一致的副本列表

AR

全部副本列表

epoch

<Leader版本号，首条数据的offset>为了解决通过HW，LEO同步数据产生的数据丢失问题

producer

消息分发机制：key通过hash分区，指定分区，轮询分区

缓冲区：每个分区有多个batch，Sender线程 + batch批量发送，按照broker来聚合多个batch作为request

同步+异步

核心参数

acks

acks = 0：表示生产端发送消息后立即返回，不等待broker端的响应结果。通常此时生产端吞吐量最高，消息发送的可靠性最低

acks = 1: 表示leader副本成功写入就会响应Producer，而无需等待ISR（同步副本）集合中的其他副本写入成功。这种方案提供了适当的持久性，保证了一定的吞吐量。默认值即是1。

acks = all或-1: 表示不仅要等leader副本成功写入，还要求ISR中的其他副本成功写入，才会响应Producer。这种方案提供了最高的持久性，但也提供了最差的吞吐量。

max.request.size

最大消息大小，默认1M

retries

示生产端消息发送失败时的重试次数，默认值为0

compression.type

消息压缩方式，gzip、snappy、lz4 、zstd

buffer.memory

缓冲区的大小，默认值为32M

batch.size

batch批次大小，默认值为16KB

linger.ms

用来控制batch最大的空闲时间，超过该时间的batch也会被发送到broker端。默认值为0

request.timeout.ms

超时时间

min.insync.replicas

最小ISR副本数

broker

controller

抢占zk临时节点 |  raft协议

作用

选举Leader和ISR

同步元数据信息包括broker和分区的元数据信息

broker增删监听与处理

topic变化监听与处理

分区变化监听与变化处理

partition分区策略

Range分配策略

Round-robin分配策略

Sticky分配策略

Cooperative分配策略

可自定义分区

partition分配策略

在不考虑机架信息的情况下: 1. 第一个副本分区通过轮询的方式挑选一个broker，进行分配。该轮询从broker列表的随机位置进行轮询。  2. 其余副本通过增加偏移进行分配。

请求处理

broker端的多路复用模型的请求处理架构，自定义二进制协议

磁盘存储

os cache

零拷贝

文件

索引文件

普通索引&时间索引

稀疏索引，4kb生成一条索引

日志文件

定期清理

默认7天

副本同步机制

follower  fetch  leader数据，leader和follwer更新LEO和HW

副本选举分布机制

先到先得，谁在列表前谁就是leader，且各个副本leader均匀分布在各个机器上

Leader宕机，LEO最大的，在ISR中的为Leader

延时处理机制

时间轮

rebalance

rebalance触发条件

consumer 加入和退出

coordinator故障，集群选举出新的coordinator

topic的partition增加

consumer调用unsubscrible()，取消topic的订阅

rebalance优缺点

如何避免rebalance

consumer

消费模型

queue & PUB/SUB

consumer group：消费者组内有多个consumer，每个分区就给一个consumer

coordinator

__consumer_offsets默认50个副本，分区所在机器即为coordinator

JoinGroup -> leader consumer -> 下发分区方案 -> 状态机，三种分区策略

消费方式

poll()调用，单线程干所有的事情

核心参数

group id 

消费者组

enable.auto.commit

是否自动提交

auto.offset.reset

earliest 从头消费

latest 接收新消息

max.poll.records

一次poll返回消息的最大条数，默认是500条

auto.commit.interval.ms

每隔多久提交一次偏移量，默认5000ms

fetch.max.bytes

获取一条消息最大的字节数，默认1M

与其他消息中间件的区别

消息丢失

原因

生产者：出现网络故障等问题导致异步消息发送失败                ack = 1或0  没有等待副本相应

broker：副本配置的不正确导致没有持久化存储

消费者：拉到消息后，自动提交offset，服务宕机，消息未处理，导致消息丢失。

方案

生产者  ack = all  等待所有副本都有相应或者有retries=3重试机制

broker：保障每个分区都有多个副本降低丢失风险               修改broker异步刷盘的频率

消费者：手动提交offset，

消息重复

原因

生产者：设置了重试机制

消费者：自动提交offset

方案

生产者：开启幂等或者ack=all

消费者：手动提交或自己保障幂等

消息顺序性

原因

分区顺序：Kafka中的消息按照分区进行存储和分发，每个分区内的消息是有序的，但不同分区之间的消息顺序是无法保证的。如果消费者在多个分区上进行并行消费，并且不处理消息的顺序，那么消费顺序可能会混乱。

消费者并发度：当使用多个消费者并行消费同一个主题或分区时，消费者的并发度可能导致消息被处理的顺序变得混乱。

重试机制：如果消息处理失败后发生了重试，而重试的结果顺序与原始消息顺序不一致，那么就会导致乱序消费。

方案

单分区消费：将消费者限制为只消费单个分区，这样可以保证每个分区的消息都是按照顺序来的。但这种方式会降低消费的并发性能。

分区键：在生产者端发送消息时，使用带有相同分区键的消息，使其被分配到同一个分区中。这样可以确保具有相同分区键的消息在同一个分区内有序地被消费。

消息积压

发送过快或消费过慢

生产者：修改batch.memory  batch size增大缓冲区或增大批次，修改linger.ms 一般100ms 为了等待消息进入batch满了 

扩容：扩大分区和消费者，并且分区数和消费者数量相等

消费者：批量拉取处理

选举

broker controller 

旧版是注册zk节点    新版是基于raft 投票机制

partition leader

ISR中第一个

consumer coordinator

1、确定消费组位移信息写入__consumers_offsets的哪个分区。具体计算公式:  __consumers_offsets partition# = Math.abs(groupId.hashCode() % groupMetadataTopicPartitionCount)   注意:groupMetadataTopicPartitionCount 由 offsets.topic.num.partitions 指定，默认是50个分区。 2、该分区leader所在的broker就是组协调器。