你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure 事件中心异地复制

事件中心异地复制功能为命名空间提供元数据(实体、配置和属性)和数据(事件有效负载)的复制,从而实现业务连续性和灾难恢复。

注意

事件中心异地复制功能仅在高级层和专用层上可用。

此功能可确保命名空间的元数据和数据从主要区域持续复制到次要区域。 命名空间可以视为扩展到多个区域,其中一个区域是主要区域,另一个区域是辅助区域。

随时可以将次要区域提升为主要区域。 将次要区域提升为命名空间 FQDN(完全限定的域名),并将上一个主要区域降级到次要区域。

方案

事件中心异地复制可用于多个不同的方案,如下所述。

确保业务连续性和灾难恢复

异地复制可确保命名空间上所有流数据的灾难恢复和业务连续性。 通过跨区域复制数据,组织可以防范数据丢失,并确保其应用程序即使在发生区域性中断时也能保持正常运行。 此功能对于需要高可用性和最短停机时间的任务关键型应用程序至关重要。

全局数据分发

异地复制可用于全局分发数据,使应用程序能够从最近的区域访问数据。 这可降低延迟并提高位于世界不同地区的工作负荷的性能。

数据主权和符合性

在多个国家/地区运营的组织通常需要遵守数据主权法律,这些法律要求将数据存储在特定的地理边界内。 异地复制允许这些组织将数据复制到符合当地法规的区域,确保它们符合法律要求,同时仍维护统一的数据平台。

迁移和升级

异地复制还可用于促进数据迁移、维护和系统升级。 组织可以主动将其命名空间从主要区域迁移到次要区域,以允许主要区域进行任何维护和升级。

基本概念

异地复制功能在主要-次要复制模型中实现元数据和数据复制。 在给定的时间,存在一个主要区域,同时为生产者和使用者提供服务。 次要区域充当热备用区域,这意味着无法与这些次要区域交互。 但是,它们与主要区域在同一配置中运行,允许快速升级,在升级完成后可以单步执行。

地理数据复制功能的一些关键方面包括:

  • 主-辅助复制模型 - 异地复制基于主-辅助复制模型构建,在给定时间,只有一个主命名空间为事件生成者和事件使用者提供服务。
  • 事件中心使用配置的一致性级别,跨次要区域执行元数据、事件数据和使用者偏移量的完全托管字节到字节复制。
  • 单个命名空间主机名 - 成功配置启用了 Geo-Replication 命名空间后,用户可以在其客户端应用程序中使用命名空间主机名。 主机名的行为与配置的主要区域和次要区域无关,并且始终指向主要区域。
  • 当客户发起促销时,主机名指向被选为新主要区域的区域。 旧主要区域成为次要区域。
  • 无法在次要区域上进行读取或写入。
  • 客户管理的从主要区域到次要区域的提升,为解决中断提供完全的所有权和可见性。 有可用的指标,可以帮助从客户端自动完成提升。 次要区域的添加或移除可由客户决定。
  • 复制一致性 - 有两种复制一致性设置,即同步和异步。
国家 图表
故障转移前(辅助升级) 显示区域 A 为主要区域并且 B 为次要区域的示意图。
故障转移后(辅助升级) 显示 B 为现有主要区域并且 A 将成为新的主要区域的示意图。

复制模式

有两种复制一致性配置,即同步和异步。 请务必了解这两种配置之间的差异,因为它们会影响应用程序和数据一致性。

异步复制

使用异步复制,所有请求都在主节点提交,然后向客户端发送确认。 复制到次要区域以异步方式进行。 用户可以配置最大可接受的滞后时间,即主要区域与次要区域进行最新操作时的服务端偏移量。 该服务会持续复制数据和元数据,确保滞后时间尽可能小。 如果活动辅助副本的滞后时间超出用户配置的最大复制滞后时间,则主要副本将开始限制传入请求。

同步复制

