Kafka常见知识点

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

整体框架

写入OS Cache，异步刷盘

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

零拷贝

分布式存储

多副本

ISR同步机制

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

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

HW

下一条消息写入的偏移量

LEO

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

ISR

全部副本列表

AR

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

epoch

概念

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

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

同步+异步

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

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

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

acks

最大消息大小，默认1M

max.request.size

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

retries

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

compression.type

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

buffer.memory

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

batch.size

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

linger.ms

超时时间

request.timeout.ms

最小ISR副本数

min.insync.replicas

核心参数

producer

抢占zk临时节点 |  raft协议

选举Leader和ISR

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

broker增删监听与处理

topic变化监听与处理

分区变化监听与变化处理

作用

controller

Range分配策略

Round-robin分配策略

Sticky分配策略

Cooperative分配策略

可自定义分区

partition分区策略

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

partition分配策略

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

请求处理

os cache

普通索引&时间索引

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

索引文件

日志文件

文件

默认7天

定期清理

磁盘存储

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

副本同步机制

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

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

副本选举分布机制

时间轮

延时处理机制

consumer 加入和退出

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

topic的partition增加

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

rebalance触发条件

rebalance优缺点

如何避免rebalance

rebalance

broker

queue & PUB/SUB

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

消费模型

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

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

coordinator

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

消费方式

消费者组

group id 

是否自动提交

enable.auto.commit

earliest 从头消费

latest 接收新消息

auto.offset.reset

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

max.poll.records

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

auto.commit.interval.ms

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

fetch.max.bytes

consumer

与其他消息中间件的区别

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

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

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

原因

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

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

消费者：手动提交offset，

方案

消息丢失

生产者：设置了重试机制

消费者：自动提交offset

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

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

消息重复

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

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

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

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

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

消息顺序性

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

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

消费者：批量拉取处理

发送过快或消费过慢

消息积压

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

broker controller 

ISR中第一个

partition leader

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

consumer coordinator

选举

Kafka