关于kafka:跨数据中心下的-Kafka-高可用架构分析

导语

本文介绍了 Kafka 跨数据中心的两种部署形式，简要剖析两种形式下的不同架构以及优缺点，对这些架构可能碰到的问题也提供了一些解决思路；同时也阐明了 Kafka 跨数据中心部署的社区解决方案和商业化解决方案。

背景

Kafka 作为世界上最风行的消息中间件之一，个别是客户数据链路中的外围组件，高可用性是客户很关注的因素。近期在对接云上客户时发现，客户对 Kafka 的高可用也有需要，行业架构师也想理解 Kafka 高可用的计划细节；有些客户须要云上 Kafka 的高可用能力；有些客户须要 IDC 中的 Kafka 与云上 Kafka 建设高可用架构; 有些客户须要与其余友商云进行跨云高可用。单集群的高可用探讨得比拟多，但跨数据中心的形式比拟多，绝对简单。本文心愿借由对 Kafka 跨数据中心高可用架构的剖析，为以上场景的解决方案提供一些思路。

相干术语

• RTO(Recovery Time Objective)：即数据恢复工夫指标。指如果产生故障，产生故障转移时业务零碎所能容忍的最长进行服务工夫。如果须要 RTO 越低，就越要防止手工操作，只有自动化故障转移能力实现比拟低的 RTO。
• RPO(Recovery Point Objective)：即数据恢复点指标。指如果产生故障，故障转移须要从数据历史记录中的哪个点复原。换句话说，有多少数据会在故障期间失落。
• 劫难复原(Disaster Recovery): 涵盖所有容许应用程序从劫难中复原的体系结构、实现、工具、策略和过程的总称，在本文档的上下文中，是指整个区域故障。
• 高可用性(High Availability): 一个高度可用的零碎即便在呈现故障的状况下也能够间断运行。在多区域架构的上下文中，高可用性应用程序即便在整个区域故障期间也能够运行。HA 应用程序具备劫难复原策略。

产生故障的场景

在以后基础设施丰盛的时代，咱们很容易认为不须要思考故障场景。然而现实情况是，不论是在虚拟化或容器化架构下，还是在提供成熟服务的云厂商上，只管概率各不相同，但都有可能产生部分和系统故障。架构师须要思考特定类型故障的可能性以及对其整体零碎可用性的影响。

上面列出一些典型的故障场景

这篇文章重点围绕故障场景 2、3、4 阐明 Kafka 中有哪些计划来应答这几类故障场景。第 1 种单节点故障，Kafka 集群高可用能够应答；第 5、6 种故障能够思考将数据存储到第三方零碎，如果在云上能够转储到 COS。

Kafka 体系架构简介

以下是 Kafka 的软件架构，整个 Kafka 体系结构由 Producer、Consumer、Broker、ZooKeeper 组成。Broker 又由 Topic、分区、正本组成。

具体能够参考 Kafka 官网文档，Kafka introduce。

单套 Kafka 集群是通过正本复制来保障集群的高可用，但在理论生产状况下，单数据中心单集群不肯定能满足生产上须要的高可用需要，也难以应答简单的业务场景。咱们上面来看看跨数据中心下几种常见的利用场景。

跨数据中心的利用场景

• 跨地区复制
  有时候，一家公司可能会在不同的天文区域、城市或大洲有多个数据中心。每个数据中心都有本人的 Kafka 集群。有些应用程序只须要与本地的 Kafka 集群通信，有些应用程序则须要拜访多个数据中心的数据（否则就没有必要跨数据中心的复制计划了）。有很多状况须要跨数据中心拜访数据，例如，依据供需状况批改商品价格就是一个典型的利用场景。该公司在每个城市都有一个数据中心，用于收集每个城市的供需信息，而后依据整体的供需状况调整商品价格。这些信息会被镜像到核心集群，而后业务分析员会基于核心集群中的数据生成整个公司的收益报告。
• 灾备
  Kafka 集群可能因为某些起因不可用，为了实现冗余，须要有另外一个与第一个集群完全相同的集群。如果有第一个集群不可用的状况产生，能够将应用程序从新定向到第二个集群。
• 集群的物理隔离
  有些客户须要将生产环境数据镜像到测试环境，进行验证。
• 云迁徙和混合云部署
  在云计算风行的明天，局部公司会将业务同时部署在本地 IDC 和云端。本地 IDC 和每个云服务区域可能都会有 Kafka 集群，应用程序会在这些 Kafka 集群之间传输数据。例如，云端部署了一个利用，它须要拜访 IDC 里的数据，IDC 里的应用程序负责更新这个数据，并保留在本地的数据库中。能够捕捉这些数据变更，而后保留在 IDC 的 Kafka 集群中，而后再镜像到云端的 Kafka 集群中，让云端的应用程序能够拜访这些数据。这样既有助于管制跨数据中心的流量老本，也有助于进步流量的监管合规性和安全性。
