Docker部署Kafka集群需三要素：3节点ZooKeeper+3节点Broker高可用结构、主题分区按业务场景配置（如吞吐选9/12分区、有序消息用key哈希）、副本强制设replication-factor=3并禁用unclean选举。
用 Docker 部署 Kafka 集群并高效管理分区，关键在于三件事：多 Broker 协同运行、ZooKeeper（或 KRaft）元数据强一致性、分区配置与业务场景对齐。不靠堆容器数量，而靠配置逻辑闭环。
集群部署：从单点到高可用的最小可行结构
推荐使用 3 节点 ZooKeeper + 3 节点 Kafka Broker 组成基础高可用单元。Docker Compose 是最稳妥的编排方式：
- ZooKeeper 必须为奇数节点（如 zoo1/zoo2/zoo3），端口统一暴露 2181，通过
server.1=zoo1:2888:3888类似配置实现选举 - 每个 Kafka 服务需设置唯一
KAFKA_BROKER_ID，且KAFKA_ADVERTISED_LISTENERS明确区分容器内互通地址（如PLAINTEXT://kafka1:9092）和宿主机访问地址（如PLAINTEXT_HOST://192.168.1.10:9092） - 所有容器置于同一自定义 Docker 网络，禁用默认桥接网络，避免 DNS 解析失败导致 Broker 无法发现彼此
主题与分区创建：自动初始化与手动控制并存
开发阶段可利用环境变量自动建主题，生产环境建议统一通过脚本或 CI 流程手动创建，确保可追溯：
- 自动创建：在 docker-compose.yml 的 Kafka 服务 environment 中添加
KAFKA_CREATE_TOPICS: "metrics:6:3:delete,events:12:3"，表示分别创建 6 分区/3 副本带 delete 策略、12 分区/3 副本的主题 - 手动创建：进入任一 Kafka 容器执行
kafka-topics.sh --create --bootstrap-server kafka1:9092,kafka2:9092,kafka3:9092 --topic orders --partitions 9 --replication-factor 3 - 注意：分区数一旦设定不能减少，后续扩容只能增加；副本数必须 ≤ Broker 总数，否则创建失败
分区策略设计：匹配吞吐、顺序与扩展性需求
分区不是越多越好，而是要与业务读写模型匹配：
- 高吞吐场景（如日志采集）：分区数设为 Broker 数的整数倍（如 3 Broker → 9 或 12 分区），配合 Producer 默认轮询策略，实现负载分散
- 有序消息场景（如订单状态流）：Producer 发送时指定 key（如
order_id），Kafka 自动哈希路由，保证同 key 消息进同一分区，分区内严格 FIFO - 未来扩容预留：初始分区数建议不低于预期峰值吞吐量 ÷ 1500 条/秒（单分区典型上限），避免频繁调大分区引发重平衡
副本与稳定性保障：让分区真正“可靠”
有分区没副本等于裸奔。高可用的核心参数必须显式配置：
- 创建 Topic 时强制指定
--replication-factor 3，Broker 级配置补充default.replication.factor=3 - 设置
min.insync.replicas=2（对应--min-isr 2），确保写入至少两个同步副本才返回 ACK - 关闭非 ISR 副本选举：
unclean.leader.election.enable=false，防止数据丢失 - 定期用
kafka-topics.sh --describe --topic xxx检查每个分区的 Leader 和 ISR 列表是否完整，ISR 缺失即告警
