Topic和Partition的关系是什么？为什么需要分区？ （Topic是逻辑分类，Partition是物理分片；提升并行度和扩展性）

Kafka Topic与Partition关系详解

1. 核心关系图解

┌───────────────────┐
│      Topic         │
│  (订单系统消息)      │
└─────────┬──────────┘│▼
┌───────────────────┐   ┌───────────────────┐   ┌───────────────────┐
│   Partition 0      │   │   Partition 1     │   │   Partition 2     │
│ (物理存储分片)       │   │ (物理存储分片)     │   │ (物理存储分片)      │
└───────────────────┘   └───────────────────┘   └───────────────────┘

2. 特性对比表

	Topic	Partition
性质	逻辑消息分类（类似数据库表）	物理存储单元（类似表分片）
存储方式	分布式存储在多个Partition	顺序不可变的消息队列
扩展性	通过增加Partition实现扩展	单个Partition不可拆分
顺序性保障	整体无序	Partition内部严格有序

3. 分区必要性分析

1. 并行处理扩展

// 生产者分区路由策略示例
ProducerRecord<String, String> record = new ProducerRecord<>("order_topic", order.getOrderId(), // 分区键order.toJSON()
);

• 通过订单ID哈希路由到不同分区
• 每个分区可被不同消费者并行处理

2. 吞吐量提升

单分区吞吐量：50,000 msg/s
三分区吞吐量：150,000 msg/s  ← 线性扩展

3. 数据分布式存储

# 查看topic分区分布
bin/kafka-topics --describe --topic order_topic --bootstrap-server localhost:9092# 输出示例：
Partition: 0  Leader: 1  Replicas: 1,2  Isr: 1,2
Partition: 1  Leader: 2  Replicas: 2,3  Isr: 2,3
Partition: 2  Leader: 3  Replicas: 3,1  Isr: 3,1

• 分区副本分布在多个Broker
• 读写负载自动均衡

4. 消费组并行度控制

// 消费者并发数配置
props.put("max.poll.records", 500);      // 单次最大拉取量
props.put("fetch.max.bytes", 52428800);  // 50MB/次

• 消费者线程数 <= Partition数
• 自动实现负载均衡

4. 分区策略选择

策略类型	适用场景	特点
Hash(key)	订单/会话类数据	相同key路由到固定分区
Round-Robin	无状态日志类数据	均匀分配写入负载
自定义策略	特殊路由需求	实现Partitioner接口