Kafka架构介绍

最新推荐文章于 2025-11-16 08:00:00 发布
原创 最新推荐文章于 2025-11-16 08:00:00 发布 · 837 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#Kafka架构介绍

本文深入解析Kafka的架构，包括分布式消息系统的组件如Broker、Producer、Consumer和ZooKeeper的作用，以及消息的存储机制和消费模型。探讨了Kafka的特性，如高性能、持久性、灵活性和分布式特性。

整体架构

  • Kafka：分布式消息系统，将消息直接存入磁盘，默认保存一周
  • Broker：接收Producer发过来的数据，并且将它持久化，同时提供给Consumer去订阅
    • 组成Kafka集群节点，之间没有主从关系，依赖ZooKeeper来协调，broker负责消息的读取和存储，一个broker可以管理多个partition
  • Producer：发布者，自己决定向那个partition中去生产消息，两种机制：hash、轮询
  • Consumer：订阅者，订阅并获取数据，提供给外部系统去使用，一个consumer只能读取一个partition分区的数据
    • consumer通过ZooKeeper去维护消费者偏移量。consumer有自己的消费者组，不同组之间消费同一个topic数据，互不影响，相同组内的不同的consumer消费同一个topic，这个topic中相同的数据只能被消费一次
  • ZooKeeper：协调Kafka Broker，存储原数据：consumer的offset+broker信息+topic信息+partition个信息。
  • Push And Pull：
    • 作为一个messaging system，Kafka遵循了传统的方式，选择由producer向broker push消息并由consumer从broker pull消息。一些logging-centric system，比如Facebook的Scribe和Cloudera的Flume,采用非常不同的push模式。事实上，push模式和pull模式各有优劣。
  • Push：push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞
  • Pull：pull模式则可以根据consumer的消费能力去从broker拿数据，很大程度上避免了应用程序别压垮，尤其是在峰值流量的情况下，同时设计会特别简单，尤其是broker的设计，它并不需要感知consumer的存在，也不需要知道有多少consumer，每个consumer订阅什么样的topic
  • Producer如何知道应该将这条数据发送给那个Broker
    • Producer就是通过Partition去判断，应该将那条消息发送给那个Broker
  • Producer是如何获取整个Broker集群的原信息
    • 上图Broker和Consumer使用了ZooKeeper，从Kafka0.8版本开始Pro杜尔不在依赖于ZooKeeper去获取整个集群的信息，在实例化Producer的时候，可以指定一个或多个Broker的URL或者IP和Port的组合，比如集群有三百个Broker，但是我们只指定三个Broker的IP和端口号给Producer，Producer就会根据这三个Broker的先后，分别取连接这三个Broker，只要有一个连接成功，他就可以从Broker里面拿到整个集群当前还活着的或者正常工作的Broker的列表以及相关的原信息，从而将它返回给Producer，这是Producer就知道整个集群有多少个Broker，每个Topic有多少个Partition，每个Partition分别在那个Broker上面，Producer会将原信息存到Producer的内存当中

  • 注意：如果某个Broker挂掉了或者Producer发送消息给Broker失败了

    • 我们需要维护Producer缓存的Broker【或者整个集群】的原信息，刷新原信息有两种机制
      • Producer向某个Broker发送数据失败之后，他会主动触发刷新原信息的操作，重新获取当前整个集群的原信息，因为Producer发送数据给Broker失败，很有可能是网络不通或者Broker掉了，这个时候需要去刷新Producer缓存的Broker原信息。
      • Producer可以周期性的去刷新缓存的原信息，刷新周期可以通过Producer的配置参数配置，可以在Producer实例化的时候指定它
  • Consumer是如何获取整个Broker集群的原信息
    • Consumer是通过连接ZooKeeper，也就是说，我们实例化Consumer的时候，需要去指定一个或多个ZooKeeper的IP和Port，我们都知道整个集群的原信息都会存到ZooKeeper里面，Consumer只要去连接了ZooKeeper，他就可以知道整个集群有多少个Topic，每个Topic在那个Broker上面
  • Broker如何知道那条消息应该发送到那个Broker上面
  • Consumer如何判断我应该从那个Broker上面去消费数据
    • ​​​​​​​上述两个问题与Topic与Partition有关，订阅、发布都会显示的指定Topic，Consumer也可以设定白名单、黑名单指定希望去消费或者不消费那些Topic的数据