使用同步复制,所有请求都会复制到次要区域,次要区域必须先提交并确认操作,然后再在主要区域上提交。 因此,应用程序将以发布、复制、确认和提交的速度进行发布。 此外,这也意味着应用程序与这两个区域的可用性相关。 如果次要区域滞后或不可用,则不会确认和提交消息,并且主要区域会限制传入请求。

复制一致性比较

使用同步复制:

  • 由于分布式提交操作,延迟更长。
  • 可用性与两个区域的可用性相关。 如果一个区域出现故障,则命名空间将不可用。

另一方面,同步复制为数据安全提供了最大保证。 如果你有同步复制,则在提交时,它会提交到为异地复制配置的所有区域中,从而提供最佳的数据保证。

使用异步复制:

  • 延迟受到的影响最小。
  • 次要区域的丢失不会立即影响可用性。 但是,一旦达到配置的最大复制滞后时间,可用性就会受到影响。

因此,它无法像同步复制那样绝对保证所有区域在提交数据之前都有数据,并且可能会发生数据丢失或重复。 但是,由于单个区域滞后或不可用时不再立即受到影响,因此应用程序可用性会提高,并且延迟也会降低。

能力 同步复制 异步复制
延迟 由于分布式提交操作,延迟更长 几乎没有影响
可用性 与次要区域的可用性相关 次要区域的丢失不会立即影响可用性
数据一致性 在确认之前,始终在两个区域中提交数据 在确认之前,仅在主要区域中提交数据
RPO(恢复点目标) RPO 0,提升时无数据丢失 RPO > 0,提升时可能会丢失数据

配置异地复制后,可以更改复制模式。 可以从同步更改为异步,也可以从异步更改为同步。 如果从异步更改为同步,则当滞后时间达到零时,次要区域会配置为同步。 如果你的运行由于任何原因而持续滞后,那么可能需要暂停发布服务器,以便滞后时间达到零,并且你的模式能够切换到同步。 启用同步复制而不是异步复制的原因与数据的重要性、特定的业务需求或合规性原因有关,而不是应用程序的可用性。

注意

如果次要区域滞后或不可用,则应用程序不再能够复制到该区域,并且一旦达到复制滞后时间时就会开始进行限制。 要继续在主要位置中使用命名空间,可以移除受影响的次要区域。 如果未配置更多次要区域,命名空间将继续而不启用 Geo-Replication。 可以随时添加其他次要区域。 无论配置的复制模式如何,顶级实体(事件中心)都会同步复制。

次要区域选择

要启用异地复制功能,需要使用已启用该功能的主要区域和次要区域。 异地复制功能取决于是否能够将已发布的消息从主要区域复制到次要区域。 次要区域位于另一大洲时,这会对从主要区域到次要区域的复制滞后产生重大影响。 如果出于可用性原因使用异地复制,则最好尽可能让次要区域位于同一大洲。 若要更好地了解地理距离导致的延迟,可以从 Azure 网络往返延迟统计信息中了解详细信息。

注意

异地复制要求事件中心的主副本和辅助副本位于同一层。 不能跨层完成配置。

异地复制管理

使用异地复制功能,客户可以配置要将元数据和数据复制到的次要区域。 因此,客户可以执行以下管理任务:

  • 配置异地复制 - 可以在启用了 Geo-Replication 功能的区域中的任何新命名空间或现有命名空间上配置次要区域。
  • 配置复制一致性 - 配置 Geo-Replication 时设置同步和异步复制,但以后也可以切换。
  • 触发升级/故障转移 - 所有升级都是客户发起的。
  • 删除辅助区域 - 如果随时想要删除次要区域,可以删除该区域,之后该区域中的数据将被删除。

触发升级的条件

下面是一些可能会触发辅助数据库升级到主要副本的情况。

  • 区域中断:如果发生影响主要区域的区域中断,则应提升次要区域,以确保业务连续性并最大程度地减少停机时间。

  • 维护活动:在主要区域中的计划内维护活动期间,提升次要区域有助于维护任务关键型应用程序的高可用性。

  • 灾难恢复:如果发生影响主要区域的灾难,提升次要区域可确保数据保持可访问性,应用程序继续正常运行。

  • 性能问题:如果主要区域遇到影响事件中心可用性或可靠性的性能问题,则提升次要区域有助于缓解这些问题。

