2. Kafka主题与分区建模
在 Kafka 中，主题（Topic）是逻辑上的消息分类，分区（Partition）才是物理存储与并行处理的基本单元。数据建模的第一步，往往不是写 SQL 或定义 Schema，而是决定“一个业务事件应该落到哪个主题、拆成多少分区、副本放在哪里”。这一节围绕主题设计原则、分区策略、副本机制、数据分布与并行度规划展开，目标是让读者能够为一个真实场景设计出可落地、可扩展、可运维的主题结构。
一、主题设计原则：先定边界，再定粒度
主题设计的核心是“边界”问题。一个常见误区是按数据库表一一对应建主题，例如 orders、order_items、order_payments 各建一个主题。这在写入侧看似清晰，但在消费侧会迫使下游做多流 Join，且难以保证同一订单的事件顺序。更合理的做法是按“业务事件流”划分主题，例如 order-events 承载订单创建、支付、取消等事件，用事件类型字段区分，而不是用主题区分。
主题命名应遵循可读、可治理的规范。推荐采用 <域>.<实体>.<事件类型> 或 <环境>.<域>.<实体>.<版本> 的形式，例如 prod.trade.order.created.v1。命名中避免使用日期、临时编号或消费者名称，因为主题是生产端与消费端之间的契约，一旦创建就不应随意变更语义。
主题数量并非越多越好。每个分区在 Broker 上对应一个日志目录和若干索引文件，分区总数过多会显著增加 Controller 元数据压力、副本同步开销和故障恢复时间。经验上，单集群分区总数控制在数万级别较为稳妥；若业务确实需要大量主题，应优先考虑合并同类事件、使用 Compact 主题或引入分层存储。
二、分区策略：决定消息如何分布
分区策略回答的是“一条消息进入主题后，落到哪个分区”。Kafka 生产者默认使用分区器（Partitioner），其行为随版本演进：早期默认对消息 Key 做哈希后取模；Kafka 2.4 之后，若未指定 Key，则采用粘性分区（Sticky Partitioner），在一批消息内尽量填满同一分区，减少小批量请求，提升吞吐。
当指定 Key 时，分区计算通常为 partition = murmur2(key) % numPartitions。这意味着相同 Key 的消息一定进入同一分区，从而保证该 Key 内的顺序。例如以 order_id 为 Key，则同一订单的所有事件有序；但不同订单之间无序。若业务要求全局有序，只能使用单分区主题，代价是并行度归零，通常只适用于极低吞吐的控制类消息。
自定义分区策略适用于有明确路由需求的场景。例如需要将大客户流量隔离到独立分区，或按地理区域路由。实现时需注意：分区数变化后，key % numPartitions 的结果会改变，导致同一 Key 的历史消息与新消息落在不同分区。因此，若使用 Key 哈希，应尽量避免在运行中增加分区；若必须扩容，需接受短暂的重分布并评估下游状态。
三、副本机制：可用性与一致性的权衡
每个分区可配置多个副本（Replica），其中一个是 Leader，其余为 Follower。生产者和消费者只与 Leader 交互，Follower 主动拉取 Leader 的日志以保持同步。副本分布由 Kafka 自动分配，通常跨 Broker 和机架，以降低单点故障影响。
关键参数包括 replication.factor（副本数）和 min.insync.replicas（最小同步副本数）。若 replication.factor=3、min.insync.replicas=2，则生产者设置 acks=all 时，至少两个副本写入成功才返回确认。这能在允许一个副本故障的同时，避免数据丢失。若 min.insync.replicas=1，则 Leader 写入即确认，故障时可能丢数据。
ISR（In-Sync Replica）是副本机制的核心概念。只有与 Leader 保持同步的副本才在 ISR 中。当 Follower 落后超过 replica.lag.time.max.ms，会被移出 ISR。Leader 故障时，Controller 从 ISR 中选举新 Leader；若 ISR 为空且 unclean.leader.election.enable=true，则可能选举落后副本，造成数据丢失。生产环境通常建议保持该参数为 false。
四、数据分布与并行度规划
分区数直接决定消费者组的最大并行度：一个分区在同一消费者组内只能被一个消费者实例消费。因此，若期望 12 个消费者并行处理，主题至少需要 12 个分区。但分区数并非越大越好，它同时影响生产端缓冲、Broker 文件句柄、端到端延迟和再均衡时间。
一个实用的估算方法是：先根据目标吞吐和单分区吞吐能力计算下限。假设单分区可稳定处理 10 MB/s，目标峰值吞吐为 120 MB/s，则至少需要 12 个分区；再结合消费者并行度需求，取两者较大值，并预留 20%～30% 余量。例如最终选择 16 个分区。若使用 Key 哈希，还需确保分区数在业务生命周期内相对稳定，避免频繁扩容。
数据分布还涉及“热点分区”问题。若 Key 分布不均，例如某几个大客户订单量远超其他客户，则对应分区会成为热点，导致 Broker 磁盘和网络倾斜。此时可考虑复合 Key（如 customer_id + order_id）、自定义分区器或拆分主题。监控上应关注各分区的字节速率、消息速率和 Leader 副本的磁盘使用，判断是否存在明显倾斜。
五、一个可参考的主题建模检查表
下面给出一份可直接用于评审的主题建模检查表，字段和判断依据均围绕 Kafka 主题与分区设计，不引入无关管理项。
| 检查项 | 判断依据 | 示例值 |
|---|---|---|
| 主题边界 | 是否按业务事件流划分，而非按数据库表 | order-events 而非 orders + order_items |
| 命名规范 | 是否包含环境、域、实体、版本 | prod.trade.order.created.v1 |
| 分区数 | 是否满足消费者并行度与吞吐下限 | 16 分区，峰值 120 MB/s |
| Key 设计 | 是否保证业务顺序且避免热点 | order_id 或 customer_id + order_id |
| 副本配置 | 是否允许单副本故障且不丢数据 | RF=3, min.insync=2, acks=all |
| 保留策略 | 是否按时间或大小设置，是否启用 Compact | retention.ms=604800000 |
| 监控指标 | 是否覆盖分区倾斜、ISR 收缩、消费延迟 | BytesInPerSec、UnderReplicatedPartitions |
kafka-topics.sh --create 或 AdminClient 在测试环境验证分区与副本分配；生产环境建议通过 IaC 或 Schema Registry 管理主题元数据，避免手工创建导致命名和配置不一致。
总结来看，主题与分区建模不是一次性的配置动作，而是贯穿数据生命周期的设计决策。主题边界决定了下游消费的便利性，分区策略决定了顺序与并行度的平衡，副本机制决定了可用性与一致性，而数据分布与并行度规划则直接影响集群的稳定性和成本。把这四者放在一起考虑，才能设计出既满足业务语义、又经得起流量增长考验的 Kafka 主题结构。