Topic & Partition

  • Topic【一类消息的总称 / 一个消息队列】

    • 逻辑概念，同一个Topic的消息可分布在一个或多个节点（Broker）上
    • 一个Topic包含一个或者多个Partition【Topic存储消息存储在Partition上，有多少个创建时候指定】
    • 每个partition内部消息强有序，其中的每个消息都有一个序号叫offset
    • 一个partition只对应一个broker，一个broker可以管多个partition
    • 每条消息都属于且仅属于一个Topic
    • 消息直接写入文件,并不是存储在内存中
    • 根据时间策略(默认一周)删除，而不是消费完就删除
    • Producer发布数据时，必须指定将该消息发布到哪一个Topic
    • Consumer订阅消息时，也必须指定订阅哪个Topic的消息

  • Partition【提高并行度】

    • 组成 topic 的单元，每个 partition 都有副本，有多少？创建时候指定。
    • 每个 partition 只能由一个 broker 来管理，这个 broker 是这个 partition 的 leader
    • 物理概念，一个Partition只分布于一个Broker上（不考虑备份）
    • 一个Partition物理上对应一个文件夹【直接写入磁盘，数据不会丢】
    • 一个Partition包含多个Segment（Segment对用户透明）
    • 一个Segment对应一个文件
    • Segment由一个个不可变记录组成
    • 记录只会被append到Segment中，不会被单独删除或者修改
    • 清除过期日志时，直接删除一个或多个Segme
    • producer自己决定往哪个partition写消息，可以是轮询的负载均衡，或者是基于hash的partition策略
      • ​​​​​​​生产的消息是<key，value>形式的，基于hash的partition策略是将key的hash值余3，得到要存的partition编号，这个策略是partition默认的策略
      • 第二种是轮询的方式，第一次进来是partition 0，第二次就partition 1，第三次是partition 2，第四次是partition 0，一次类推
  • ​​​​​​​

kafka的消息存储和生产消费模型

  • kafka里面的消息是有topic来组织的，简单的我们可以想象为一个队列，一个队列就是一个topic，然后它把每个topic又分为很多个partition，这个是为了做并行的，在每个partition里面是有序的，相当于有序的队列，其中每个消息都有个序号，比如0到12，从前面读往后面写
  • 一个partition对应一个broker，一个broker可以管多个partition，比如说，topic有6个partition，有两个broker，那每个broker就管3个partition
  • 这个partition可以很简单想象为一个文件，当数据发过来的时候它就往这个partition上面append，追加就行，kafka和很多消息系统不一样，很多消息系统是消费完了我就把它删掉，而kafka是根据时间策略删除，而不是消费完就删除，在kafka里面没有一个消费完这么个概念，只有过期这样一个概念
  • -------------------------------------------------------------------
  • consumer自己维护消费到哪个offset【消费到partition的offset由consumer交给ZooKeeper去维护】
  • 每个consumer都有对应的group
  • group内是queue消费模型
    • ​​​​​​​各个consumer消费不同的partition【也就是说相同的消息只能被消费一次】
    • 一个消息在group内只消费一次
    • 依次去消费，不是一起消费，先p0，再p3，再p1，再p2
    • 如果在消费过程中，C1与p0断开，那么C2可以消费p0，只是消费的位置是C1断开前消费的位置
  • ​​​​​​​各个group各自独立消费，互不影响