建议偶尔测试故障转移机制,以确保业务连续性计划有效,并且应用程序可以在需要时无缝切换到次要区域。

监视数据复制

用户可以通过监视应用程序指标日志中的复制滞后指标来监视复制作业的进度。

  • 按照“监视 Azure 事件中心 - Azure 事件中心 | Microsoft Learn”中的说明,在事件中心命名空间中启用应用程序指标日志。

  • 启用应用程序指标日志后,需要先从命名空间生成和使用数据几分钟,然后才能开始查看日志。

  • 若要查看应用程序指标日志,请导航到事件中心页面的“监视”部分,然后选择左侧菜单中的“日志”。 可以使用以下查询查找主命名空间和辅助命名空间之间的复制滞后时间(以秒为单位)。

    AzureDiagnostics
      | where TimeGenerated > ago(1h)
      | where Category == "ApplicationMetricsLogs"
      | where ActivityName_s == "ReplicationLag
    
  • count_d 列指示主要区域和次要区域之间的复制滞后时间(以秒为单位)。

发布数据

发布应用程序可以通过启用了异地复制的命名空间的命名空间主机名将数据发布到异地复制的命名空间。 发布方法与非异地复制情况相同,不需要更改数据平面 SDK 或客户端应用程序。

在以下情况下,事件发布可能不可用:

  • 请求升级次要区域后,现有主要区域将拒绝发布到事件中心的任何新事件。
  • 当主要区域和次要区域之间的复制滞后时间达到最大复制滞后持续时间时,发布服务器入口工作负载可能会受到限制。

发布服务器应用程序无法直接访问次要区域中的任何命名空间。

使用数据

使用应用程序可以通过启用了异地复制功能的命名空间的命名空间主机名来使用数据。 从提升启动到提升完成,不支持使用者操作。

检查点/偏移量管理

使用事件的应用程序可以继续维护偏移管理,就像使用非异地复制命名空间一样。 启用异地复制的命名空间无需特别考虑偏移管理。

警告

如果强制故障转移(即非正常故障转移),某些尚未复制的数据可能会丢失。 这可能会导致该特定数据的偏移量在命名空间的主区域和次要区域中不同,但它仍位于为命名空间配置的最大复制滞后时间的边界内。 在这种情况下,最好从上次提交的偏移量开始使用。 某些数据可能有重复处理,必须在客户端进行处理。

Kafka

偏移量将直接提交到事件中心,并且会跨区域复制偏移量。 因此,使用者可以从主要区域中离开的位置开始使用。

下面是支持的 Apache Kafka 客户端列表 -

客户端名称 版本
Apache Kafka 2.1.0 或更高版本
Librdkafka 和派生库 2.1.0 或更高版本

对于其他库,支持使用以下 API 版本的库 -

API 名称 支持的版本
元数据 API 7 或更高版本
提取 API 9 或更高版本
ListOffset API 4 或更高版本
OffsetFetch API 5 或更高版本
OffsetForLeaderEpoch API 0 或更高版本

事件中心 SDK/AMQP

对于 AMQP,检查点由具有检查点存储(例如 Azure Blob 存储或自定义存储解决方案)的用户管理。 如果存在故障转移,则必须在次要区域中提供检查点存储,以便客户端能够检索检查点数据并避免消息丢失。

最新版本的事件中心 SDK 对检查点表示形式进行了一些更改,以支持故障转移。 我们建议使用 最新版本的 SDK,但以下 SDK 的早期版本也受支持。

语言 包名称
C# Azure.Messaging.EventHubs
C# Microsoft.Azure.EventHubs

警告

作为实现的一部分,在命名空间上启用异地复制时,检查点格式会进行调整。 地理复制完成后,后续的检查点将以新格式写入。 如果在异地复制配对完成后强制将次要区域提升为主区域,但在存储新检查点之前(在强制升级/故障转移的情况下可能会发生这种情况),则发布后升级后发布的新数据可能会丢失。

