kafka 基础
2022-11-22 16:15:16 0 举报AI智能生成
kafka 基础知识点
作者其他创作
大纲/内容
消息生产者
采用推（push）模式将消息发布到broker，每条消息都被追加（append）到分区（patition）中，属于顺序写磁盘
Producer
Kafka服务器，负责消息存储和转发，一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
Borker
消息消费者
Consumer
保存着集群broker、topic、partition等meta数据
负责broker 故障发现，partition leader选举，负载均衡等功能
Zookeeper
角色
消息逻辑分组类别，Kafka按照topic来分类消息
Topic
topic的物理分区，一个 topic 可以包含多个 partition，topic消息保存在各个 partition上
实现扩展性，一个partition是一个有序的队列
Partition
Kafka采取了分片和索引机制，将每个partition分为多个segment
每个segment对应两个文件(*.index表示存放数据的索引，*.log表示存储的数据)
数据默认存储7天。其中的每一个消息都被赋予了一个唯一的offset值
segment
消息在日志中的位置，可以理解是消息在 partition上的偏移量，也是代表该消息的唯一序号
Offset
消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
Consumer Group
partition 的副本，保障 partition 的高可用（的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作）
一个topic的每个分区都有若干个副本，一个leader和若干个follower
Replica
replica 中的一个角色，每个分区多个副本的主， producer消费数据的对象 consumer发送数据的对象只跟 leader 交互
Leader
replica 中的一个角色，每个分区多个副本中的从，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个follower会成为新的follower
不和producer消费数据的对象 consumer发送数据的对象，不做数据读写
Follower
kafka 集群中的其中一个服务器，用来进行 leader election 以及 各种 failover
Controller
消息，通信的基本单位，每个producer可以向一个topic发布一些消息
Message
概念
架构
没有指定分区编号，没有指定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文件中，写的过程是一直追加到文件末端，为顺序写
顺序写磁盘
零拷贝技术
高效读写数据
Kafka集群中有一个broker会被选举为Controller
负责管理集群broker的上下线，所有topic的分区副本分配和leader选举等工作
Controller的管理工作都是依赖于Zookeeper的
选举过程
Zookeeper作用
单topic 单partition 单消费者
单topic 指定相同message key 已保证同 key 的消息能路由到相同的 partition 单消费者
顺序消费
是⼀个分布式、⽀持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统
简介
高吞吐量、低延迟
kafka集群支持热扩展
可扩展性
消息被持久化掉本地磁盘，并且支持数据备份防止数据丢失
持久性、可靠性
容错性
支持数千个客户端同时读写
高并发
特征
一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等
日志收集
解耦和⽣产者和消费者、缓存消息等
消息系统
Kafka经常被⽤来记录web⽤户或者app⽤户的各种活动，如浏览⽹⻚、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘
⽤户活动跟踪
Kafka也经常⽤来记录运营监控数据。包括收集各种分布式应⽤的数据，⽣产各种操作的集中反馈，⽐如报警和报告。
运营指标
比如spark streaming和storm
流式处理
适用场景
可靠性强（分布式-分区-副本）、扩展性强（可伸缩）、性能高（数据读写）、耐用性强（数据持久化）、时效性强。
优点
由于是批量发送，数据并非真正的实时。
仅支持统一分区内消息有序，无法实现全局消息有序
有可能消息重复消费
依赖zookeeper进行元数据管理
缺点
介绍
选举新的leader时，容忍n台节点的故障，需要n+1个副本
延迟高
全部完成同步，才发送ack
副本数据同步方案
网络延迟对Kafka的影响较小
方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，减少冗余
原因
数据可靠性
动态的in-sync replica (ISR) set，意为和leader保持同步的follower集合
当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。
如果follower长时间未向leader同步数据，则该follower将被踢出ISR
ISR
每个副本最大的offset
LEO
消费者能见到的最大的offset，ISR队列中最小的LEO
HW
follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了
follower故障
leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据
leader故障
故障处理
副本同步
producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据；
acks= 0
producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据；认为leader返回 信息就成功了
acks = 1
producer等待broker的ack，partition的leader和follower(ISR中的)全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。leader收到信息了返回ok，follower收到信息但是发送ACK时候leader故障，此时生产者会重新给follower发送个信息
acks = -1 或 acks = all
ACK 应答机制
时间：默认存储168小时（一周）
数据的大小：默认 -1 （不删除），可以自行设置
数据删除机制
broker
设置ack = all 或者 ack = -1
同步发送消息
设置retries重试次数
手动提交：enable.auto.commit=false
副本数大于等于3，replication.factor >= 3
min.insync.replicas>1
确保 replication.factor > min.insync.replicas
Broker
消息可靠性
kafka基础
0 条评论
回复 删除
下一页
