3. Confluent集群部署架构验收

Confluent集群部署架构验收的核心目标，是确认“控制面、数据面、跨中心复制面”三层拓扑与设计一致，并且任意单点故障不会导致集群不可用或数据不可恢复。验收对象包括Broker节点、KRaft控制器（或ZooKeeper集群，视版本而定）、以及多数据中心部署中的复制链路。验收不是简单看进程是否启动，而是通过拓扑核对、角色确认、副本分布检查和故障注入，验证高可用是否真实成立。

一、先确认控制面形态：KRaft还是ZooKeeper

Confluent Platform 7.x及以后版本推荐使用KRaft模式，ZooKeeper模式仍存在于部分存量集群。验收第一步必须明确当前集群属于哪种控制面，因为两者的检查项完全不同。

KRaft模式下，节点分为Controller、Broker和Controller+Broker混合角色。验收时要确认Controller数量为奇数（通常3或5个），且与Broker角色在物理或逻辑上分离。可通过以下命令查看节点注册情况：

kafka-metadata-quorum --bootstrap-server broker1:9092 describe --status
kafka-metadata-quorum --bootstrap-server broker1:9092 describe --replication

输出中应看到CurrentVoters包含全部Controller节点，且Leader唯一。若某个Controller长期不在Voters列表中，说明它未成功加入仲裁，高可用存在缺口。

ZooKeeper模式下，验收重点是ZooKeeper集群的节点数、myid配置、以及Broker与ZooKeeper的会话状态。使用 echo stat | nc zk1 2181 或 zkServer.sh status 可确认follower/leader角色。ZooKeeper节点数同样应为奇数，且Broker的zookeeper.connect应指向全部ZK节点，避免单点。

二、Broker拓扑与副本分布验证

Broker验收不能只看systemctl status。需要确认每个Broker的broker.id唯一、listeners与advertised.listeners可被其他节点和客户端正确解析，以及机架信息broker.rack已配置。机架感知是跨机架副本分布的前提。

使用以下命令查看Broker列表与机架：

kafka-broker-api-versions --bootstrap-server broker1:9092
kafka-topics --bootstrap-server broker1:9092 --describe --under-replicated-partitions

对于关键Topic，应检查分区副本是否分散在不同Broker和不同机架上。例如一个3副本Topic，若三个副本全部落在同一机架，则机架级故障会导致数据不可用。验收标准可设为：每个分区的副本集合中，至少覆盖2个不同broker.rack。

同时检查ISR（In-Sync Replicas）状态。若存在大量Isr: 1或持续under-replicated的分区，说明副本同步链路存在问题，需排查网络延迟、磁盘IO或replica.fetch.max.bytes等参数。

三、多数据中心拓扑验证

多数据中心部署通常采用Confluent Replicator或Cluster Linking。验收时要区分“同城双活”“两地三中心”等不同拓扑，确认复制方向、复制Topic命名、以及消费者偏移量是否同步。

以Cluster Linking为例，验收命令包括：

confluent cluster link list --cluster <target-cluster>
confluent cluster link describe <link-name> --cluster <target-cluster>

需要确认link状态为ACTIVE，且source与destination的Topic分区数一致。若使用Replicator，则检查Replicator Connector的tasks.max与replication.factor，并确认目标集群中副本Topic的min.insync.replicas不低于2。

跨中心验收还必须验证故障切换路径。例如主中心Broker全部不可用时，备用中心是否能在可接受时间内接管生产与消费。这需要结合DNS切换、客户端bootstrap.servers配置和acks=all语义综合判断。

四、高可用检查与故障注入

拓扑核对完成后，必须通过故障注入验证高可用。建议按以下顺序执行，每步观察集群恢复时间与数据一致性：

1. 停止一个Controller：KRaft仲裁组应仍能选举Leader，kafka-metadata-quorum describe --status中Leader应切换，且Broker元数据操作不中断。
2. 停止一个Broker：该Broker上的Leader分区应自动转移到其他副本，ISR收缩后恢复。观察UnderReplicatedPartitions指标是否在预期时间内归零。
3. 模拟机架故障：停止同一broker.rack下所有Broker，验证Topic是否仍可读写。若不可读写，说明副本未跨机架分布，需调整replica.assignment。
4. 断开跨中心链路：停止Cluster Link或Replicator，确认源集群生产不受影响，目标集群消费滞后可监控，链路恢复后能自动追平。

故障注入后，应记录恢复时间（RTO）与数据丢失量（RPO）。对于acks=all且min.insync.replicas=2的Topic，单Broker故障不应产生数据丢失。若出现数据丢失，需检查生产者acks配置与ISR收缩策略。

五、验收交付物示例

建议将验收结果整理为可追溯的检查表，以下为字段示例：