• 法律和法规要求
  越来越多的国家和地区对数据安全都很器重，都有出台相应的信息爱护法律法规。如果有数据波及到跨境被拜访，能够利用 kafka 的镜像能力，在传输到境外之前，进行数据脱敏、传输加密等一系列的解决。
  为了合乎不同国家的法律和监管要求，一家公司在不同国家的经营也可能须要不同的配置和策略。例如，一些数据可能须要被保留在具备严格访问控制的独立集群中，一些数据则能够被复制到具备宽松拜访权限的其余集群。为了满足不同区域对数据保留期限的合规性要求，保留在不同区域集群中的数据能够应用不同的配置。

跨数据中心 Kafka 的部署状态

一般来说，Kafka 跨数据中心部署大体分两种状态：Stretched Cluster 和 Connected Cluster。

Stretched Cluster

延展集群，它实质上是单个集群，是应用 Kafka 内置的复制机制来放弃 broker 正本的同步。通过配置 min.insync.replicas 和 acks=all，能够确保每次写入音讯时都能够收到至多来自两个数据中心的确认。

Connected Cluster

连贯集群，个别通过异步复制实现多地区复制，并且应用内部工具将数据从一个（或多个）集群复制到另一个集群。该工具中会有 Kafka 消费者从源集群生产数据，而后利用 Kafka 生产者将数据生产到目标集群。但 Confluent 提供了一种不应用内部工具实现此性能的连贯集群，在上面介绍商业化计划的时候再具体阐明。

上面是这两种部署状态的比照

基于这两种部署状态，跨数据中心会有如下几种部署架构。

跨数据中心 Kafka 的部署架构

延展集群 2AZ

Kafka 的 Broker 跨两个数据中心组成集群，Zookeeper 是 Hierarchical Quorum 模式。数据中心的 Kafka 集群间接连贯本地的 Zookeeper 组。延展集群 2AZ 部署架构如下：

如果 DC1 不可用，客户端在另外一个数据中心也失去了分区 Leader。要么局部生产，要么进行生产，这取决于复制因子的配置。

如果某个数据中心产生故障，能够通过如下形式进行切换。

① DC1 产生故障

②不能抉择 Leader 分区

③从配置文件中移除不可用的 ZK 和 Group

④在 DC2 中抉择新的 Leader 分区

⑤将 min.insync.replica 从 3 批改为 2

⑥生产者能够发送音讯给新的 Leader 分区

能够看到延展集群 2AZ 的架构并非规范的高可用解决方案。如果呈现某个数据中心不可用，须要手动调整配置文件，手动从新拉起 ZK 集群。所以整个过程 RTO 和 RPO 都是大于 0。现有的解决方案中，Confluent 提供的 Linker 产品更实用 2AZ 高可用的场景，在上面的商业化解决方案中再具体介绍。

延展集群 2.5AZ

延展集群 2.5AZ 的架构蕴含两个齐全运行的可用区，和一个运行单个延展集群的轻可用区(0.5)。Zookeeper 须要跨 3 个数据中心部署，每个数据中心一个 ZK 节点。如果某个数据中心不可用，故障切换的 RTO 和 RPO 都是 0。在 2.5AZ 的部署架构下，如果正本数设为 3，并且 Acks=all，min.insync.replicas=2，那么 3 正本的散布为 2 +1。此时如果 2 正本所在的数据中心不可用，因最小 ISR 设为了 2，所以集群的写入将不可用，但生产不受影响。

延展集群 2.5AZ 的部署架构如下：

延展集群 3AZ

该架构跨 3 个数据中心部署一个集群，RTO 和 RPO 在一个数据中心故障时为 0。这种模式是所有模式中最简略、最强壮的。这种模式在公共云中十分常见（应用多个可用区）。也不会有 2.5AZ 起码 ISR 不够用的危险。延展集群 3AZ 的部署架构如下：

通过配置 min.insync.replicas 和 Acks=all，能够确保每次写入音讯时都能够收到至多来自两个数据中心的确认。从 Kafka 2.4.0 开始，消费者能够基于机架信息从最近的正本获取数据。从本地数据中心的 Follow 正本读取数据能够进步吞吐量、升高提早和老本，因为跨数据中心的流量缩小了。

连贯集群 - 灾备架构

