4. Kafka集群规划
银行交易事件平台对Kafka的要求与一般互联网场景不同：交易事件不可丢失、峰值集中、审计合规严格、故障恢复时间被写入SLA。因此集群规划不是“装几台机器”的问题，而是围绕可用性、吞吐、延迟、可运维性四个目标做系统性取舍。本节从元数据模式、Broker部署、硬件选型、网络与磁盘四个维度展开。
一、核心原理：元数据模式决定集群骨架
Kafka集群的元数据管理有两种模式。ZooKeeper模式中，Broker将Controller选举、Topic配置、ACL、ISR变更等元数据写入ZooKeeper，由ZooKeeper负责一致性；KRaft模式则把元数据作为内部Topic写入Kafka自身，由一组Controller节点通过Raft协议维护。KRaft消除了外部依赖，Controller故障切换从秒级降到毫秒级，且支持更大规模的分区元数据。
KRaft下节点角色分为broker、controller、broker,controller。生产环境推荐Controller独立部署，数量为3或5，保证Raft多数派；Broker只负责数据读写，避免元数据压力与数据流量互相干扰。
二、方法流程：Broker部署与容量规划
Broker部署的核心是“分区分布均匀、副本跨机架、单节点故障不丢数据”。规划流程如下：
- 确定分区数：按目标吞吐除以单分区吞吐估算。银行交易单分区写入约10~30MB/s，若峰值200MB/s，至少8~12个分区，再乘以2~3倍冗余。
- 设置副本因子：交易事件用
replication.factor=3，min.insync.replicas=2，配合Produceracks=all，保证至少两份副本落盘才确认。 - 机架感知：配置
broker.rack，让副本分布到不同机架/可用区，避免单机架断电导致分区不可用。 - 节点数量：Broker数 ≥ 副本因子 + 1，且建议为3的倍数，便于均匀分布。
# server.properties 关键配置（KRaft Broker）
process.roles=broker
node.id=1
controller.quorum.voters=1@ctrl1:9093,2@ctrl2:9093,3@ctrl3:9093
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
log.dirs=/data1/kafka-logs,/data2/kafka-logs
num.partitions=12
default.replication.factor=3
min.insync.replicas=2
broker.rack=az-1
log.retention.hours=168
log.segment.bytes=1073741824三、硬件选型、网络与磁盘规划
银行交易平台硬件选型遵循“磁盘优先、内存适中、网络冗余”的原则。Kafka是顺序写磁盘的系统，磁盘吞吐和IOPS比CPU更关键；JVM堆不宜过大，否则GC停顿影响延迟。
| 资源 | 推荐配置 | 说明 |
|---|---|---|
| CPU | 16~32核 | 压缩、TLS、副本复制消耗CPU |
| 内存 | 64~128GB，堆6~8GB | 其余留给页缓存，提升读性能 |
| 磁盘 | NVMe SSD，多盘JBOD | 顺序写吞吐高，避免RAID5写惩罚 |
| 网络 | 双万兆绑定 | 副本复制与客户端流量分离 |
| 文件系统 | XFS | 大文件顺序写表现稳定 |
磁盘规划建议每块盘独立挂载，log.dirs配置多个目录，Kafka会自动均衡分区。保留策略按合规要求设置，交易事件通常保留7~30天，冷数据归档到对象存储。
四、案例与误区复盘
案例：某银行交易事件平台初期用3台Broker、ZooKeeper 3节点，单分区副本因子2。大促期间一台Broker宕机，部分分区只剩1份副本，Producer acks=all超时，交易事件积压。复盘后改为5台Broker、副本因子3、min.insync.replicas=2，并将Controller独立部署，故障切换时间从8秒降到1秒内。
broker.rack，副本集中在同一机架；⑤ 分区数过少，无法水平扩展消费能力。集群规划完成后，应通过压测验证：模拟单Broker宕机、单机架断电、磁盘写满等场景，确认副本同步、Controller切换、客户端重试均符合SLA。规划不是一次性工作，需随交易量增长定期复核分区数、磁盘水位和网络带宽。