一文读懂运维消息中间件之KAFKA

原创

已于 2025-02-20 11:59:28 修改 · 1.6k 阅读

44 ·

CC 4.0 BY-SA版权

文章标签：

#运维 #kafka #分布式 #linux #中间件

于 2024-03-06 08:42:22 首次发布

本文深入解析Kafka，涵盖Kafka的基本术语如topic、partition、producer、consumer、broker等，并介绍Kafka的总体数据流、生产流程、集群搭建模式，包括配置、环境准备、ZooKeeper结构等，同时讲解常用命令，如服务管理和数据操作，帮助读者全面理解Kafka运维。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

(5)、controller failover

2）将消息发送到名为myTopic的主题中

(一)、KAFKA简介

Kafka是一种高吞吐量的分布式发布订阅消息系统（消息引擎系统），简单点理解就是系统A发送消息给kafka（消息引擎系统），系统B从kafka中读取A发送的消息，而kafka就是个中间商。

Kafka的消息传递模式就是一种发布-订阅模式。在发布-订阅消息系统中，消息被持久化到一个topic中。与点对点消息系统不同的是，消费者可以订阅一个或多个topic，消费者可以消费该topic中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除。在发布-订阅消息系统中，消息的生产者称为发布者，消费者称为订阅者。

发布-订阅模式的示例图如下：

1、KAFKA基本术语

Kafka的相关术语及其之间的关系如下图所示：

说明：

上图中一个topic配置了3个partition。Partition1有两个offset：0和1。Partition2有4个offset。Partition3有1个offset。副本的id和副本所在的机器的id恰好相同。
如果一个topic的副本数为3，那么Kafka将在集群中为每个partition创建3个相同的副本。集群中的每个broker存储一个或多个partition。多个producer和consumer可同时生产和消费数据。

(1)、topic

Kafka将消息分门别类，每一类的消息称之为一个主题（Topic）。一个topic可以有零个，一个或多个消费者订阅该主题的消息。一个topic实际是由多个partition组成的，遇到瓶颈时，可以通过增加partition的数量来进行横向扩容。单个parition内是保证消息有序。
类似于数据库的表名。
Topic在逻辑上可以被认为是一个queue，每条消息都必须指定它的Topic，可以简单理解为必须指明把这条消息放进哪个queue里。对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否。

(2)、partition

topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

(3)、producer

生产者即数据的发布者，该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。

(4)、consumer

消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。

(5)、broker

Kafka 集群包含一个或多个服务器，服务器节点称为broker。
broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。
如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。
如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。

(6)、Consumer Group

每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。
同一Topic的一条消息只能被同一个Consumer Group内的一个Consumer消费，但多个Consumer Group可同时消费这一消息。

(7)、Leader

每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。

(8)、Follower

Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。

2、KAFKA总体数据流图

一个典型的Kafka集群中包含若干Producer（可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。

Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉去指定Topic的消息，然后进行业务处理。图中有两个topic，topic 0有两个partition，topic 1有一个partition，三副本备份。可以看到consumer gourp 1中的consumer 2没有分到partition处理，这是有可能出现的，下面会讲到。

关于broker、topics、partitions的一些元信息用zk来存，监控和路由啥的也都会用到zk。

3、KAFKA生产流程

(1)、生产者发布消息

1）写入方式

producer 采用 push 模式将消息发布到 broker，每条消息都被 append 到 patition 中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障 kafka 吞吐率）。

2）消息路由

producer 发送消息到 broker 时，会根据分区算法选择将其存储到哪一个 partition。

其路由机制为：

指定了 patition，则直接使用；
未指定 patition 但指定 key，通过对 key 的 value 进行hash 选出一个
patition patition 和 key 都未指定，使用轮询选出一个 patition。

3）写入流程

producer 写入消息序列图如下所示：

流程说明：

producer 先从 zookeeper 的 "/brokers/.../state" 节点找到该 partition 的 leader
producer 将消息发送给该 leader
leader 将消息写入本地 log
followers 从 leader pull 消息，写入本地 log 后 leader 发送 ACK
leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset）并向 producer 发送 ACK