Kafka架构及基本概念

简介: 刚开始了解Kafka时对其中多个名词表示懵逼,broker是啥?咋还有分区?有没有跟和我一样有很多???本文就我对Kafka的理解梳理各个角色以及功能,欢迎大家一起来沟通交流

刚开始了解Kafka时对其中多个名词表示懵逼,broker是啥?咋还有分区?有没有跟和我一样有很多???本文就我对Kafka的理解梳理各个角色以及功能,欢迎大家一起来沟通交流。废话不多说,上图:

架构模型

Kafka架构模型

按照自己的理解画一个简单的Kafka架构模型,下面分别说明Zookeeper、Produce、Broker、Replica、Customer、Customer Group 、Topic、Partition在Kafka中的作用以及如何交互。当然,功能远远不止这些。


Produce

作为生产者,它的作用就是将消息成功发送指定的Topic中,消息投递的可靠度、顺序性由Produce决定。

  1. 可靠度:Produce在生产消息时通过设置ACK来决定消息的可靠度。
    — 当ACK为0时,不保证消息是否投递成功。
    — 当ACK为1时(默认),分区leader接收到消息视为投递成功。
    — 当ACK为-1时,分区leader和在同步的副本(ISR)接收到消息视为投递成功,取而代之的是生产效率。
  2. 顺序性:kafka不限制生产者的个数,要确保顺序,单个topic或partition的生产者不可以多线程或者多客户端🤗️。如下图,当有两个生产客户端是无法知道哪个消息先到达的。
    在这里插入图片描述

    Broker

    Broker其实就是Kafka服务启动后的一个进程,是一个物理节点,启动几个Kafka就有几个Broker。作为消息的中介,接收producer往指定的topic中写消息,提供consumer拉取指定topic的消息,除此之外还承担以下几个职责:
  3. Broker集群中有一个节点作为Controller负责Broker成员管理、Topic维护和Partition的管理。
  4. 负责分区数据的持久化和维护。Broker将每个分区的数据按照segment划分,每个segment存放log、offset索引、时间戳索引3个物理文件,以提高数据的读取效率。

Topic

Topic被称为主题,在kafka中是一个逻辑概念,物理上同一个Topic的消息会存储在不同个broker上,真正意义上的分布式消息中间件。通常以topic划分消息所属类别,起业务隔离作用。

Partition

如上图所示,Broker以Topic为单位将消息分摊在不同分区,每个分区都有leader和副本。那为什么会有分区?这是因为如果topic内的消息只存储于一个broker,那这个broker终会成为瓶颈,无法做到水平扩展。此外在分区使用中需要注意的事项:

  1. topic中的各分区只保证内部数据的顺序,所以业务中对顺序有严格要求的只能建立一个分区。
  2. leader负责对外提供读写请求,副本只是同步数据。
  3. 一个分区只能被一个消费组的一个消费者消费。如下图,当分区被分配完后,consumer4无法消费。
    在这里插入图片描述

Replica

kafka的副本机制指的是分区的副本而不是broker,副本通常存放在和leader不同的broker中。如上述Partition注意事项2,副本如何同步数据以保证数据的可靠性和一致性?

  1. 分区leader会动态维护一个与之保持同步的副本列表ISR(In-sync Replicas),如果一个副本同步未达到阈值要求或宕机会被移除至OSR(Outof-sync Replicas),kafka要保证不丢失消息,就要保证ISR列表中至少有一个存活。如下图所示:
    ISR机制

  2. 副本以pull的方式拉取数据进行同步,每个副本都会维护自己的HW(High Watermark)和LEO(Last End Offset)保持数据同步。
    — 当ACK为-1时所有ISR节点的HW和LEO会保持一致。
    — 当ACK为0或1时,可能会因为leader节点的宕机,未同步、消费的数据会丢失。如下图,当leader节点宕机黄色节点的数据会丢失。
    在这里插入图片描述

    Customer

    消费者负责订阅 Kafka 中的Topic,按照Offset进行拉取消费。

Customer Group

