

首页  思维导图  详情



Kafka复习

2021-04-10 19:46:47   0  举报





AI智能生成

kafka知识点总结

kafka生产消费流程

Kafka

IO模型

kafka集群

模版推荐

作者其他创作

大纲/内容

producer

发送流程

1、用户线程封装消息到ProducerRecord

2、发送给partitioner确定目标分区，放入内存缓冲区

3、Sender线程从缓冲区中取出就绪消息封装成批次统一发送给对应的broker

发送方式

同步发送

异步发送+回调

异常

可重试异常

LeaderNotAvailableException

NotControllerException

NetworkException

不可重试异常

RecordTooLargeException

SerializationException

分区策略

根据key的hash值来选择目标分区

未指定分区时，采用轮训的方式分配

自定义分区策略

常见参数

acks

acks=0

acks=all或者-1

acks=1

buffer.memory

compression.type

retries

retry.backoff.ms

batch.size

linger.ms

max.request.size

request.timeout.ms

拦截器

onSend

onAcknowledgement

无消息丢失配置

producer端

max.block.ms=true

acks=all

retries=Integer.MAX_VALUE

max.in.flight.request.per.connection=1

broker端

unclean.leader.election.enable=false

replication.factory>=3

min.insync.replicas>1

replication.factory>min.insync.replicas

精准一次语义

幂等

事务

consumer

consumer分类

独立消费者

消费者组

一个消费者组有多个消费者实例

对于同一个group，topic的每条消息只能被发送到该group下的一个消费者实例

同一个topic消息可以被发送到多个group中

消息顺序性

位移（offset）

consumer group保存offset

位移提交

自动提交，默认5秒一次

手动提交

__consumer_offsets

分为50个offset文件目录

一个日志文件

.log

group.id+topic+partition:offset

两个索引文件

.index

.timeindex

定期压缩日志文件

消息交付语义

最多一次

最少一次（默认）

精准一次

其他位置信息

上次提交位移

当前位置

水位

日志终端位移

获取消息

常见参数

session.timeout.ms

max.poll.interval.ms

enable.auto.commit

fetch.max.bytes

max.poll.records

heartbeat.interval.ms

connections.max.idle.ms

rebalance

触发条件

1、组成员发生变更

新成员加入

成员崩溃

主动离场

2、组订阅topic发生变更

3、订阅topic的分区发生变更

分配策略：consumer进行分配

range

round-robin

sticky

generation

rebalance流程

确定coordinate，和提交topic确定partition一样，groupID的hashcode取模50，对应partition所在broker

加入组：所有组内consumer向coordinate发送加入请求，分配策略不兼容则剔除

coordinate转发所有成员信息给consumer leader

consumer leader定制分配方案，然后发送给coordinate

coordinate将每个consumer的分配方案抽取出来发给对应consumer

kafka为什么搞吞吐低延迟

大量使用操作系统的页缓存，内存操作速度快且命中率高

采用追加写入方式，顺序写入

零拷贝技术

kafka消息采用紧凑的字节数组保存

将消息仅写到页缓存中，之后由操作系统将页缓存中的消息刷到磁盘

常见概念

topic

partition

offset

replica

leader replica

follower replica

ISR

新旧版本变化

producer

1、发送过程由两个线程处理，用户线程将封装好的消息扔到缓冲区，Sender I/O线程将缓冲区消息分批次发给broker

2、异步发送，提供回调机制判断发送成功与否

3、分批机制，每个批次包括多个发送请求

4、更合理的分区策略，对于没有指定key的消息，采用轮训分区的方式分配，以免造成数据倾斜

consumer

1、旧版的消费位移依赖zookeeper管理，新版本的位移放在kafka的一个内部topic中

2、使用类似epoll的机制，一个线程管理连接多个broker的socket连接

3、消费者组的成员管理由zookeeper变成了coordinator

线上环境部署

磁盘容量规划

消息数

平均消息大小

消息留存时间

副本数

是否启用压缩

内存规划

尽量分配更多的内存给操作系统的页缓存

不要为broker设置过大的堆内存，最好不超过6GB

页缓存大小至少大于一个日志段的大小

带宽规划

多节点zookeeper

broker参数

unclean.leader.election.enable

log.retention

min.insync.replicas

num.network.threads

num.io.threads

message.max.bytes

JVM

CPU充足，要求低延迟：CMS

吞吐量优先：并行

jdk8：G1

系统参数

文件描述符：设置一个大值100000

Socket缓冲：64KB，跨区128KB

页缓存刷盘默认5秒，建议2分

各种选举

controller选举

分区leader选举

coordinate选举

consumer leader选举

broker

成员管理

ISR

位移信息

高水位值HW

日志终端位移LEO

follower与leader不同步原因

follower请求leader同步的速度小于leader接收消息的速度

follower进程卡住，例如FullGC

新创建的副本

不同步的标准

LEO更新机制

1、leader副本写入日志，leader LEO变为1

2、follower副本fetch请求leader，follower副本LEO=1

3、第二次fetch，remote LEO=1，HW=min(leader LEO,remote LEO)=1

4、follower HW=min(follower LEO,leader HW)=1

没有leader epoch时的缺陷

数据丢失：leader HW未全部同步到follower就挂了

数据不一致：leader HW未全部同步到follower就挂了，follower立即写入消息和重启后的leader HW一直

leader epoch

解决消息丢失

解决消息不一致

日志存储

日志段文件

日志索引文件

位移索引文件

相对位移

物理位移

时间戳索引文件

时间戳

相对位移

日志存留

基于时间的存留策略

基于大小的存留策略

日志压缩

controller

选举

1、先在zookeeper创建Controller节点成功的获选

2、其他节点监听zookeeper上的Controller节点

3、一旦Controller崩溃其他节点都会收到消息，再次开始竞选

controller职责

更新集群元数据到其他broker

zookeeper上面新建topic对应节点，Controller监听后为topic分区确定leader和ISR再广播出去

broker处理请求

一个acceptor线程监听连接，分配给processor

多个processor线程（默认3个）处理所分配的连接的IO操作，交给线程池任务队列

实际业务处理线程从池获取任务进行处理，默认8个

 Collect

Get Started

Kafka

 Collect

Get Started

KAFKA

 Collect

Get Started

Storm消费Kafka中的数据

 Collect

Get Started

kafka





0 条评论

下一页