kafka有哪些特点

  • 消息系统的特点：生存者消费者模型，FIFO
    • partition内部是FIFO的，partition之间呢不是FIFO的，当然我们可以
      把topic设为一个partition，这样就是严格的FIFO
  • 高性能：单节点支持上千个客户端，百MB/s吞吐
  • 持久性：消息直接持久化在普通磁盘上且性能好
    • 直接写到磁盘里面去，就是直接append到磁盘里面去，这样的好处是
      直接持久话，数据不会丢，第二个好处是顺序写，然后消费数据也是
      顺序的读，所以持久化的同时还能保证顺序读写
  • ​​​​​​​分布式：数据副本冗余、流量负载均衡、可扩展
    • ​​​​​​​分布式，数据副本，也就是同一份数据可以到不同的broker上面去，
      也就是当一份数据，磁盘坏掉的时候，数据不会丢失，比如3个副本，
      就是在3个机器磁盘都坏掉的情况下数据才会丢
  • ​​​​​​​很灵活：消息长时间持久化+Client维护消费状态
    • ​​​​​​​消费方式非常灵活，第一原因是消息持久化时间跨度比较长，一天或
      者一星期等，第二消费状态自己维护消费到哪个地方了，可以自定义
      消费偏移量

Partitioner

  • Producer在发送一条消息，需要决定这条消息应该发送到具体哪个Broker上面去
  • 对于指定消息的key，返回这条消息应该被发送到那个Partition
    • ​​​​​​​取key的hash值，还会对Partition总数取余，这样的好处是，key相同的数据会被发送到同一个Broker中
  • 不管key是什么样子，对于发送过来的消息，如果第一条消息被发送到第0个Partition，那么第二个就发送到第1个partition，依次类推循环处理
    • ​​​​​​​它不会引起线程安全问题，incrementAndGet() 是线程安全的

同步（Sync）Producer和异步（Aync）Producer

  • Sync Producer

    • 消息发送过去之后，只有发送成功，我们才发送下一条数据，如果发送失败，它会不停的Retry，三次不成功就失败抛出异常，这个时候我们选择忽略这条，不过不太推荐

      • 低延迟
      • 低吞吐率
      • 无数据丢失

  • Aync Producer

    • ​​​​​​​​​​​​​​每次数据使用了send方法之后，它并不是真正的被发送出去了，而是说它里面有一个Queue，每次发送都是入队，会有一个后台线程不停的从Queue中拿数据，发送给Broker，这个发送过程是一个批量过程，因此效率比较高，但是会有延迟

      • 高延迟：不会对每条数据直接真实发送
      • 高吞吐率：发送是一个批量的过程
      • 可能会有数据丢失：如果Queue满了，并且阻塞了一定时间，它会选择将新的数据直接丢掉