Parimay 集群 (主) 将数据镜像到备用集群集群 (被动) 应用 MM2。当主用站点故障时，您须要挪动生产者和消费者应用程序到备用站点。RTO 取决于备用站点的升温水平向上当波及到 RPO 时，可能会产生数据失落因为 MM2 异步复制数据主用站点到备用站点。
 

这种架构益处是比拟好实现，只须要装置第二个集群，而后应用镜像工具将第一个集群的数据齐全镜像到第二个集群中。但这个架构最大的问题在于节约一个集群，并且 Kafka 的故障转移很难齐全做到既不丢数据，也无反复数据。咱们只能尽量减少这些问题的产生，然而无奈完全避免。

Kafka 的已知的镜像计划都是异步的，所以灾备集群无奈及时获取主集群的次要数据。咱们须要监控同步提早，来确认灾备集群落后主集群多少，并确保不要落后太多。如果有故障转移打算，能够先进行主集群，等镜像过程将残余数据同步结束，而后再切换到灾备集群，这样能够防止数据失落。如果产生了非打算内的故障转移，切换到灾备集群可能会失落一部分音讯。

另外，以后社区镜像计划还不反对 EOS(Exactly-once Semantics)，如果主集群有事务音讯，同步到灾备集群，有些音讯可能会失落。切换到灾备集群，还有个比拟大的挑战是消费者位点的同步。MM1 并不能承诺消费者位点可能同步，所以晚期版本（2.4 版本以前）的 Kafka 灾备切换，生产位点要么从起始地位开始读取数据，要么从开端开始读取数据。从起始地位读取会带来大量的反复数据；从开端开始读取数据，可能抛弃局部数据。一般来说，从开端读取数据更为常见。从 Kafka0.10 之后，Kafka 每条音讯都蕴含了一个工夫戳，所以也能够依据工夫点来调整生产位移点。追随 Kafka2.4 一起推出的 MirrorMaker2（以下简称 MM2）是下一代的多集群镜像解决方案，修复了 MirrorMaker1 的局限性。

连贯集群 - 双活架构

当有两个或者多个数据中心须要共享局部或全副数据，并且每个数据中心都能够生产或者生产数据，能够应用双活架构，如下图所示：

每个数据中心运行独自的 Kafka 集群，每个集群都是另外一个集群的正本。当一个数据中心产生故障，应用程序将故障转移到另外一个数据中心。

双活架构可能遇到的一些问题。

• 数据镜像提早问题。如果用户向一个数据中心生产数据，从另外一个数据中心生产数据，生产的数据可能还没有镜像到另外一个数据中心。
• 多数据中心反复生产问题。要小心防止同一条音讯被镜像到两个或多个数据中心，被生产屡次。须要依据理论状况抉择适合的办法，比方给每条音讯设置一个 ID，通过音讯 ID 来检测是否被反复生产过。或者依据音讯上带的工夫戳，生产前查看该工夫戳是否被生产过。
• 配置和治理的复杂性。须要在两个或多个数据中心之间配置和治理多个 kafka 集群，如果配置不当或者治理不当，可能会导致数据同步失败或者数据失落。同时也须要有欠缺的监控零碎来观测镜像的状况，如镜像提早，镜像速率等。
• 音讯循环镜像。须要防止音讯在两个或多个数据中心来回镜像。能够通过在不同的数据中心设置独自的 Topic，并确保不要从不同的数据中心镜像同名的 Topic。如 MirrorMaker2 就是通过在指标集群的 Topic 上中带 Kafka 实例 ID 来防止循环镜像。或者通过音讯 Head 中蕴含数据中心信息，从而防止循环镜像。

跨数据中心 Kafka 解决方案

社区解决方案

社区计划中的延展集群利用 Kafka 本身的同步机制达到高可用的成果，并不需要借助于内部工具。针对连贯集群，社区解决方案次要是借助于 Kafka 自带的 MirrorMaker 工具。晚期的 MirrorMaker1(以下简称 MM1)存在一些问题。

比方：

• 指标集群的 Topic 应用默认配置创立，但通常须要手动分区。
• ACL 和 Topic 配置的变更不会主动同步
• 音讯会被 DefaultPartitioner 打散到不同分区，即对一个 Topic，指标集群的 Partition 与源集群的 Partition 不统一。所以也没方法保障程序音讯。
• 不保障 Exactly-Once 语义，可能呈现反复数据的状况
• MM1 反对的数据备份模式较简略，比方无奈反对 Active/Active 模式
• Rebalance 可能会导致镜像提早
• 不反对生产 Offset 同步

