3个Broker、12个Partition够不够？——聊聊你们Kafka集群怎么规划的
先说结论
Kafka的核心架构由5个角色组成：Producer（生产者）、Broker（服务节点）、Topic（逻辑分类）、Partition（物理分片）、Consumer Group（消费者组）。数据流向：Producer → Broker集群 → Consumer Group。
面试加分的关键不是背这5个名词，而是讲清楚三个'为什么'：为什么要有Partition（并行度+局部有序）、为什么要有Consumer Group（消费隔离+负载均衡）、ZooKeeper/KRaft在其中扮演什么角色。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
面试官问Kafka架构，不是让你背名词。他真正想知道的是：你生产环境的Kafka集群长什么样？Broker几个、Topic怎么设计、Partition怎么定的？为什么这么定？我在某元宇宙社交公司从0搭建Flink+Kafka+Doris的实时数仓，这些问题全部亲手做过决策，今天把整套思路讲清楚。
从我实际搭建的架构说起
这家公司做的是元宇宙UGC社交APP，用户可以送虚拟礼物、创建虚拟空间。我当时要处理两类数据：一是用户行为埋点（通过第三方SDK收集），二是虚拟礼物交易流水（通过FlinkCDC从MySQL同步）。整个实时链路是这样的：
# 实时数仓架构（我从0搭建的）
#
# 埋点SDK ──→ Kafka Cluster ──→ Flink DataStream ──→ Doris
# FlinkCDC（MySQL）──→ Kafka ──→ Flink ──→ Doris
#
# Kafka Cluster（3 Brokers，Ambari管理）
# ┌───────────────────────────────┐
# │ Broker-0 Broker-1 Broker-2│
# └───────────────────────────────┘
# user_event P0,P3 P1,P4 P2,P5 ← 6个Partition
# gift_txn P0,P3 P1,P4 P2,P5 ← 6个Partition
# user_sync P0 P1 P2 ← 3个Partition（CDC）
#
# 用Know Streaming管理Kafka，StreamPark提交Flink任务为什么是3个Broker？因为Kafka副本一般设3个（replication.factor=3），3个Broker刚好每个副本分布在不同Broker上，任何一台挂了数据都不丢。这是最小的高可用配置。
5个核心角色的生产实战理解
① Producer：有两类。一类是第三方埋点SDK收集的用户行为数据直接写入Kafka；另一类是FlinkCDC读取MySQL的binlog，把业务数据（用户表、礼物交易表）同步到Kafka。Producer直接和Broker通信，不经过中间层。
② Broker：每个Broker就是一个Kafka进程。我们用Ambari搭建Hadoop平台，Kafka也跑在上面。3个Broker，每台16核64GB内存，1TB SSD。
③ Topic + Partition：Topic按业务域划分：user_event（用户行为）、gift_txn（礼物交易）、user_sync（用户维度CDC同步）。Partition决定了并行度——下游Flink的并行度不能超过Partition数。
④ Consumer Group：Flink作为Consumer，每个Flink Job就是一个Consumer Group。不同Job各自消费互不影响。比如实时大盘和实时风控是两个Job，各有独立的offset。
⑤ ZooKeeper：当时用ZooKeeper管理元数据。Kafka 3.x开始有KRaft模式，把元数据管理内置到Kafka自身。后来在短剧出海公司用的是云托管Kafka，不用自己管ZK。
Partition数怎么定？——我的实战经验
| Topic | Partition数 | 决策依据 | 下游Consumer |
|---|---|---|---|
| user_event | 6 | 日均5000万条，高峰QPS约1.5万 | Flink 6并行度 |
| gift_txn | 6 | 交易数据量不大但不能丢 | Flink 6并行度 |
| user_sync | 3 | CDC同步量小，3个够了 | Flink 3并行度 |
Partition数的经验公式：Partition数 >= 下游Consumer数。如果12个Partition只有6个Consumer，每个Consumer消费2个Partition没问题；但6个Partition配12个Consumer，有6个完全空闲，浪费资源。
踩坑提醒：Partition数只能增加不能减少。增加后按Key分区的消息会被打散，历史数据的分区逻辑会乱。所以一开始要留够余量，按预期流量的1.5-2倍来设。
面试高频追问
追问一：Kafka为什么吞吐量这么高？
四个原因：① 顺序写磁盘（追加写，磁盘顺序写接近内存速度）；② 零拷贝（sendfile系统调用，数据不经过用户态）；③ Partition并行（多Partition同时读写）；④ 批量发送+压缩。第5篇会详细讲。
追问二：Kafka 3.x的KRaft和ZooKeeper有什么区别？
KRaft把元数据管理内置到Kafka自身，用Raft协议做共识。好处是部署更简单、启动更快、元数据操作性能更好。但很多生产环境还在用ZooKeeper，包括我之前搭建的那套集群。
追问三：你用什么工具管理Kafka集群？
我用Know Streaming的Web界面看Topic、Partition分布、Consumer Lag，很直观。Flink任务用StreamPark提交和管理。这两个工具配合起来，Kafka+Flink的运维效率很高。
总结
Kafka架构面试不要只背名词。先画出数据流向（Producer → Broker → Consumer），再结合项目讲清楚：Topic怎么按业务域划分、Partition数怎么定（和下游Consumer的关系）、为什么用3个Broker（高可用最小配置）。能说出具体数字，面试官就知道你是真正用过Kafka的人。
下一篇聊一个非常高频的面试题：Producer发消息时acks=0、1、all到底选哪个？广告归因数据丢了一条，ROI算错了怎么办？
你们生产环境Kafka集群几个Broker？Partition数怎么定的？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长