Kafka - 分布式流处理平台

Apache Kafka 是一个分布式、高吞吐、可持久化的流数据平台。它采用发布-订阅模型，生产者将消息写入主题（Topic），消费者从主题读取。消息被分区（Partition）存储并多副本

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

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

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

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

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

对于运维来说，一个正常的Kafka的集群，一般情况下我们是不需要去操作ZooKeeper来维护它的集群状态的。我们对Kafka的操作，大部分都通过Kafka自带的脚本来操作它。

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

我们在前面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写入消息角

在 Apache Kafka 中，每个分区都有Leader分区和Follower分区，Leader 分区 是负责处理客户端读写请求的主副本。

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

在 Apache Kafka 中，Topic（主题） 是消息的逻辑分类单元，所有消息的生产和消费都围绕 Topic 进行。每个 Topic 可以看作一个消息队列的抽象。

本小节我们将进行Kafka的安装，截止到2025年，最新的Kafka最新版本默认不依赖Zookeeper，而由于刚刚发布，我们业务使用的大部分版本应该都是需要依赖的ZooKeeper的版本。

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