为什么需要有Topic？

Topic是一个消息的逻辑分类。Kafka为什么需要Topic，就是Kafka为什么需要对消息进行逻辑上的分类。

在一个小型电商项目中，如果订单模块和商品模块都需要使用消息队列。两个模块中的消息一个是订单信息，一个是商品的描述消息。两种消息肯定不是同一类的消息，它们消息内容不一样、结构不一样、并且分别有自己的生产者群体和消费者群体。

Kafka消息系统是一个庞大的系统，不可能针对两个模块都各自搭建一套kafka消息系统。那么如何在一套消息系统中为多个模块提供服务。那就要对不同类型的消息进行逻辑分类，具体分类的方式就是用Topic进行区分，不同类别的消息具有不同的Topic。

既然Kafka通过Topic唯一标示每类消息，那么，

每条消息属于且仅属于一个Topic
Producer发布数据时，必须指定将该消息发布到哪个Topic
Consumer消费消息时，也必须指定消费哪个Topic的信息

基础操作

1.1 创建topic

创建一个topic（主题）。Kafka中所有的消息都是保存在主题中，要生产消息到Kafka，首先必须要有一个确定的主题。

# 创建名为test的主题
bin/kafka-topics.sh --create --bootstrap-server node1:9092 --topic test
# 查看目前Kafka中的主题
bin/kafka-topics.sh --list --bootstrap-server node1:9092

1.2 生产消息到Kafka

使用Kafka内置的测试程序，生产一些消息到Kafka的test主题中。

bin/kafka-console-producer.sh --broker-list node1:9092 --topic test

1.3 从Kafka消费消息

使用下面的命令来消费 test 主题中的消息。

bin/kafka-console-consumer.sh --bootstrap-server node1:9092 --topic test --from-beginning

1.4 使用Kafka Tool操作Kafka

1.4.1 连接Kafka集群

安装Kafka Tools后启动Kafka

1.4.2 创建topic

Kafka基准测试

2.1 基准测试

基准测试（benchmark testing）是一种测量和评估软件性能指标的活动。我们可以通过基准测试，了解到软件、硬件的性能水平。主要测试负载的执行时间、传输速度、吞吐量、资源占用率等。

2.1.1 基于1个分区1个副本的基准测试

测试步骤：

1. 启动Kafka集群

2. 创建一个1个分区1个副本的topic: benchmark

3. 同时运行生产者、消费者基准测试程序

4. 观察结果

2.1.1.1 创建topic

bin/kafka-topics.sh --zookeeper node1:2181 --create --topic benchmark --partitions 1 --replication-factor 1

2.1.1.2 生产消息基准测试

在生产环境中，推荐使用生产5000W消息，这样会性能数据会更准确些。为了方便测试，课程上演示测试500W的消息作为基准测试。

bin/kafka-producer-perf-test.sh --topic benchmark --num-records 5000000 --throughput -1 --record-size 1000 --producer-props bootstrap.servers=node1:9092,node2:9092,node3:9092 acks=1

bin/kafka-producer-perf-test.sh --topic topic的名字

--num-records 总共指定生产数据量（默认5000W）

--throughput 指定吞吐量——限流（-1不指定）

--record-size record数据大小（字节）

--producer-props bootstrap.servers=192.168.1.20:9092,192.168.1.21:9092,192.168.1.22:9092 acks=1 指定Kafka集群地址，ACK模式

测试结果：

2.1.1.3 消费消息基准测试

bin/kafka-consumer-perf-test.sh --broker-list node1:9092,node2:9092,node3:9092 --topic benchmark --fetch-size 1048576 --messages 5000000

bin/kafka-consumer-perf-test.sh

--broker-list 指定kafka集群地址

--topic 指定topic的名称

--fetch-size 每次拉取的数据大小

--messages 总共要消费的消息个数

如何规划 Kafka Topic

在构建基于Kafka的应用架构时，合理规划Kafka Topic至关重要，这直接关系到系统的扩展性、稳定性和数据管理的便利性。

依据业务领域划分

将不同业务模块或功能产生的数据分别发送到各自独立的Topic中。例如，在一个电商系统里，订单相关的消息可以发送到“order_topic”，用户行为数据发送到“user_behavior_topic”，商品信息变更发送到“product_info_topic”等。这样做的好处是当某个业务模块的数据处理逻辑发生变化或者需要单独扩展时，不会影响到其他业务领域的Topic，便于进行针对性的维护和优化。

考虑数据量和吞吐量

如果某些数据的产生量和消费速度较大，应单独设置Topic，并根据实际情况为其分配足够的分区。比如日志数据，通常会有大量的日志持续产生，为其创建专门的“log_topic”，并依据数据量预估设置多个分区，以确保数据能够快速写入和被消费，避免因数据积压导致的性能问题。对于数据量较小且频率较低的业务数据，可以适当合并到一个Topic中，但也要注意避免过度合并造成的管理混乱。

数据一致性和完整性需求

对于那些需要保证数据完整性和顺序性的业务场景，应将相关数据放在同一个Topic中，并确保这些数据由同一个生产者按照顺序写入，消费者也按照顺序消费。例如，在金融交易系统中，一笔交易的各个环节数据（如交易发起、资金冻结、交易完成等）需要保证顺序和完整性，那么这些数据就应该存放在同一个“transaction_topic”中，并且采用合适的分区策略和消费者组配置来确保数据的一致性处理。

与数据存储和处理系统的适配

考虑到下游的数据存储和处理系统，如将数据写入数据库、数据仓库或者进行实时数据分析等，规划Topic时应使其与这些系统的架构和数据摄取方式相匹配。如果数据要写入到不同的数据库表中，那么可以按照目标表来划分Topic，方便后续的数据加载和转换操作。

命名规范

采用清晰、具有描述性的Topic命名规则，能够快速传达Topic所包含的数据内容和用途。命名可以包含业务领域、数据类型等关键信息，如“finance_report_data_topic”“marketing_campaign_event_topic”等，避免使用过于模糊或随意的名称，方便团队成员理解和管理。

通过以上几个方面的综合考虑，应用程序能够更科学、合理地规划Kafka Topic，为整个系统的高效稳定运行奠定坚实基础，充分发挥Kafka在数据流转和处理中的优势，提升系统的整体性能和可维护性。

总结

Kafka Topic 是 Kafka 消息队列中的核心概念，它提供了数据分类、隔离和并行处理的机制，帮助生产者和消费者之间实现解耦和高效通信。合理规划 Kafka Topic 对于构建高性能、高可用的数据处理系统至关重要，需要根据业务领域、数据量、一致性需求等因素来设计和管理 Topic，以确保系统的稳定性和可扩展性。