本文是《运维小路》关于Kafka技术的系统教程，从基础概念到高级应用全面覆盖。内容包括：Kafka核心概念介绍、集群部署与ZooKeeper对比、主题/分区/副本机制解析、生产者消费者模型、高性能原理（顺序读写/零拷贝）、元数据存储与监控方案（Prometheus/KafkaManager）、日常运维命令及典型故障处理案例（节点恢复/分区扩容修复）。特别介绍了不依赖ZooKeeper的Kraft模式，并附有MySQL到PostgreSQL的异构数据库迁移方案。作者以运维工程师视角，通过思维导图清晰展示知识体

我们前面演示都是依赖ZooKeeper的版本，本小节我们介绍2个版本不依赖ZooKeeper的版本，第一个版本就是我们前面使用的版本：kafka_2.13-2.8.2，它既支持使用ZooKeeper，也支持使用kraft。

在我以前的工作中遇到过多次数据库迁移，如果数据库是一样的，其实相对都是比较简单的。因为基本上都可用利用数据库自身的同步原理就可以实现，但是现实中还有需求就是异构数据库的迁移。就好比Oracle到MYSQL，当然这里我为了简单，我这里用了简单的MYSQL迁移到PG。

一般情况下，我们的分区很少会出现异常的情况，但是在Broker异常下线，尤其是一次性下线多个节点的情况就会出现。我这里为了演示，所以把上个小节5节点Kafka直接下线2个节点，就可以模拟这个情况。

前面是3个节点，我们这里增加了2个节点，模拟扩容Broker，然后再扩分区。如果前期我们配置的3副本，则副本是不需要扩容的。这里我们并没有考虑跨AZ（可以通过机架感知参数来实现）。

本篇文章大概是我3年前写的，当时写这篇文章的背景是一个容器化部署的Kafka集群，其中一个节点宕机以后无法恢复，所以想了解下这个Kafak集群崩溃以后的恢复过程（下面的内容参考原文做了部分修改和脱敏）。

对于运维来说，一个正常的Kafka的集群，一般情况下我们是不需要去操作ZooKeeper来维护它的集群状态的。我们对Kafka的操作，大部分都通过Kafka自带的脚本来操作它，下面我们就来介绍下使用较多的命令。（部分命令在前面的操作里面已经有演示）。

我们上一个小节介绍Kafka的监控信息，但是这个监控适合接入到云原生的监控系统，如果没有云原生监控，光使用JVM监控则会更麻烦，而我们今天介绍另外一个监控：Kafka Manager，Kafka Manager也是在云原生流行之前的普遍使用的Kafka监控。

我们在前面ZooKeeper里面也使用到了这个JMX监控，Kafka作为一个JAVA应用也有对应的jmx监控，而且在ZooKeeper里面数据，也会显示当前节点是否开启了jmx监控。

我们前面在部署Kafka的时候，选择的是需要ZooKeeper支持的版本，在 Kafka 2.8 之前的版本中，ZooKeeper 承担了以下关键职责：

Kafka的零拷贝（Zero-Copy）技术是其实现高吞吐量的关键优化之一，主要通过减少数据在内核态和用户态之间的冗余拷贝及上下文切换来提升性能。以下是对该机制的详细分析

我们前面在介绍Kafka的时候，有一个Topic概念，它不仅仅是一个逻辑隔离的概念，也是实际存储内容的地方。在RabbitMQ里面有一个类似的概念，就是虚拟主机（vhost），它只是起到一个逻辑隔离，本身并不存储数据。

我们前面讲解了Kafka的几个关键概念，生产者者发送的消息最终都会写到Broker节点的磁盘里面，那么它在本地数据是怎么样的呢？

我们上个小节介绍了生产者怎么给afka发送数据，本小节我们来介绍消费者(Consumer)，以及我们如何消费数据。

我们上前面介绍了Topic的基本概念和涉及到Topic核心的分区和副本概念，但是我们还得往里面写入数据才行，然后数据写进入以后我们还得把里面的数据读出来，我们今天首先介绍的负责向Kafka写入消息角色：生产者(Producer)。

在 Apache Kafka 中，每个分区都有Leader分区和Follower分区，Leader 分区 是负责处理客户端读写请求的主副本，其副本管理机制通过 AR（Assigned Replicas）、ISR（In-Sync Replicas） 和 OSR（Out-of-Sync Replicas） 确保数据的高可用性和一致性。

我们上个小节介绍了Kafka里面一个很核心的逻辑概念：主题(Topic)，在创建Topic的时候，涉及到两个很关键的参数：分区(Partition)和副本(Replica)，我们今天就来详细介绍这2个概念。

在 Apache Kafka 中，Topic（主题） 是消息的逻辑分类单元，所有消息的生产和消费都围绕 Topic 进行。每个 Topic 可以看作一个消息队列的抽象，但 Kafka 通过 分区（Partition） 和 副本（Replica） 机制实现了高吞吐、高可用和水平扩展的特性。

本小节我们将进行Kafka的安装，截止到2025年，最新的Kafka最新版本默认不依赖Zookeeper，而由于刚刚发布，我们业务使用的大部分版本应该都是需要依赖的ZooKeeper的版本。我们选择的是2.8.2版本，这个版本开始可以不依赖Zookeeper，我们后期有需要可以调整。

Kafka的设计哲学源于发布-订阅模型，但其创新性地引入了分布式存储和分区化处理机制，使得系统能够高效处理每秒百万级的消息吞吐。这一特性使其迅速成为现代数据管道（Data Pipeline）和流式处理（Stream Processing）的核心组件。