Kafka_01_Kafka初识

Kafka_01_Kafka初识

Kafka

Kafka : ZooKeeper协调的分布式消息系统

  1. 基于Scala语言编写的高性能、多分区、多副本
  2. Kafka高性能的原因:页缓存、顺序IO、零拷贝

具有以下特性:

  1. 消息中间件: 系统解耦、冗余存储、流量消峰、异步通信等
  2. 存储系统: 通过消息持久化和多副本机制实现消息落盘
  3. 流处理: 为流式处理框架提供可靠的数据来源和库

Kafka组成: 若干个Producer、Consumer、Broker和ZooKeeper集群

  1. Producer(生产者): 生产并发送消息到Broker(推送)
  2. Consumer(消费者): 从Broker订阅并消费消息(拉取)
  3. Broker(服务代理节点): 将从Producer收到的消息进行落盘
  4. ZooKeeper集群:管理Kafka集群的元数据

// Broker可看成单个独立的Kafka服务实例, 多个Broker组成个Kafka集群

如: Kafka集群构成

基础概念

主题 (Topic): Kafka中消息归类单位

  1. Topic并不实际存在(仅逻辑上的概念)
  2. Topic可细分为多个Partition, 但Partition仅属于单个Topic
  3. 功能: Producer将消息发送到特定Topic, Consumer订阅Topic消费消息

分区 (Partition): 组成Topic的单位(实际存储消息)

  1. Partition在存储层面可视为: 可被追加的日志文件
  2. 同一Topic下的不同Partition包含的消息是不同的
  3. Partition可跨Broker(Topic可跨Broker)

偏移量 (Offset): 消息追加到Partition时分配的标志位

  1. Offset是消息在Partition中的唯一标识(保证Partition内的有序性)
  2. Offset不支持跨Partition(Topic无序)

如: 消息追加写入Partition

  1. 消息在发送到Broker之前, 都会先根据Partition规则分配到具体的Partition
  2. Topic的Partition应避免都属于单个文件(避免机器的I/O成为性能瓶颈)

Partition中2个特殊的Offset:

  1. HW (High Watermark): Consumer能拉取到消息的最大Offset
  2. LEO (Log End Offset): Partition下条消息写入的Offset

// ISR中最小的LEO为该Partition的HW(最慢的follower)

如: Partition中的特殊Offset

副本 (Replica): Partition的冗余

  1. 功能: Kafka通过多副本机制提高容灾能力
  2. 副本之间分为:leader (主副本)、follower(从副本)
  3. 副本间仅存在一主多从关系, 且可实现自动故障转移
  4. Producer和Consumer只能和leader进行交互(follower仅进行消息同步)

如: Kafka的多副本交互

副本相关名词:

  1. AR (Assigned Replicas): 所有副本(包括leader)
  2. ISR (In-Sync Replicas): 与leader保持同步的副本(包括leader)
  3. OSR (Out-of-Synce Replicas): 与leader同步滞后过多的副本(数据不同步)

// 默认仅ISR中的副本才有资格选举为leader, 且负责动态管理ISR和OSR中的follower

延迟任务

时间轮 (TimeingWheel): 以固定时间粒度为单位管理和调度事件的数据结构

  1. 时间跨度 (tickMs): 时间轮构成的基本单位, 个数固定
  2. 表盘指针 (currentTime): 指向当前所处的时间粒度
  3. 时间轮对于插入/删除操作的时间复杂度为O(1)

定时器 (SystemTimer): Kafka中各类延迟操作的触发

  1. 本质: 基于时间轮机制和数组构成的环形队列
  2. 定时任务项 (TimerTaskEntry): 封装真正的定时/延迟任务(Task)
  3. 定时任务列表 (TimerTaskList): 存放时间粒度下所有TimerTaskEntry的双向链表

如: 定时器构成结构

  1. 当添加TimerTaskEntry时, 会根据过期时间和currentTime算出应插入的TimerTaskList
  2. 当计算结果超出总tickMs时, 会复用之前的TimerTaskList
  3. TimerTaskList中都有个哑元节点方便操作(不存储数据)

层级时间轮 (Hierarchical TimeingWheel): 分层处理不同tickMs的多级时间轮的组合结构

  1. 本质: 通过划分每个时间轮处理的时间范围, 以保证时间轮的高性能
  2. 升级: 当TimerTaskEntry的过期时间超出本层的时间范围时, 将交由上层时间轮
  3. 降级: 当TimerTaskEntry在高层时间轮中过期时, 会将其减少已过的时间并重新提交到层级时间轮
  4. TimerTask仅能由最底层的时间轮负责执行处理, 高层的时间轮仅根据时间粒度负责其的编排和重新提交

// Kafka中通过DelayQueueExpiredOperationReaper线程实现时间的推进(避免空转造成的性能浪费)

如: 层级时间轮

  1. 层级时间轮创建时会以当前系统时间作为最底层时间轮的起始时间(startMs)
  2. 高层时间轮的起始时间都为创建时上一层时间轮的currentTime
  3. 每层时间轮的currentTIme都必须是tickMs的整数倍
  4. Kafka仅持有最底层时间轮的引用

延迟操作管理器 (DelayedOperationPurgatory, DOP): 管理/执行Kafka中各类延迟操作

  1. 每个DOP都对应个定时器(超时管理)和监听池(监听Partition事件)
  2. 当进行延迟拉取时, 会读取两次日志文件并等待足够数量的消息才会返回

如: Producer的延迟操作

相关推荐
大熊程序猿1 小时前
ubuntu 安装kafka-eagle
linux·ubuntu·kafka
星染xr1 小时前
kafka 生产经验——数据积压(消费者如何提高吞吐量)
分布式·kafka
东方巴黎~Sunsiny1 小时前
如何监控Kafka消费者的性能指标?
分布式·kafka
飞升不如收破烂~1 小时前
kafka
分布式·kafka
龙哥·三年风水3 小时前
群控系统服务端开发模式-应用开发-前端个人信息功能
分布式·vue·群控系统
小码哥呀4 小时前
RabbitMQ集群搭建
分布式·rabbitmq
材料苦逼不会梦到计算机白富美4 小时前
golang分布式缓存项目 Day6 防止缓存击穿
分布式·缓存·golang
想学习java初学者5 小时前
Docker Compose部署Kafka(非Zookeeper)
docker·容器·kafka
Yz98766 小时前
Kafka面试题
大数据·分布式·zookeeper·kafka·big data
customer086 小时前
【开源免费】基于SpringBoot+Vue.JS课程答疑系统(JAVA毕业设计)
java·jvm·vue.js·spring boot·spring cloud·kafka·开源