Kafka集群——（区别于Master/Slave架构的的分布式集群）
YuannaY的博客
07-25 1517
1.
大数据技术Kafka详解 ② | Kafka基础与架构介绍
热门推荐
dvlinker的技术专栏
12-02 2万+
本文详细介绍开源高吞吐量分布式消息中间件kafka的架构与组件构成。
Kafka 3.0 源码笔记(9)-Kafka 服务端元数据的主从同步
谈谈1974
04-04 3808
文章目录前言1. 元数据主从同步的流程1.1 两次 Fetch 完成 HW 同步1.2 一次 Fetch 完成 HW 同步2. 元数据主从同步源码分析2.1 Follower 节点 Fetch 请求的发起2.2 Leader 节点对 Fetch 请求的处理2.3 Follower 节点对 Fetch 响应的处理 前言 在 Kafka 3.0 源码笔记(8)-Kafka 服务端对创建 Topic 请求的处理 中笔者分析介绍了 Kafka 集群的 Leader 节点更新保存元数据的流程，而元数据保存下来后必然要
【分布式利器：Kafka】Kafka基本原理详解：架构、流转机制与高吞吐核心（附实战配置）
最新发布
专注AI工程化与架构实战。从分布式思维到模型部署，用工程化视角为你厘清AI落地的真实路径。
11-16 1568
Kafka是一个分布式流处理平台，以高吞吐、高可靠和高扩展性著称，广泛应用于日志收集、实时分析和数据同步场景。其核心架构包括生产者、消费者、Broker节点、Topic和Partition，通过分区并行、副本容错和批量处理实现百万级TPS。消息流转流程涵盖生产、存储和消费环节，依赖分区策略和Offset管理确保数据有序可靠。Kafka的高性能源于顺序写磁盘、零拷贝和批量压缩等技术优化，同时提供副本机制和ISR列表保障高可用。实际应用中需注意分区数配置、消息积压等问题，以充分发挥其“大数据流量枢纽”的作用。
Kafka 整体架构 及 概念
Man2022的博客
09-04 2112
kafka整体架构
kafka架构与原理 ，消息的可靠性与一致性幂等性，数据存储、zookeeper、使用场景
.
03-03 3244
Kafka常用命令之kafka-topics.shhttps://blog.youkuaiyun.com/qq_29116427/article/details/80202392 Kafka概述 Kafka作为一个商业级消息中间件 ，发布和订阅记录流，它类似于一个消息队列 先了解下Kafka的基本原理，然后通过对kakfa的存储机制、复制原理、同步原理、可靠性和持久性保证等等一步步对其可靠性进行分析...
Kafka的原理、基础架构、以及使用场景详解
jjc4261的博客
03-10 1139
Apache Kafka是分布式发布-订阅消息系统，在 kafka官网上对 kafka 的定义：一个分布式发布-订阅消息传递系统。Kafka最初由LinkedIn公司开发，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。主要应用场景有：日志收集系统和消息系统。
kafka架构体系
tian830937的专栏
02-21 1198
Kafka是一个由Scala和Java编写的企业级的消息发布和订阅系统，最早是由Linkedin公司开发，最终开源到Apache软件基金会的项目。Kafka是一个分布式的，支持分区的，多副本的和多订阅者的高吞吐量的消息系统，被广泛应用在应用解耦、异步处理、限流削峰和消息驱动等场景。本文将针对Kafka的架构和相关组件进行简单的介绍。在介绍Kafka的架构之前，我们先了解一下Kafk的核心概念。
Kafka介绍.ppt
06-20
Kafka的message格式具有明确的结构，包括消息长度、魔术值（用于兼容性）、校验和、以及消息负载。这种格式化设计确保了消息在传输和处理过程中的准确性和高效性。 Kafka凭借其独特的设计理念和特性，已经成为处理...
精选资源
Kafka基本架构介绍
01-27
消息系统负责将数据从一个应用程序传输到另一个应用程序，因此应用程序可以专注于数据，但不担心如何共享它。分布式消息传递基于可靠消息队列的概念。消息在客户端应用程序和消息传递系统之间异步排队。...
Kafka系统架构（ Broker，Topic， Partition，Replication）
XIATWO
11-30 5814
Kafka系统架构 一、Broker 服务器节点 概念 Kafka 集群包含一个或多个服务器，服务器节点称为broker 描述 就是Kafka集群replication的名称 二、Topic 主题|消息类别 概念 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic 描述 1、在Kafka 中一张表就是一个主题 2、类：table index 3、将来会根据业务的不同创建不同的主题 4、创建流程：首先创建主题，然后选择 Partition和Replication 说
Kafka的基本架构是怎样的？Kafka的消息发布和订阅模型是怎样的？Kafka的核心组件有哪些？Kafka的消息保证机制有哪些？
luoluoal的博客
07-07 797
该模型基于生产者和消费者的概念，其中生产者负责将消息发布到Kafka集群的一个或多个主题中，而消费者负责从主题中订阅消息并进行处理。至少一次（At least once）：发送者发送一条消息后，会等待接收者的确认，如果没有收到确认，则会重试发送，直到接收者确认收到消息。每个消费者在同一个消费者组中订阅相同的主题，但消费的消息会被分配给不同的消费者，以实现负载均衡和高可用性。它将消息发送到指定的主题（topic），并可以选择性地指定消息的分区（partition）和键（key）。
Kafka学习笔记--kafka 概述、快速入门，架构深入
桑凯旋的博客
02-28 3801
文章目录第 1 章 Kafka 概述1.1 定义1.2 消息队列1.2.1 传统消息队列的应用场景1.2.2 消息队列的1.3 Kafka 基础架构第 2 章 Kafka 快速入门2.1 安装部署2.1.1 集群规划2.1.2 jar 包2.1.3 集群部署2.2 Kafka 命令行操作第 3 章 Kafka 架构深入3.1 Kafka 工作流程及文件存储机制3.2 Kafka 生产者3.2.1 分区策略3.2.2 数据可靠性保证3.2.3 Exactly Once 语义3.3 Kafka 消费者3.3.1
大白话认识 Kafka 背后优秀的架构设计
中生代技术
04-12 319
来源 |https://juejin.cn/post/6844903999066341384前言一、Kafka基础消息系统的作用1.Topic 主题2.Partition 分区3.Pro...
Kafka：kafka的主从模式和故障切换 ②
有才而性缓，定属大才。有智而气和，斯为大智。
02-24 1942
因此，如果分区数量固定，消费者数量的上限就是分区的数量。这种方式更类似于Leader-Follower模式，而不是传统意义上的主从模式，因为在Kafka中，每个Broker（Kafka的服务器节点）都可能成为某个Partition的Leader，也可能是Follower，这取决于你如何配置和使用你的Kafka集群。需要注意的是，一个Partition在一个消费者组中，一次只能被一个消费者消费，所以消费者组中的消费者数量不能超过总的Partition数量，否则多余的消费者将会闲置。
Kafka架构
qzqanzc的博客
09-25 391
Kafka架构kafka 概念 kafka 概念 Topic 逻辑概念，同一个Topic的消息分布在一个或者是多个（Broker）节点上 一个Topic包含一个或者多个Partition 每条消息都属于而且仅属于一个Topic Producer发布数据，必须指定将该消息发布到哪一个Topic Consumer订阅消息时，也必须指定订阅那个Topic的消息 Partition 物理...
Hadoop核心源码剖析系列（六）: Kafka的架构、原理、特点介绍
大数据与人工智能
02-08 337
作者 | 吴邪 大数据4年从业经验，目前就职于广州一家互联网公司，负责大数据基础平台自研、离线计算&实时计算研究编辑 | auroral-L‍‍Kafka作为时下火热的分布式消...
漫游Kafka设计篇之主从同步
红磊的专栏
07-09 2万+
Kafka允许tipci的分区拥有若干副本，这个数量是可以配置的，你可以为每个topci配置一个副本数量。Kafka会自动的在个副本上备份数据，所以当一个server down掉时数据依然是可用的。 Kafka的副本功能不是必须的，你可以配置只有一个副本，这样其实就相当于只有一份数据。 创建副本的单位是topic的分区，每个分区都有一个leader和零或多个followers.所有的读写操作都
主从选举机制，架构高可用性的不二选择
战斧的博客
06-09 4354
本文主要分析现代三高架构中的一个经典集群结构————主从模式，并分析一些常见框架在集群上的异同随着现代数据处理量和对稳定性要求的水涨船高，高并发，高可用，高性能逐渐成为Java程序员的日常，但是这种架构暗藏很多难点，如果你对这种架构还有很多疑惑，可以直接锁定本栏目，会持续推出有关三高架构的内容Redis的选举机制是基于Raft协议，用于选举哨兵(Sentinel)集群中的主节点，再由该主节点为主从系统选出主节点；Zookeeper的选举机制是基于Zab协议（选举模式基于Paxos），用于选举领导者节点。
kafka介绍
03-23
<think>嗯，用户想了解Apache Kafka的基本概念和核心功能。首先，我需要回忆一下Kafka的定义和主要用途。Kafka是一个分布式流处理平台，主要用于处理实时数据流，支持发布-订阅模式，这在消息队列系统中很常见。根据引用[1]和[3]，Kafka具有高吞吐量、可扩展性和容错性，适合企业级消息传递和大规模数据处理。 接下来，核心功能方面，用户可能需要知道Kafka的四个核心API，如生产者API、消费者API等，这些在引用[1]和[4]里提到过。另外，Kafka的架构包括Broker、Topic、Partition这些概念，需要详细解释。比如，Topic是消息的分类，Partition用于横向扩展和并行处理，引用[3]和[4]中的信息可以支持这部分内容。 用户可能还会关心Kafka的存储机制，比如它的高性能存储模块，这部分在引用[3]里有提到。另外，Kafka与其他系统的集成能力，比如通过Kafka Connect进行数据导入导出，以及流处理能力如Kafka Streams，这些也是核心功能的一部分。 需要注意的是，用户的问题可能涉及Kafka的分布式特性，比如ZooKeeper的作用和KRaft模式的引入，引用[5]中提到Kafka 3.0开始使用KRaft替代ZooKeeper，这一点要说明清楚。 此外，应用场景部分需要举例说明，比如在微服务架构中的异步通信，日志聚合，实时分析等，引用[4]中的例子可以作为参考。还要提到Kafka在数据管道中的作用，连接不同系统进行数据流转。 最后，生成相关问题时要覆盖用户可能进一步想了解的内容，比如架构组件、消息模式、存储机制、ZooKeeper和KRaft的区别，以及应用场景。确保问题有针对性，帮助用户深入理解Kafka的不同方面。</think>### Apache Kafka 简介及核心功能 #### 1. **基本概念** Apache Kafka 是一个**分布式流处理平台**，主要用于实时数据流的处理、存储和传输。其核心设计目标是实现高吞吐量、水平扩展和容错能力，适用于大规模数据处理场景[^1][^3]。 #### 2. **核心功能** - **分布式流系统** Kafka 通过分布式架构将数据分片存储在多个节点（Broker）上，支持横向扩展。每个 Topic 分为多个 Partition，每个 Partition 可在不同 Broker 上复制以提高容错性[^3][^5]。 - **发布-订阅模式** 生产者（Producer）将消息发布到 Topic，消费者（Consumer）订阅 Topic 并按需消费消息。例如，微服务中可用 Kafka 实现服务间异步通信，确保解耦和可靠传输[^4]。 - **高性能存储** Kafka 采用顺序读写和零拷贝技术优化磁盘 I/O，支持高吞吐量（百万级消息/秒）。数据按时间或大小策略持久化存储，便于回溯和批量处理。 - **流处理能力** 通过 Kafka Streams API 或集成外部框架（如 Flink），可直接对数据流进行实时处理（如聚合、过滤）。 #### 3. **核心组件** - **Broker**：Kafka 集群中的单个节点，负责消息存储和转发。 - **Topic**：逻辑上的消息分类，例如 `user_activity` 或 `payment_events`。 - **Partition**：Topic 的分区，每个 Partition 是一个有序、不可变的消息队列。 - **Producer/Consumer**：生产者推送消息到 Topic，消费者按需拉取消息[^3]。 #### 4. **关键特性** - **容错性**：通过副本机制（Replication）保障数据可靠性，即使部分节点故障，数据仍可用。 - **扩展性**：新增 Broker 可自动分配负载，无需停机。 - **持久化**：消息可配置保留时间（如 7 天），支持历史数据重放[^3]。 #### 5. **应用场景** - **日志聚合**：集中收集多服务的日志数据。 - **实时分析**：结合流处理框架进行实时指标计算（如用户行为分析）。 - **事件溯源**：记录系统状态变化事件，用于审计或回放[^4]。 ```plaintext 示例架构： 生产者 → Kafka Topic（Partition 1, Partition 2） → 消费者组 ``` #### 6. **生态集成** - **Kafka Connect**：工具库，支持与数据库、Hadoop 等系统集成。 - **KRaft 模式**：Kafka 3.0+ 版本支持去 ZooKeeper 的元数据管理，简化集群运维。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值