在现代数据驱动的应用场景中,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个节点,以确保集群的高可用性和容错能力。这是生产环境中常见的配置。
如果你喜欢此文章,不要忘记关注+点赞哦!你的支持是我创作的动力。如果你有任何意见或建议,欢迎在下方留言,非常期待与你的交流和讨论。