在kafka中一个分区的消息只能被一个消费组中的一个消费者消费,不然会破坏分区中消息的消费顺序,但是避免不了一条消息会被多个地方使用的场景,所以有消费组的概念。消费者在进行消费时可以指定一个消费组,同一条消息在被多个消费组消费时就达到消息“广播”的功能。

Zookeeper

Zookeeper在kafka中主要起到两个作用,一是存储broker、topic、partition等元数据信息,二是协调如broker的controller、partition的leader等选举过程。


总结

OK,至此已经大致了解了kafka,总结一下:

  1. 生产——broker——消费,三个环节通过ACK来决定消息的可靠和一致。
  2. 分区有几个作用:
    (1)避免单个broker节点的瓶颈。
    (2)提高数据可靠性。
    (3)提高消费吞吐量。
  3. 利用Zookeeper协调功能,不用做额外配置工作,使得broker可以自动伸缩。

欢迎大家一起来沟通交流。

相关文章
|
9月前
|
消息中间件 Java Kafka
Java 事件驱动架构设计实战与 Kafka 生态系统组件实操全流程指南
本指南详解Java事件驱动架构与Kafka生态实操,涵盖环境搭建、事件模型定义、生产者与消费者实现、事件测试及高级特性,助你快速构建高可扩展分布式系统。
430 7
|
资源调度 监控 调度
基于SCA的软件无线电系统的概念与架构
软件通信体系架构(SCA)是基于软件定义无线电(SDR)思想构建的开放式、标准化和模块化平台,旨在通过软件实现通信功能的灵活配置。SCA起源于美军为解决“信息烟囱”问题而推出的联合战术无线电系统(JTRS),其核心目标是提升多军种联合作战通信能力。 上海介方信息公司的OpenSCA操作环境严格遵循SCA4.1/SRTF标准,支持高集成、嵌入式等场景,适用于军用通信、雷达等领域。 SCA体系包括目标平台资源层(TRL)、环境抽象层(EAL)、SRTF操作环境(OE)及应用层(AL)。其中,SRTF操作环境包含操作系统、运行时环境(RTE)和核心框架(CF),提供波形管理、资源调度等功能。
|
消息中间件 数据可视化 Kafka
docker arm架构部署kafka要点
本内容介绍了基于 Docker 的容器化解决方案,包含以下部分: 1. **Docker 容器管理**:通过 Portainer 可视化管理工具实现对主节点和代理节点的统一管理。 2. **Kafka 可视化工具**:部署 Kafka-UI 以图形化方式监控和管理 Kafka 集群,支持动态配置功能, 3. **Kafka 安装与配置**:基于 Bitnami Kafka 镜像,提供完整的 Kafka 集群配置示例,涵盖 KRaft 模式、性能调优参数及数据持久化设置,适用于高可用生产环境。 以上方案适合 ARM64 架构,为用户提供了一站式的容器化管理和消息队列解决方案。
1075 10
|
11月前
|
消息中间件 存储 大数据
阿里云消息队列 Kafka 架构及典型应用场景
阿里云消息队列 Kafka 是一款基于 Apache Kafka 的分布式消息中间件,支持消息发布与订阅模型,满足微服务解耦、大数据处理及实时流数据分析需求。其通过存算分离架构优化成本与性能,提供基础版、标准版和专业版三种 Serverless 版本,分别适用于不同业务场景,最高 SLA 达 99.99%。阿里云 Kafka 还具备弹性扩容、多可用区部署、冷热数据缓存隔离等特性,并支持与 Flink、MaxCompute 等生态工具无缝集成,广泛应用于用户行为分析、数据入库等场景,显著提升数据处理效率与实时性。
|
7月前
|
Cloud Native Serverless API
微服务架构实战指南:从单体应用到云原生的蜕变之路
🌟蒋星熠Jaxonic,代码为舟的星际旅人。深耕微服务架构,擅以DDD拆分服务、构建高可用通信与治理体系。分享从单体到云原生的实战经验,探索技术演进的无限可能。
微服务架构实战指南:从单体应用到云原生的蜕变之路
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
466 3