单数据中心跨安全区部署Kafka：Stretch Cluster是否为唯一方案？

Stretch Cluster不是实现跨安全区Topic访问的唯一方案，你调研的两种思路都是可行的方向，具体差异和适用场景如下：

方案一：共用ZooKeeper的Stretch Cluster #

• 核心逻辑：将Kafka集群节点跨两个安全区部署（比如Broker-1在安全区1，其他Broker分布在安全区2），同时共用一套跨区部署的ZooKeeper集群来管理元数据。
• 优势：
  • 属于单一逻辑集群，Topic的分区、副本统一调度，跨安全区访问Topic无需额外同步工具，架构极简。
  • 客户端（生产者/消费者）无需适配多集群，配置和使用成本低。
• 潜在问题：
  • 安全区之间的网络延迟会直接拉低集群性能，比如副本同步、元数据读写的响应速度都会受影响。
  • 必须打通两个安全区之间Broker与ZooKeeper、跨区Broker的通信链路，可能与安全区的隔离政策冲突。

方案二：独立Kafka集群+专属ZooKeeper #

• 核心逻辑：两个安全区各自部署独立的Kafka集群和专属ZooKeeper，通过Kafka官方的MirrorMaker 2.0工具实现Topic数据的跨区复制。
• 优势：
  • 两个集群物理隔离，安全区之间仅需开放同步工具的通信端口，安全边界清晰，更符合安全区的合规要求。
  • 集群各自独立运维，单个集群的故障不会传导到另一个集群，可用性风险更可控。
• 注意事项：
  • 需要额外部署和维护MirrorMaker 2.0组件，增加了架构复杂度和运维工作量。
  • 数据同步存在固有延迟，无法做到实时一致，需结合业务对数据时效性的要求评估可行性。

内容的提问来源于stack exchange，提问作者Aali