Kafka Topic 是 Kafka 消息队列中的核心概念。它既是消息分类的逻辑容器，也是生产者和消费者之间解耦的边界。Topic 规划是否合理，会直接影响数据隔离、消费并行度、顺序性、容量规划和后续运维复杂度。
核心要点
- Topic 用来承载某一类消息，生产者向 Topic 写入消息，消费者订阅 Topic 读取消息。
- Partition 是 Topic 内部的并行单元，决定写入、存储和消费的并行能力。
- Replica 用来提升可用性和可靠性，分区副本会分布在不同 Kafka broker 上。
- Topic 不宜只按“系统名称”粗暴划分，应结合业务领域、数据量、顺序性和下游处理方式设计。
- 清晰的命名规范比后期口头约定更可靠，能降低排障、权限管理和数据治理成本。
Kafka Topic 是什么
Kafka Topic（主题）是消息的分类或逻辑容器。生产者（Producer）把消息发送到指定 Topic，消费者（Consumer）从订阅的 Topic 中接收消息。
可以把 Topic 理解为一个新闻频道。生产者像新闻记者，把不同类型的消息发送到对应频道；消费者像观众，只订阅自己关心的频道。通过 Topic，生产者不需要知道消费者是谁，消费者也不需要知道消息由哪个生产者生成。
在工程实践中，Topic 通常对应一类稳定的数据流，例如订单事件、库存变更、用户行为、日志数据或营销活动事件。
Kafka Topic 的结构
Partition：并行处理的基本单元
每个 Topic 可以包含一个或多个 Partition。Partition 是 Kafka 实现并行写入、并行消费和高吞吐的关键机制。
消息写入 Topic 时，会被分配到不同分区。例如，一个名为 sales_data 的 Topic 有 3 个分区，生产者发送的销售数据会根据轮询、基于 key 的哈希等策略进入不同分区。
Partition 还有一个重要特点：分区内消息按追加顺序存储，分区内顺序可以保证。对于金融交易流水这类关注顺序的场景，通常需要通过合理的 key 设计，让同一业务对象的相关消息进入同一个分区。
Replica：可用性和可靠性的基础
为了提升可用性和数据可靠性，Topic 的分区可以有多个 Replica。副本分布在不同 Kafka broker 上。当某个 broker 故障时，其他副本可以继续提供服务。
例如，一个分区有 3 个副本，其中一个副本所在 broker 宕机后，Kafka 可以从其他正常副本中选举新的 Leader Replica 负责处理读写请求。
Topic、Partition、Replica 的关系
| 概念 | 作用 | 规划时关注点 |
|---|---|---|
| Topic | 消息分类和业务隔离 | 业务边界、数据类型、生命周期 |
| Partition | 并行写入和并行消费 | 吞吐量、消费者并发、顺序性 |
| Replica | 高可用和容灾 | broker 数量、故障恢复、存储成本 |
Kafka Topic 的作用
解耦生产者和消费者
Topic 降低生产者和消费者之间的耦合。生产者只需要把消息发到对应 Topic，不需要关心有哪些消费者；消费者只需要订阅感兴趣的 Topic，不需要了解消息如何产生。
例如在物联网系统中，传感器可以把环境数据发送到 environment_data Topic，数据分析系统和监控系统分别作为消费者订阅同一 Topic，各自独立处理数据。
数据分类和隔离
Topic 可以按数据类型或业务领域进行隔离。例如电商系统中：
order_topic处理订单相关消息。inventory_topic处理库存相关消息。user_behavior_topic处理用户行为数据。
这种划分可以让不同业务数据独立扩展、独立监控，也便于权限控制和故障定位。
提升并行处理能力
Topic 通过 Partition 提供并行能力。分区数越多，理论上可支持更多并行消费者和更高吞吐。但分区并不是越多越好，过多分区会增加 broker、controller、客户端和运维管理成本。
如何规划 Kafka Topic
规划 Topic 的目标不是“建得越细越好”，而是让数据边界清楚、吞吐可扩展、顺序性可控、下游处理方便。
1. 按业务领域划分
将不同业务模块或功能产生的数据发送到各自独立的 Topic。例如：
- 订单消息进入
order_topic。 - 用户行为数据进入
user_behavior_topic。 - 商品信息变更进入
product_info_topic。
这样做的好处是，当某个业务模块的数据处理逻辑变化，或需要单独扩容时，不会影响其他业务领域的 Topic。
2. 按数据量和吞吐量评估分区
如果某类数据产生量大、消费速度要求高，应单独设置 Topic，并为其分配足够分区。例如日志数据通常持续、大量产生，可以创建专门的 log_topic，并根据写入量和消费并发预估分区数。
对于数据量较小、频率较低、生命周期和权限要求相近的数据，可以适当合并到同一个 Topic。但不要为了减少 Topic 数量而过度合并，否则后续排障和消费逻辑会变复杂。
3. 根据顺序性和完整性设计 key
对于需要保证顺序和完整性的业务场景，应保证相关数据进入同一 Topic，并通过合适的分区策略让同一业务对象进入同一分区。
例如金融交易系统中，一笔交易的多个环节数据，如交易发起、资金冻结、交易完成，通常需要保持顺序。此时可以使用交易 ID 作为消息 key，让同一交易的事件进入同一分区，消费者再按分区顺序处理。
4. 适配下游存储和处理系统
Topic 规划还要考虑下游系统，例如数据库、数据仓库、实时分析引擎或告警系统。如果下游要写入不同数据库表，可以按目标表或数据模型划分 Topic，便于后续加载、转换和回放。
如果下游消费系统对数据格式、消费延迟或权限边界要求不同，也应避免把差异过大的数据混在同一个 Topic 中。
5. 建立命名规范
Topic 名称应清晰、稳定、可读，能表达业务领域和数据含义。例如：
finance_report_data_topicmarketing_campaign_event_topicorder_status_event_topic
命名时避免使用过于模糊的名称，例如 data_topic、test_topic、new_topic。模糊名称会在 Topic 数量增长后带来理解和治理成本。
Topic 规划检查表
| 问题 | 判断目的 |
|---|---|
| 这个 Topic 承载哪类业务事件或数据？ | 确认业务边界 |
| 生产者和消费者分别是谁？ | 确认上下游依赖 |
| 是否需要保证同一业务对象的消息顺序？ | 决定 key 和分区策略 |
| 数据量和消费并发大概是什么级别？ | 决定是否单独 Topic 和分区数量 |
| 下游是否写入不同系统或不同表？ | 决定是否按目标模型拆分 |
| Topic 名称是否能被新人直接理解？ | 降低长期维护成本 |
FAQ
一个业务系统只建一个 Topic 可以吗？
可以，但通常不建议作为默认做法。如果一个系统内的数据类型、生命周期、消费方和权限边界差异很大，全部放在一个 Topic 会降低可维护性。
Topic 越多越好吗？
不是。Topic 过多会增加管理成本，分区过多也会增加 Kafka 集群负担。合理做法是按业务边界和数据特征拆分，而不是按每个接口、每个字段或每个临时需求拆分。
分区数如何决定？
原文没有给出固定公式。实践中应结合写入吞吐、消费并发、消息顺序要求和 broker 资源评估。需要严格顺序的业务，不能只为了并发而随意增加分区。
总结
Kafka Topic 负责消息分类、数据隔离和生产消费解耦；Partition 决定并行能力；Replica 提供高可用基础。规划 Topic 时，应围绕业务领域、数据量、顺序性、下游系统和命名规范做决策。好的 Topic 设计不是数量最多，而是边界清晰、扩展可控、排障方便。
