首页  思维导图  详情

kafka 基础

2022-11-22 16:15:16   0  举报





AI智能生成

kafka 基础知识点

kafka

中间件

订阅发布

作者其他创作

大纲/内容

架构

角色

Producer

消息生产者

采用推（push）模式将消息发布到broker，每条消息都被追加（append）到分区（patition）中，属于顺序写磁盘

Borker

Kafka服务器，负责消息存储和转发，一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

Consumer

消息消费者

Zookeeper

保存着集群broker、topic、partition等meta数据

负责broker 故障发现，partition leader选举，负载均衡等功能

概念

Topic

消息逻辑分组类别，Kafka按照topic来分类消息

Partition

topic的物理分区，一个 topic 可以包含多个 partition，topic消息保存在各个 partition上

实现扩展性，一个partition是一个有序的队列

segment

Kafka采取了分片和索引机制，将每个partition分为多个segment

每个segment对应两个文件(*.index表示存放数据的索引，*.log表示存储的数据)

数据默认存储7天。其中的每一个消息都被赋予了一个唯一的offset值

Offset

消息在日志中的位置，可以理解是消息在 partition上的偏移量，也是代表该消息的唯一序号

Consumer Group

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

Replica

partition 的副本，保障 partition 的高可用（的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作）

一个topic的每个分区都有若干个副本，一个leader和若干个follower

Leader

replica 中的一个角色，每个分区多个副本的主， producer消费数据的对象 consumer发送数据的对象只跟 leader 交互

Follower

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

不和producer消费数据的对象 consumer发送数据的对象，不做数据读写

Controller

kafka 集群中的其中一个服务器，用来进行 leader election 以及各种 failover

Message

消息，通信的基本单位，每个producer可以向一个topic发布一些消息

生产者

生产数据到分区方式

没有指定分区编号，没有指定key时采用轮询方式存储数据

没有指定分区编号，指定key时，数据分发策略为对key求取hash值，这个值与分区数量取余，余数就是分区编号

指定分区编号，所有数据输入到指定的分区内

自定义分区

消费者

消费方式

consumer采用pull模式从broker中读取数据

分区分配策略

范围分区RangeAssignor

轮询分区RoundRobinAssignor

粘性分区StickyAssignor

同一个消费者组内

一个消费者可以消费多个分区

一个分区只能被一个消费者消费

消费数据的流程

1、首先Consumer连接指定的Topic partition所在leader broker，使用折半/二分查找，先确定数据所在的segment

2、确定在哪个segment后，使用确定的segment内的index文件找到数据具体的位置采用pull方式从kafkalogs中获取消息

高效读写数据

分布式

分布式的并发读写数据

顺序写磁盘

producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写

零拷贝技术

Zookeeper作用

Controller

Kafka集群中有一个broker会被选举为Controller

负责管理集群broker的上下线，所有topic的分区副本分配和leader选举等工作

Controller的管理工作都是依赖于Zookeeper的

选举过程

顺序消费

单topic 单partition 单消费者

单topic 指定相同message key 已保证同 key 的消息能路由到相同的 partition 单消费者

介绍

简介

是⼀个分布式、⽀持分区的（partition）、多副本的
（replica），基于zookeeper协调的分布式消息系统

特征

高吞吐量、低延迟

kafka每秒可以处理几十万条消息，它的延迟最低只在几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作

可扩展性

kafka集群支持热扩展

持久性、可靠性

消息被持久化掉本地磁盘，并且支持数据备份防止数据丢失

容错性

允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）

高并发

支持数千个客户端同时读写

适用场景

日志收集

一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等

消息系统

解耦和⽣产者和消费者、缓存消息等

⽤户活动跟踪

Kafka经常被⽤来记录web⽤户或者app⽤户的各种活动，如浏览⽹⻚、
搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过
订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖
掘

运营指标

Kafka也经常⽤来记录运营监控数据。包括收集各种分布式应⽤的数据，⽣产
各种操作的集中反馈，⽐如报警和报告。

流式处理

比如spark streaming和storm

优点

可靠性强（分布式-分区-副本）、扩展性强（可伸缩）、性能高（数据读写）、耐用性强（数据持久化）、时效性强。

缺点

由于是批量发送，数据并非真正的实时。

仅支持统一分区内消息有序，无法实现全局消息有序

有可能消息重复消费

依赖zookeeper进行元数据管理

数据可靠性

副本数据同步方案

全部完成同步，才发送ack

优点

选举新的leader时，容忍n台节点的故障，需要n+1个副本

缺点

延迟高

原因

网络延迟对Kafka的影响较小

方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，减少冗余

副本同步

ISR

动态的in-sync replica (ISR) set，意为和leader保持同步的follower集合

当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。

如果follower长时间未向leader同步数据，则该follower将被踢出ISR

LEO

每个副本最大的offset

消费者能见到的最大的offset，ISR队列中最小的LEO

故障处理

follower故障

follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了

leader故障

leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据

ACK 应答机制

acks= 0

producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据；

acks = 1

producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据；认为leader返回信息就成功了

acks = -1 或 acks = all

producer等待broker的ack，partition的leader和follower(ISR中的)全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。leader收到信息了返回ok，follower收到信息但是发送ACK时候leader故障，此时生产者会重新给follower发送个信息

broker

数据删除机制

时间：默认存储168小时（一周）

数据的大小：默认 -1 （不删除），可以自行设置

消息可靠性

生产者

设置ack = all 或者 ack = -1

同步发送消息

设置retries重试次数

消费者

手动提交：enable.auto.commit=false

Broker