在这种情况下,最好从上次提交的偏移量开始使用。 某些数据可能有重复处理,必须在客户端进行处理。

还建议升级到 最新版本的 SDK

注意事项

请注意以下与此功能相关的考虑因素:

  • 在提升计划中,还应考虑时间因素。 例如,如果失去连接超过 15 到 20 分钟,你可能会选择开始促销活动。
  • 提升复杂的分布式基础结构应至少演练一次。

定价

定价因所选层而异,但通常有 2 个参数 -

  • 群集或命名空间的计算费用。
  • 主要和次要区域之间复制数据的带宽费用。

注意

请参阅 Azure 事件中心 列出的定价详细信息,以确定费用。 异地复制费用取决于主要区域的位置。

专用集群

在专用事件中心中使用异地复制要求必须在不同区域至少有两个专用群集,这些群集可以用于托管除了正在进行异地复制的命名空间以外的其他命名空间。 这些专用群集根据分配给每个群集的容量单位数单独计费。

启用异地复制后,唯一的额外费用是从主数据库复制到辅助数据库的数据的带宽费用。 此费用取决于主要区域的位置。

高级命名空间

对于高级命名空间,启用异地复制可在次要区域中预配相同数量的处理单元(PU)。 因此,需要支付所使用的 PU 数量 以及在主要区域和次要区域之间传输数据的带宽费用。

例如,如果在预配了 4 PU 的高级命名空间上启用异地复制,则需付费

  • 主要区域中的 4 个 PU,
  • 次要区域中的 4 个 PU,
  • 每GB异地复制数据的费用。

带宽根据主要区域和次要区域之间传输的数据收费。

定价计量

异地复制数据传输带宽费用的定价计量将显示以下详细信息 -

产品名称 计量说明
服务总线 服务总线 - 地理复制区域 1 GB 数据传输 - 地区名称
服务总线 服务总线 - 地理复制区 2 GB 数据传输 - 区域名称
服务总线 服务总线 - 地理复制区域 3 GB 数据传输 - 地区名称

专用终结点

在使用带有私人端点的命名空间中的Geo-Replication时,本节提供了额外的注意事项。 有关将专用终结点与事件中心配合使用的一般信息,请参阅 将 Azure 事件中心与 Azure 专用链接集成

为使用专用终结点的事件中心命名空间实现 Geo-Replication 时,请务必为主要区域和次要区域创建专用终结点。 应针对托管应用程序的主实例和辅助实例的虚拟网络配置这些终结点。 例如,如果有两个虚拟网络(VNET-1 和 VNET-2),则需要在事件中心命名空间上分别使用 VNET-1 和 VNET-2 中的子网创建两个专用终结点。 此外,应使用 跨区域对等互连设置 VNET,以便客户端可以与任一专用终结点通信。 最后,需要以某种方式管理 DNS ,以便所有客户端获取 DNS 信息,该信息应将命名空间终结点(namespacename.servicebus.windows.net)指向当前主要区域中专用终结点的 IP 地址。

重要说明

升级事件中心的次要区域时,还需要更新 DNS 条目以指向相应的终结点。

截图显示两个 VNET,各自拥有专用终结点和 VM,并连接到一个本地实例和一个 Event Hubs 命名空间。

此方法的优点是,故障转移可以在应用程序层或事件中心命名空间上独立发生:

  • 仅应用程序故障转移:在此场景中,应用程序从 VNET-1 切换到 VNET-2。 由于在 VNET-1 和 VNET-2 上都配置了针对主命名空间和次命名空间的专用终结点,应用程序能够继续无缝运行。
  • 事件中心仅限命名空间的故障转移:同样,如果故障转移仅在事件中心命名空间级别发生,则应用程序仍可正常运行,因为两个虚拟网络上都配置了专用终结点。

通过遵循这些准则,可以使用专用终结点确保事件中心命名空间的强健且可靠的故障转移机制。

若要了解如何使用异地复制功能,请参阅使用异地复制