因为存在这些问题，MM1 很难在生产环境中应用。所以在 Kafka2.4 版本中，推出了一个新的 MirrorMaker2（以下简称 MM2），MM2 基于 kafka connect 框架，解决了下面大部分的问题。

下图是 MM2 在主备架构中的利用。

能够在 MirrorMaker2 下配置简单的拓扑来反对更为宽泛的的场景。比方有 Kafka 集群 A、B、C。双活高可用可配置：A→B，B→A。灾备集群可配置：A→B。聚合：A→C，B→C。扇出可配置：C→A，C→B。链式复制可配置：A→B，B→C。

为防止增加新的 Topic 或分区产生再平衡而导致提早激增，在调配分区时，MirrorMaker2 并没有应用 Kafka 的消费群组治理协定。源集群的每个分区的音讯都能够镜像到指标集群的雷同分区。如果源 Topic 增加了分区，那么指标 Topic 也会主动创立对应的分区。除了能够复制元数据、音讯数据，MM2 还反对消费者偏移量、Topic 配置和 ACL。

MM2 的具体配置也能够参考：https://kafka.apache.org/documentation/#georeplication-mirror…，文档外面蕴含 MM2 相干的 KIP-382，有趣味能够理解下。

开源 & 商业化计划

uber 的 uReplicator

uReplicator 是 UBber 开源的 Kafka 集群复制开源我的项目，基于 MirrorMaker1 的改进版，应用 Apache Helix 作为核心控制器，用于治理 Topic 列表和调配给每个 uReplicator 实例的分区。管理员能够通过 REST API 增加新的 Topic，uReplicator 负责将分区调配给不同的消费者。uReplicator 引入 Helix，取代了 High-Level Consumer 外面的 Consumer Group Coordinator 角色，消费者的分区由 Helix 控制器负责调配，不须要在消费者之间进行协调，防止了再平衡。

uReplicator 借助于 Helix 解决了 MM1 的一些痛点问题，然而也带来了额定的复杂性。MM2 解决了 MM1 的伸缩性和容错性问题，并且不须要依赖内部组件。想对 uReplicator 有更多理解，能够参考官网博客：uReplicator: Uber Engineering’s Robust Apache Kafka Replicator。

Confluent 的 Replicator

Confluent Replicator 容许您轻松牢靠地将主题从一个 Kafka 集群复制到另一个集群。除了复制音讯外，Replicator 还会依据须要创立主题，保留源集群中的主题配置。这包含保留分区数、复制因子以及为单个主题指定的任何配置笼罩。和 MirrorMaker 相似，Confluent Replicator 也依赖于 Connect 框架，并能够在 Connect 集群中运行。

Confluent Replicator 反对各种拓扑的数据复制以及消费者偏移量和 Topic 配置信息的迁徙，但与 MirrorMaker2 不同，Confluent Replicator 不反对 ACL 迁徙；并且 Replicator 不应用近程 Topic 防止循环复制，而是应用起源头来防止循环复制。同时 Replicator 提供一系列指标，比方复制提早，还能够通过 REST API 或者控制台 UI 来监控这些指标。

Confluent 的 Cluster Linker

Confluent 的 Cluster Linker 能够使可能间接将集群和镜像 Topic 从一个集群连贯到另一个集群。Cluster Linker 使构建多数据中心、多区域和混合云部署变得更为容易。它是平安的，高性能的，容忍网络提早，并内置于 Confluent 服务器和 Confluent 云。通过 Cluster Linker，能够实现多区域高可用性，同时能够反对劫难复原、全局复制、数据共享以及集群迁徙等需要。

与 Replicator 和 MirrorMaker 2 不同，集群链接不须要运行 Connector 来将音讯从一个集群挪动到另一个集群，并且它创立具备全局统一偏移量的雷同的“镜像主题”。源主题上的音讯准确地镜像到指标集群上，在雷同的分区和偏移量上。镜像主题中不会呈现与源主题所蕴含内容相干的重复记录。

Cluster Linker 将 Topic 正本复制协定用在了集群复制上，能够跨集群进行带生产 Offset 迁徙的数据复制，不须要进行 Offset 转换。Topic 配置信息、分区、消费者 Offset 和 ACL 都能够在两个集群间接同步，以便在产生劫难时实现低 RTO 的故障转移。指标集群上镜像 Topic 的 Leader 分区从对应的源 Leader 那里获取分区数据，指标集群上镜像 Topic 的 Follower 应用 Kafka 规范的 Replication 机制从本地 Leader 那里复制数据。指标集群的镜像 Topic 会被定义成只读，避免本地生产者将数据生产到这些主题。

