10.2.1 部署架构选择与节点规划

部署架构选择与节点规划#

架构模式选择#

  • 单机/伪集群：仅用于学习或功能验证，不适用于生产。
  • 小规模生产集群（3–5 节点）：适用于中小流量场景，建议 Broker 与 ZooKeeper 分离或采用 KRaft 模式。
  • 中大型集群（≥6 节点）：按业务域拆分主题，结合机架感知与多可用区部署，提升容灾与扩展能力。

架构原理草图（KRaft 三控制器 + 三Broker）#

文章图片

节点角色与职责#

  • Broker 节点：负责存储与消息传输，数量决定吞吐与容量上限。
  • 控制节点（ZooKeeper/KRaft）：负责元数据与控制平面，需稳定、低延迟。
  • 客户端访问层：可选部署反向代理或负载均衡，统一入口与隔离业务。

角色规划示例（6 节点）#

node1: controller + broker
node2: controller + broker
node3: controller + broker
node4: broker
node5: broker
node6: broker

节点数量与容量规划#

  • 最小高可用：3 Broker + 3 控制节点（或 3 KRaft Controller）。
  • 副本因子：通常设为 3，需确保 Broker 数量 ≥ 副本因子。
  • 分区数：按峰值吞吐与并发需求估算，保证每个 Broker 分区分布均衡。
  • 存储容量：预留数据保留周期 × 峰值写入速率 × 副本因子 × 安全冗余（建议 1.3–1.5）。

容量估算示例（带解释）#

假设：
峰值写入速率 = 80 MB/s
保留周期 = 7 天
副本因子 = 3
冗余系数 = 1.4

原始数据量 = 80 MB/s * 86400 s/天 * 7 天
            = 48,384,000 MB ≈ 46.1 TB

总容量 = 46.1 TB * 3 * 1.4 ≈ 193.6 TB
如果 6 个 Broker，单机磁盘规划 ≈ 32 TB

机房与机架规划#

  • 机架感知：跨机架分布副本，降低单点故障风险。
  • 多可用区：跨 AZ 部署，Broker 与控制节点需同等分散。
  • 网络要求：低延迟、稳定带宽，推荐万兆网络及专用交换。

机架感知示例配置#

# /opt/kafka/config/server.properties
broker.rack=az1-rack1

硬件建议#

  • CPU：8–16 核起步，吞吐型场景可提升到 32 核。
  • 内存：32–64GB，缓存与页缓存影响吞吐。
  • 磁盘：NVMe/SSD 优先，单盘顺序写入能力为关键指标。
  • 网络：10GbE 起步，集群内复制流量需充分带宽。

规划清单#

  • Broker 数量与副本因子匹配
  • 分区数与业务并发匹配
  • 数据保留策略与磁盘容量匹配
  • 机架与可用区分布均衡
  • 监控与告警节点独立部署

安装与基础校验示例（用于规划验证）#

目的：快速启动最小 KRaft 集群，验证节点规划与资源占用。
说明：以下仅用于规划验证，生产请见后续章节的完整安装流程。

# 1) 下载并解压
cd /opt
curl -LO https://downloads.apache.org/kafka/3.6.1/kafka_2.13-3.6.1.tgz
tar -xzf kafka_2.13-3.6.1.tgz
ln -s kafka_2.13-3.6.1 kafka

# 2) 生成集群ID（控制节点需要一致）
/opt/kafka/bin/kafka-storage.sh random-uuid
# 例输出: w5MZ1l2fQx2m0g5n8hG9xQ

# 3) 初始化存储（每台节点执行，替换 KRAFT_CLUSTER_ID）
export KRAFT_CLUSTER_ID=w5MZ1l2fQx2m0g5n8hG9xQ
/opt/kafka/bin/kafka-storage.sh format -t $KRAFT_CLUSTER_ID -c /opt/kafka/config/kraft/server.properties

# 4) 启动（仅验证用）
/opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/kraft/server.properties

命令解释：
- kafka-storage.sh random-uuid：生成 KRaft 集群唯一 ID。
- kafka-storage.sh format：初始化元数据目录，未执行会导致启动失败。
- kafka-server-start.sh -daemon：后台启动进程，规划验证用。

排错与验证#

# 查看进程与监听端口
ps -ef | grep kafka
ss -lntp | grep 9092

# 查看控制器是否正常选主
/opt/kafka/bin/kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe

# 查看日志（常见启动失败信息）
tail -n 200 /opt/kafka/logs/server.log

常见问题与处理：
- 错误：No readable meta.properties
原因：未执行 kafka-storage.sh format
处理：按上文第3步格式化。
- 错误：Port 9092 already in use
原因：端口冲突或残留进程
处理：lsof -i:9092 查找占用并停止。

练习#

  1. 设计一个 6 节点集群（3 控制器 + 6 Broker），计算 7 天保留、峰值 50MB/s 的总容量与单机容量。
  2. 在 3 台虚拟机上模拟跨机架部署，为每台配置 broker.rack 并说明副本分布预期。
  3. 使用上述最小集群启动命令，验证 kafka-metadata-quorum.sh 的输出是否包含 3 个控制器。