Apache Kafka 是一个分布式流处理平台，最初由 LinkedIn 开发，后成为 Apache 顶级项目。它主要用于构建实时数据管道和流式应用，具备高吞吐、低延迟、可扩展、持久化和容错等特性。

核心概念包括：

• Producer（生产者）：向 Kafka 主题（Topic）发布消息。
• Consumer（消费者）：从 Topic 订阅并拉取消息，以组（Consumer Group）形式协作消费，实现负载均衡与容错。
• Topic（主题）：消息的逻辑分类，支持分区（Partition），每个分区是有序、不可变的日志序列。
• Broker（代理）：Kafka 集群中的单个服务器节点，负责存储数据和响应客户端请求。
• Partition（分区）：Topic 的物理分片，支持并行读写；每个分区有多个副本（Replica），其中 Leader 处理读写，Follower 同步数据，保障高可用。
• ZooKeeper（旧版）/ KRaft（新版）：早期依赖 ZooKeeper 管理元数据与协调；自 Kafka 3.3+ 可启用 KRaft（Kafka Raft Metadata Mode）替代 ZooKeeper，实现元数据自治管理。

典型应用场景：日志聚合、事件溯源、实时分析、微服务解耦、CDC（变更数据捕获）等。

# 示例：创建 Topic（使用 KRaft 模式）
kafka-topics.sh --create \
  --bootstrap-server localhost:9092 \
  --topic test-topic \
  --partitions 3 \
  --replication-factor 1

Kafka 分区（Partition）数量的设置是性能调优与架构设计的关键环节，需在吞吐能力、并行度、资源开销、运维复杂度和一致性保障之间取得平衡。以下是系统性分析：

✅ 合理设置分区数的核心原则：

1. 匹配消费者并行度：一个 Consumer Group 中最多只能有 N 个消费者同时消费某 Topic（N = Partition 数），因此分区数应 ≥ 预期最大并发消费者数。
2. 满足目标吞吐量：单分区吞吐受限于单磁盘顺序写/网络带宽（通常单分区稳定写入约 50–100 MB/s，读取略高）。若目标吞吐为 T，单分区吞吐为 t，则最小分区数 ≈ ⌈T / t⌉（建议预留 20–30% 余量）。
3. 避免过度碎片化：每个分区对应独立的日志段（log segment）、索引文件、内核句柄及内存映射（mmap），过多分区会显著增加 Broker 的 JVM 堆外内存压力、文件句柄消耗（ulimit -n）、ZooKeeper/KRaft 元数据负担（尤其旧版元数据路径 /brokers/topics/{topic}/partitions/{p} 爆炸式增长）。
4. 兼顾键控消息（Key-based）语义：若依赖 key → partition 保证同一 key 的消息有序（如用户ID→订单事件），分区数不宜频繁变更（否则 rehash 导致顺序破坏），且应避免因分区数过少导致热点分区（hot partition）。

⚠️ 分区过少的影响：

• 吞吐瓶颈：无法利用多磁盘/多线程并行，整体写入/读取速率受限；
• 消费扩展受限：Consumer Group 无法横向扩容（多余消费者处于空闲状态）；
• 单点压力大：易形成热点，影响稳定性与延迟；
• 副本同步压力集中：Leader-Follower 复制集中在少数分区，拖慢 ISR（In-Sync Replicas）更新。

⚠️ 分区过多的影响：

• Broker 资源耗尽：JVM GC 压力增大（大量 Partition 对象）、文件句柄超限（Linux 默认 1024，需调大）、内存映射区域（mmap）占用激增；
• 启动/重启变慢：Broker 加载所有分区元数据和索引耗时显著增加；
• Leader 选举与元数据传播延迟升高（尤其 ZooKeeper 时代路径爆炸，KRaft 下也增加 Raft 日志负载）；
• 增加运维风险：Rebalance 时间变长、副本同步失败概率上升、监控粒度细化难度加大。

🔧 实践建议（经验值参考）：

• 新 Topic 初始分区数建议：16～32（中小规模集群），可基于压测结果动态调整；
• 单 Broker 分区总数建议 ≤ 2000～4000（取决于硬件：SSD、32GB+ 内存、足够文件句柄）；
• 关键业务 Topic 可适度冗余（如预估需 24 分区 → 设为 32），但避免盲目设为 100+；
• 禁止后期随意增加分区数：虽 kafka-topics.sh --alter 支持扩分，但会导致 key 散列变更、消费者重平衡、历史数据无序（除非不依赖 key 顺序）；缩分区则完全不支持（需重建 Topic + 迁移数据）。

💡 进阶提示：可通过 Kafka 自带指标监控关键信号：

• kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec（按 topic/partition 维度）
• kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions（判断是否因分区过载导致 ISR 缩减）
• kafka.network:type=RequestMetrics,name=RequestsPerSec,request=Fetch（识别消费瓶颈分区）