目录
一,简介
1.1 概念
1.2 特性
2,应用场景
二,原理
1,基本概念
1.7 Consumer Group(CG,消费者组)
2,工作机制
3,数据存储
4,高可用
4.1 多分区多副本 + Leader/Follower
文章内容来自:南京大学 / 星环科技课程,大数据理论与实践课程Ⅰ
对细节部分引用其他网络资源进行补充。
一,简介
1,什么是kafka
1.1 概念
基于发布/订阅的分布式消息系统
由Linkedin开发,用Scala编写
1.2 特性
消息持久化:采用时间复杂度O(1)的磁盘存储结构,即使TB级以上数据也能保证常数时间的访问速度
高吞吐:即使在廉价的商用机器上,也能达到单机每秒10万条消息的传输
高容错:多分区多副本
易扩展:新增机器集群无需停机,自动感知
同时支持实时和离线数据处理
2,应用场景
异步通信:将消息放入Kafka,可以不立即处理
应用解耦:在应用处理过程中插入一个隐含的、基于数据的接口层
流量消峰:关键应用能够顶住访问峰值,不会因超出负荷而崩溃
二,原理
1,基本概念
1.1 Broker(代理)
Kafka的一个实例或节点,一个或多个Broker组成Kafka集群
1.2 Topic(主题)
Topic是Kafka中同一类数据的集合(贴同一标签),相当于数据库中的表
Producer将同一类数据写入同一个Topic,Consumer从同一个Topic中读取同类数据
Topic是逻辑概念,只需指定Topic就可以生产或消费数据,不必关心数据的物理存储
1.3 Partition(分区)
分区是一个有序的、不可修改的消息队列,分区内消息有序存储
一个Topic可分为多个分区,相当于把一个数据集分成多份,分别存储不同的分区中
Parition是物理概念,每个分区对应一个文件夹,存储分区的数据和索引文件
1.4 Replication(副本)
一个分区可以设置多个副本,副本存储在不同的Broker中
1.5 Producer(消息生产者)
向Broker发布消息的客户端
1.6 Consumer(消息消费者)
从Broker消费消息的客户端
1.7 Consumer Group(CG,消费者组)
每个Consumer都隶属于一个特定的CG
对于Topic中的某一消息,不同的CG可以重复读取该消息(组间共享),但一个CG中只能有一个Consumer可以读取该消息(组内互斥)
1.8 Zookeeper
Kafka将主要的元数据保存在Zookeeper中
负责Kafka集群管理,包括配置管理、动态扩展、Broker负载均衡、Leader选举等
2,工作机制
2.1 整体运作机制:
2.2 Broker数据分布
消息在Broker中按Topic(主题)进行分类,相当于为每个消息打个标签
一个Topic可分为多个Partition(分区)
每个Partition可以有多个Replication(副本)
消息存储在Broker的某一Topic的某一Partition中,同时存在多个副本
2.3 Partition写入
Partition是一个FIFO队列, 发布消息采用在队列尾部追加的方式,消费消息采用在队列头部顺序读取的方式
一个Topic可分为多个Partition,仅保证同一分区内消息有序存储,不保证Topic整体(多个分区之间)有序
2.4 Topic数据消费
为了加快读取速度,多个Consumer可划分为一个组(Consumer Group, CG),并行消费同一个Topic
一个Topic可以被多个CG订阅,CG之间是平等的,即一个消息可同时被多个CG消费
一个CG可以有多个Consumer,CG中的Consumer之间是竞争关系,即一个消息在一个CG中只能被一个Consumer消费
3,数据存储
3.1 Segment(段文件)
Segment文件是Kafka的最小数据存储单元,一个Partition包含多个Segment文件
Segment文件由以消息在Partition中的起始偏移量命名的数据文件(*.log)和索引文件(*.index、*.timeindex)组成
每个Partition副本都是一个目录,目录中包含若干Segment文件
3.2 Offset(偏移量)
Offset是定位分区中消息的顺序编号
Offset用于在分区中唯一标识消息
推荐由Kafka(而不是Zookeeper)来存储和维护Offset,即在Broker中记录和重置每个Comsumer读取分区消息的偏移量。也可以选择由Zookeeper来存储和维护,但效率会有一定影响
3.3 Kafka索引
为了提高消息写入和查询速度,为每个Partition创建索引,索引文件存储在Partition文件夹下
- 偏移量索引
- 文件以offset偏移量为名称,以index为后缀索引数据格式:<offset, position>
- 采用稀疏存储方式
时间戳索引
- 文件以timeindex为后缀
- 索引数据格式:<timestamp, offset>
- 采用稀疏存储方式
4,高可用
4.1 多分区多副本 + Leader/Follower
Kafka早期版本没有Replication概念,一旦某个Brocker宕机,其上的分区数据就可能丢失
一个Topic可以有多个分区,每个分区可以有多个副本,副本存储在不同的Broker中
从一个分区的多个副本中选举一个Partition Leader,由Leader负责读写,其他副本作为Follower从Leader同步消息
4.2 双层选举
Controller Leader选举
- 每个Broker启动时都会创建一个Controller进程
- 通过Zookeeper,从Kafka集群中选举出一个Broker作为Controller Leader
- Controller Leader负责管理分区和副本状态,避免分区副本直接在Zookeeper上注册Watcher和竞争创建临时Znode,导致Zookeeper集群负载过重
Partition Leader选举
- Controller Leader负责Partition Leader的选举
- ISR列表(In Sync Replica)。ISR是Zookeeper中的候选分区副本同步列表,负责保存候选分区副本(Partition Follower)的状态信息
- Partition Leader负责跟踪和维护ISR
- Partition Follower定期从Leader同步数据,若Follower心跳超时或消息落后太多,将被移除出ISR
- Partition Leader挂掉后,Controller Leader从ISR中选择一个Follower作为新的Leader
标签:副本,06,分区,Partition,Broker,Kafka,Topic,Leader,分布式 From: https://blog.51cto.com/u_15849465/5803814