4. Kafka 集群部署：单机与集群模式搭建、ZooKeeper/KRaft 模式对比、关键配置参数
在风控 PSI 漂移告警系统中，Kafka 作为事件流的核心总线，其部署模式直接决定了消息投递的可靠性、吞吐量以及运维复杂度。本章将围绕单机与集群的搭建步骤、ZooKeeper 与 KRaft 两种共识机制的选择，以及 acks、replication-factor 等关键参数的调优展开，为后续 PSI 数据流的稳定接入打下基础。
4.1 单机模式 vs 集群模式
单机模式适用于开发测试或低吞吐场景，集群模式则用于生产环境，提供高可用与水平扩展能力。下表从多个维度对比两种模式的核心差异：
| 对比维度 | 单机模式 | 集群模式 |
|---|---|---|
| 节点数量 | 1 个 Broker | ≥3 个 Broker（推荐奇数） |
| 高可用 | 无，单点故障即丢失数据 | 通过副本机制实现故障转移 |
| 吞吐量 | 受单机磁盘/网络限制 | 可线性扩展 |
| 数据持久性 | 依赖单盘 RAID 或备份 | 多副本跨节点冗余 |
| 运维复杂度 | 低，适合快速验证 | 需管理 ZooKeeper 或 KRaft 元数据 |
| 适用场景 | 本地开发、单元测试 | 生产环境、风控实时计算 |
风控建议：PSI 漂移告警对数据完整性要求极高，生产环境至少使用 3 节点集群，并配合
min.insync.replicas=2 防止写入丢失。
4.2 ZooKeeper 模式与 KRaft 模式对比
Kafka 2.8 之前依赖 ZooKeeper 管理集群元数据（Broker 注册、Topic 分区分配、Controller 选举）。2.8 之后引入 KRaft（Kafka Raft）模式，逐步去除外部依赖。下表对比两种模式的关键差异：
| 对比维度 | ZooKeeper 模式 | KRaft 模式 |
|---|---|---|
| 外部依赖 | 需独立部署 ZooKeeper 集群 | 无外部依赖，Kafka 自身管理元数据 |
| Controller 选举 | 通过 ZooKeeper 临时节点实现 | 基于 Raft 协议内部选举 |
| 元数据存储 | ZooKeeper 的 ZNode | Kafka 内部 Topic __cluster_metadata |
| 部署复杂度 | 较高，需维护两套集群 | 较低，单进程即可启动 |
| 成熟度 | 生产验证多年，稳定 | 3.0+ 逐步成熟，3.5+ 推荐生产 |
| 风控场景推荐 | 存量系统兼容 | 新项目首选，运维更简洁 |
迁移提示：若现有风控平台已使用 ZooKeeper 模式，可继续沿用；新建 PSI 漂移告警管道建议直接采用 KRaft 模式，减少运维节点。
4.3 关键配置参数详解
以下三个参数直接影响消息投递的可靠性、吞吐量和数据冗余策略，是风控场景下必须精确调优的配置项。
4.3.1 acks —— 生产者确认级别
- acks=0：生产者发送后不等待确认，吞吐最高，但可能丢失消息。仅用于日志采集等可容忍丢失的场景。
- acks=1：Leader 副本写入本地日志后即返回确认，不等待 Follower 同步。平衡吞吐与可靠性，但 Leader 宕机时可能丢数据。
- acks=all（或
-1）：等待所有 ISR（In-Sync Replicas）副本确认写入后才返回。最强可靠性保证，风控 PSI 数据推荐使用此级别。
4.3.2 replication-factor —— 副本因子
- 定义每个分区的副本数量，包括 Leader 和 Follower。
- 生产环境建议设置为 3，确保单节点故障时仍可选举新 Leader。
- 副本因子过高会占用更多磁盘和网络带宽，需根据集群规模权衡。
- 必须配合
min.insync.replicas使用，例如min.insync.replicas=2，保证至少 2 个副本同步后才确认写入。
4.3.3 其他关键参数
| 参数名 | 推荐值 | 说明 |
|---|---|---|
num.partitions |
3~6（按吞吐调整） | Topic 默认分区数，影响并行消费能力 |
default.replication.factor |
3 | 自动创建 Topic 时的默认副本数 |
min.insync.replicas |
2 | 写入时最少同步副本数，配合 acks=all 使用 |
log.retention.hours |
72（按合规要求） | 消息保留时长，风控审计需保留足够周期 |
compression.type |
lz4 或 zstd | 减少网络带宽和磁盘占用 |
避坑提醒：若
acks=all 但 min.insync.replicas 设置为 1，则实际退化为 acks=1 的可靠性。务必确保 min.insync.replicas ≤ 副本因子，且建议至少为 2。
4.4 集群搭建步骤（KRaft 模式示例）
以下以 3 节点 KRaft 模式为例，展示核心配置与启动流程。假设三台服务器 IP 分别为 192.168.1.10、192.168.1.11、192.168.1.12。
- 生成集群 ID：
./bin/kafka-storage.sh random-uuid # 输出示例：mPn7q9ZxQ2yF3gH4jK5l6N - 配置
server.properties（以节点 1 为例）：
process.roles=broker,controller node.id=1 controller.quorum.voters=1@192.168.1.10:9093,2@192.168.1.11:9093,3@192.168.1.12:9093 listeners=PLAINTEXT://192.168.1.10:9092,CONTROLLER://192.168.1.10:9093 advertised.listeners=PLAINTEXT://192.168.1.10:9092 log.dirs=/data/kafka/logs num.partitions=3 default.replication.factor=3 min.insync.replicas=2 - 格式化存储目录：
./bin/kafka-storage.sh format -t <集群ID> -c config/server.properties - 启动 Kafka 服务：
./bin/kafka-server-start.sh config/server.properties - 验证集群状态：
./bin/kafka-metadata-quorum.sh --bootstrap-server 192.168.1.10:9092 describe --status
生产检查清单：启动前确认所有节点时钟同步（NTP）、文件描述符上限 ≥ 100000、磁盘使用率低于 80%，并配置 JMX 监控 Broker 指标。
4.5 部署架构示意
下图展示了一个 3 节点 KRaft 模式集群的内部组件关系，以及生产者/消费者与 Broker 的交互路径：
上图清晰展示了 KRaft 模式下，每个节点同时承担 Broker 和 Controller 角色，通过 Raft 协议内部协商元数据变更，无需外部 ZooKeeper。生产者写入数据后，副本因子为 3 时，数据自动同步至所有副本，确保风控 PSI 数据不丢失。
4.6 单机快速启动（开发测试用）
若仅需本地验证 PSI 数据流，可使用单机 KRaft 模式快速启动：
# 1. 生成集群 ID
./bin/kafka-storage.sh random-uuid
# 2. 格式化
./bin/kafka-storage.sh format -t <UUID> -c config/server.properties
# 3. 启动
./bin/kafka-server-start.sh config/server.properties
# 4. 创建测试 Topic
./bin/kafka-topics.sh --create --topic psi-drift-test --bootstrap-server localhost:9092 --partitions 3 --replication-factor 1
注意：单机模式下
replication-factor 只能设为 1，且 min.insync.replicas 必须 ≤ 1，否则启动会报错。生产环境务必使用集群模式。