Cluster Linker 比 MM2 或 Replicator 劣势的中央在于，不须要保护一个 Connector 集群，并且比内部工具更高效，防止了 Connector 集群镜像数据时须要解压缩和再压缩，同时 Cluster Linker 可用于网络不牢靠且高提早的数据中心，它只在数据中心之间复制一次数据，缩小了跨数据中心的流量。但 Cluster Linker 没有相似 MM2 的镜像配置选项，短少镜像配置的灵活性。同时，如果产生了故障转移，须要重启客户端，将网络连接到指标集群上。Cluster Linker 个别实用于迁徙集群和须要共享主题的场景。

Confluent 的 Multi-Region Cluster

Confluent 的 Multi-Region Cluster（以下简称 MRC）实用于提早在 50ms 以内的数据中心，它同步组合了同步复制和异步复制，以此来升高对生产者性能的影响，并能提供给更高的网络容错性。

Confluent Server 通常跨可用性区域或左近的数据中心运行。如果跨可用性区域或左近数据中心的代理之间的计算机网络在可靠性、提早、带宽或老本方面不同，这可能会导致更高的提早、更低的吞吐量以及生产和应用音讯的成本增加。

为了缓解这种状况，Confluent Server 增加两个加强的能力：

• Follower-Fetching：Kafka 容许客户端从 Follower 正本读取数据，客户端能够依据机架 ID 从最近的 Broker 获取数据，从而缩小了跨数据中心的流量。
• Observers：社区 Kafka 有两种类型的正本，Leader 和 Follower。Multi-Region Cluster 引入了第三种类型的正本，观察者。默认状况下，观察者不会退出同步正本 (ISR)，但会像 Follower 一样致力跟上 Leader 的步调。通过 Follower 获取，客户也能够从 Observer 那里生产。通过不退出 ISR，Observer 使操作员可能异步复制数据。在 Confluent Server 中，主题分区的高水位线不会减少，直到 ISR 的所有成员都确认他们曾经复制了一条音讯。应用的客户端 acks=all 可能会遇到吞吐量问题，尤其是在波及跨数据中心的高提早、低带宽网络时。应用 Observer，能够定义在一个区域内同步复制数据但在区域之间异步复制数据的 Topic。默认状况下，这些 Observer 不退出 ISR，因而它们不会影响排除音讯的吞吐量和提早，因为主题分区 Leader 在向生产者确认申请之前不须要期待它们被复制到 Observer。
  Confluent Server 反对主动观察者晋升(Automatic Observer Promotion)，能够主动将 Observer 晋升到同步正本列表 (ISR) 中。这在某些降级状况下可能是很有用的。例如，如果分区的 ISR 数量小于 min.insync.replicas 的值，那么该分区通常会不可用。通过主动观察者晋升，一个或多个 Observer 能够取代 ISR 中的 Follower，放弃分区在线，直到不可用的 Follower 复原。一旦 Follower 被复原（他们被赶上并重新加入 ISR），观察者就会主动从 ISR 中降级。

总结

本文介绍了 Kafka 跨数据中心的两种部署形式，简要剖析了两种形式下的不同架构以及优缺点，对这些架构可能碰到的问题也提供了一些解决思路；同时也阐明了 Kafka 跨数据中心部署的社区解决方案和商业化解决方案。

随着数据中心故障的不可避免，作为外围数据链路中的 Kafka 的高可用也失去更多的器重。Kafka 跨数据中心部署形式中，Stretched Cluster 采纳同步的形式复制数据，RTO&RPO 是 0；Connected Cluster 采纳异步的形式复制数据，RTO&RPO 个别大于 0。如果自建 Connected Cluster，那么须要做好故障切换的演练。大家能够依据理论场景需要来抉择相应的部署架构，一种场景并不见得只有一种解决方案架构能满足。或者为了省心，能够在腾讯云上间接抉择 Ckafka。

腾讯云 CKafka 在私有云上也提供跨可用区集群的产品化能力，反对 Streched Cluster 2.5AZ 和 Streched Cluster3AZ 两种部署架构；也反对 Connected Cluster，反对多个集群间接相互复制，反对多种复制拓扑。曾经有泛滥的大客户在云上抉择了 Ckafka。

因篇幅无限，本文在局部计划细节上并未深刻开展，欢送随时分割交换。

参考资料

https://docs.confluent.io/platform/current/multi-dc-deploymen…

https://www.confluent.io/blog/multi-geo-replication-in-apache…

https://kafka.apache.org/documentation/

https://www.confluent.io/resources/kafka-the-definitive-guide…

https://cloud.tencent.com/document/product/597/52786