Kafka 架构图示例

以下 Kafka 示例展示了同样的「生产者-Broker-消费者」模型如何适配单 Broker、副本集群、多 Topic 配置和 Kafka Streams 有状态处理。

真实案例

使用场景: 本地运行 Kafka 的开发者

一个 Broker、无副本

Topic 含 1-3 个分区做并行

生产者和消费者在同一台机器

Zookeeper 或 KRaft 在同一节点

开发可用，生产不可

这样组织的原因: 单 Broker Kafka 用于本地开发——图表无副本无故障切换。一旦上生产，这就是要升级离开的基线。

使用场景: 把 Kafka 部署到生产的团队

3+ Broker、副本因子 3

每个分区跨 Broker 有一个主、两个从

Producer acks=all 等副本确认后才返回

Broker 失败：自动选举另一个副本为主

KRaft（较新）替代 Zookeeper 做元数据

这样组织的原因: 生产 Kafka 必须副本化——图表展示分区跨 Broker 分布、带主从拆分，这正是 Broker 失败时无数据丢失的保障。

使用场景: 在一个集群运行多种事件类型的团队

多个 Topic（orders、payments、inventory）

每个 Topic 有自己的分区数

不同消费者组订阅不同 Topic

一个服务可以是某 Topic 的生产者、另一个 Topic 的消费者

消费者加入 / 离开时触发组再平衡

这样组织的原因: 多 Topic 是典型生产形态——图表里多个 Topic 各有订阅者，消费者组再平衡是扩缩时重新分配分区的机制。

使用场景: 在 Kafka 之上构建流处理的团队

Kafka Streams 应用从输入 Topic 读、写入输出 Topic

按分区的状态存储（RocksDB），由 changelog Topic 支持

可用 exactly-once 处理语义

通过添加应用实例扩展

无需独立处理集群

这样组织的原因: Kafka Streams 把 Kafka 本身变成流处理器——图表在输入和输出 Topic 之间加入 streams 应用，按分区的状态用 changelog Topic 支撑，无需独立的 Flink 或 Spark 集群。

回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。