首页  思维导图  详情



 



Kafka理论文件

2023-06-07 13:53:02   1  举报





Kafka

大数据

Kafka

kafka流程图逻辑脉络调用逻辑

模板推荐

作者其他创作

大纲/内容

Kafka概述

定义

Kafka是一个分布式的基于发布/订阅模式的消息队列，主要应用于大数据实时处理领域

消息队列解释

消息队列的应用

异步

消峰

解耦

消息队列的模式

点对点模式

一对一，消费者主动拉取数据，消息收到后消息清除

Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

图示

分支主题

发布/订阅模式

一对多，消费者消费数据之后不会清除消息

消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

图示

分支主题

Kafka基础架构

架构说明

Producer

Kafka cluster

broker0

TopicA-Partition0(leader)

TopicA-Partition1(follower)

broker1

TopicA-Partition1(leader)

TopicA-Partition2(follower)

broker2

TopicA-Partition2(leader)

TopicA-Partition0(follower)

Consumer

Group

Consumer

名词解释

Producer ：消息生产者，就是向kafka broker发消息的客户端；

Consumer ：消息消费者，向kafka broker取消息的客户端；

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

Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

Topic ：可以理解为一个队列，生产者和消费者面向的都是一个topic；

Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列；

Replica：副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。

leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。

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

Partition的Leader选举机制

依赖于zookeeper

为何要获得半数以上的选票才能成为leader

为了防止选出2个leader（防脑裂）

架构示意图

分支主题

Kafka的用途

日志收集

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

消息系统

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

用户活动跟踪

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

运营指标

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

流式处理

比如spark streaming和storm

事件源

kafka架构深入

Kafka工作流程及文件存储机制

Kafka工作流程

流程图示

分支主题

文件存储机制（Partition-log）

架构说明

Kafka消息基于topic分类，生产者消费者都是面向topic

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

每个partition对应一个log文件，log文件中存储producer的生产数据

Producer生产的数据会被不断追加到该log文件末端，且每条数据都有自己的offset。

由于生产者生产的消息会不断追加到log文件末尾，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制

将每个partition分为多个segment。每个segment对应两个文件——“.index”文件和“.log”文件

index和log文件以当前segment的第一条消息的offset命名。

“.index”文件存储大量的索引信息，“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中message的物理偏移地址。

Kafka文件图示

分支主题

Segment中index与log图示

概述

Segment的命名是以0开始,后续每个segment文件名为上一个全局partion的最大offset(偏移message数)

Segment

分支主题

Segment内部文件

分支主题

解说

3意味着在该Index中它处于第三个的位置，497意味着（position）这个消息的物理偏移地址

Partition中如何通过offset查找message

查找segment file（二分查找法定位具体文件）

定位具体segment file后根据offset获取Index元数据，通过Index元数据查找log文件中的物理偏移地址

Kafka生产者

分区策略

为什么要分区

方便在集群中扩展

Partition可以调整适应机器，从而适应任意大小的数据

可以提高并发

以Partition为单位读写

如何分区

指明Partition情况下，直接使用指明的值

未指明但有key的情况下，keyhash和topic的partition数取余

round-robin算法

既没有Partition有没有key时，随机生成整数自增与与topic的partition取余

数据可靠性保证

ack机制

概述：topic的每个partition收到producer发送的数据后，都向producer发送ack，收到则继续发送，未收到则重新发送

副本数据同步策略

全部Follower完成同步，才发送ack

原因

半数以上完成同步就发送ack，减少了isr的数量，因而在选举时无形增加了成本，造成了数据的冗余

延迟尚可

图示

分支主题

ack应答机制（可靠性参数配置）

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

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

-1

producer等待broker的ack，partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。

isr（in-sync replica set）

目的：处理迟迟不同步的follower

原理：长期不同步的follower被踢出ISR，通过时间阈值设定，leader若故障，选举新的leader

故障处理细节

概述

log文件中有HW和LEO

HW（High Watermark）

LEO（Log End Offset）

图示

分支主题

follower故障

先踢出，恢复后读取leader的LEO，重新加入

leader故障

ISR重新选举，各follower截掉高于HW的部分，从新leader同步数据

说明

这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复

Exactly Once语义

幂等性机制（idempotent）

无论发送几次，只落盘一次

idempotent + at least once = exactly once

如何使用

idempotent + at least once = exactly once

true

acks = -1

Kafka消费者

消费方式

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

因为push很难适应消费速率不同的消费者，但pull不足在于如果kafka没有数据，consumer会返回空数据

针对于上一点，kafka传入timeout，若无数据，consumer等待后再返回

分区分配策略

roundrobin

轮循消费者

range

总数做除法，前几分配给第一个consumer，以此类推

按Topic分配，容易造成数据倾斜

offset的维护

Kafka 0.9以前，consumer将offset保存在zookeeper中

Kafka0.9以后，保存在内置的topic中

Kafka高效读写机制

顺序写磁盘，一直追加在log文件的末尾

零复制技术

Linux的分层

application

kernel

hardware

图片示意

分支主题

利用零拷贝技术

图示

分支主题

Kafka的零复制技术

生产者序列化后直接存储，不解除序列化

Zookeeper在Kafka中的作用

Kafka Controller

管理broker的上下线

Topic的分区副本分配

leader选举

Kafka Controller依赖于Zookeeper

Leader选举机制举例

KafkaController监听Zookeeper

broker故障

Kafka Controller从Zookeeper获取ISR

Kafka Controller更新leader及ISR在zookeeper上

Kafka Controller的形成机制-先到先得

Kafka API

Producer API

Kafka Producer采用异步发送，有两个线程

main线程

封装ProducerRecord对象

拦截器（Interceptors）

序列化（Serializer）

分区（Partitioner）

线程共享变量RecordAccumulator

多个消息队列对应Topic的分区

累计批次或时间后进入Sender线程

Sender线程

Kafka Producer发送消息流程

分支主题

如何写Producer API

异步Kafka Producer

创建一个KafkaProducer对象

创建一个Properties对象

bootstrap.servers（集群地址）

key.serializer

value.serializer

retries

传参入kafka

通过ProducerRecord调用send方法

同步发送Kafka Producer

Consumer API

如何写Consumer API

自动提交

创建一个Properties对象

分支主题

通过ConsumerRecord调用poll方法

手动提交

创建一个Properties对象

分支主题

通过ConsumerRecord调用poll方法

分支主题

同步提交与异步提交的异同

相同点

将本次poll的一批数据最高的偏移量提交

不同点

同步阻塞，自动失败重试

异步不阻塞，没有失败重试

数据的重复和丢失

自定义维护offset

目的：防止数据漏提交和数据重复提交

自定义Interceptor

接口ProducerInterceptor

ProducerRecord

对ProducerRecord里的数据进行筛选

onAcknowledgement

在sender线程调用

可用来统计metadata成功次数和exception次数等

configure

 Collect

Get Started

Storm中消费Kafka中缓存日志示意图

 Collect

Get Started

KAFKA

 Collect

Get Started

Storm消费Kafka中的数据

 Collect

Get Started

架构 - MQ消息队列，rabbitmq，kafka





0 条评论

下一页