在现代数据驱动的应用场景中，Apache Kafka 已经成为了一个不可或缺的组件。作为一个高吞吐量、可扩展、高可靠性的分布式消息系统，Kafka 能够胜任从简单的消息队列到复杂的流处理平台的多种角色。
Apache Kafka 天生就支持集群架构。其设计和实现从一开始就考虑了分布式系统的特点，使其能够在多个节点上运行，提供高可用性、可扩展性和容错性。以下是 Kafka 集群支持的一些关键方面：
添加图片注释，不超过 140 字（可选）
Kafka 集群组件
- Broker：
- Kafka 集群中的一个服务器实例，每个 Broker 负责存储一定数量的分区。
- Broker 通过 Broker ID 进行标识。
- Topic：
- 消息的逻辑分类，可以理解为消息的类别。
- 每个 Topic 可以有多个分区（Partition）。
- Partition：
- 一个 Topic 被分割成多个分区，每个分区是一个有序的消息序列。
- 分区是 Kafka 中的基本并行单元，分布在不同的 Broker 上。
- Producer：
- 负责向 Kafka 主题发布消息的客户端应用程序。
- Consumer：
- 负责从 Kafka 主题消费消息的客户端应用程序。
- Consumer Group：
- 一组消费者共同消费一个或多个主题的分区，每个分区只能被 Consumer Group 中的一个消费者消费。
分区和副本机制
- Leader 和 Follower：
- 每个分区都有一个 Leader 和若干个 Follower。
- Leader 处理所有的读写请求，Follower 复制 Leader 的数据。
- 当 Leader 失效时，一个 Follower 会被选举为新的 Leader。
- 副本（Replica）：
- 每个分区的副本数可以配置，副本分布在不同的 Broker 上，以提高容错性。
- 副本机制保证了数据的冗余和高可用性。
在 Kafka 集群中，主题 test 将会分成3个分区，每个分区有3个副本。以下是可能的分布情况：
添加图片注释，不超过 140 字（可选）
Broker 1
- Partition 0 (Leader)
- Partition 1 (Leader)
- Partition 2 (Follower)
Broker 2
- Partition 0 (Follower)
- Partition 1 (Follower)
- Partition 2 (Leader)
Broker 3
- Partition 0 (Follower)
- Partition 1 (Follower)
- Partition 2 (Follower)
每个 Partition 可以配置多个副本（Replica），这些副本分布在不同的 Broker 上。
在 Partition 的多个副本中，有一个副本被选举为 Leader，其他副本则为 Follower。
高可用性和容错性
- 复制机制：
- 数据被复制到多个 Broker 上，提高了数据的可用性和持久性。
- Leader 选举：
- 当 Leader 节点失效时，Controller 会从 ISR 中选举一个新的 Leader。
- Kafka 确保即使部分 Broker 失效，数据仍然可用。
- 数据恢复：
- 新加入的 Broker 或恢复的 Broker 会从其他副本同步数据，确保数据一致性。
无 Zookeeper 的架构（Kafka 2.8+）
Kafka 2.8 引入了不依赖 Zookeeper 的架构，通过新的 Raft 协议（KRaft）管理集群元数据。
在这种架构中，Kafka使用内嵌的集群元信息管理，不再需要Zookeeper来进行broker状态管理和leader选举等功能。当然用户部署还是可以选择继续使用zookeeper或不使用zookeeper而使用内嵌的KRaft。
集群方案
Kafka 集群的部署方案主要有以下几种：
单节点集群
适用于开发和测试环境，只有一个 Broker，不具备高可用性和容错能力。
多节点集群
至少3个节点，以确保集群的高可用性和容错能力。这是生产环境中常见的配置。
如果你喜欢此文章，不要忘记关注+点赞哦！你的支持是我创作的动力。如果你有任何意见或建议，欢迎在下方留言，非常期待与你的交流和讨论。
