服务总线异地复制功能是使 Azure 服务总线应用程序免受服务中断和灾难影响的选项之一，可复制元数据（实体、配置、属性）和数据（消息数据和消息属性/状态更改）。 可以在新的命名空间和现有命名空间上启用 Geo-Replication。
Geo-Replication 功能持续将命名空间的元数据和数据从主要区域复制到一个或多个次要区域。 它进行复制：
- 队列、主题、订阅和筛选器。
- 驻留在实体中的数据。
- 针对命名空间中的消息执行的所有状态更改和属性更改。
- 命名空间配置。
此功能允许你随时将任何次要区域提升为主要区域。 提升次要区域会将命名空间重新指向所选次要区域，并在主要区域和次要区域之间切换角色。
注释
- 此功能适用于Azure 服务总线的高级层。
- 目前仅支持单个次要区域。
Important
- 不能将此功能与 Azure 服务总线 Geo-Disaster 恢复功能结合使用。
- 以下功能目前尚不可用。 产品团队不断致力于引入更多功能，并将更新此列表并显示最新状态。
- 进行故障转移时，已启用空闲时自动删除的实体的计时器会被重置，并重新开始计时。
- 在使用异地复制的命名空间上启用事件网格集成时，请注意以下事项：
与地质灾害恢复的比较
Azure 服务总线提供两项地理复原功能：Geo-Replication 和地理灾难恢复。 主要区别在于，Geo-Replication 复制元数据和数据（消息、消息状态、属性更改），而 Geo-Disaster 恢复仅复制元数据。 对于大多数灾难恢复方案，建议选择 Geo-Replication。 有关详细比较，请参阅 Azure 服务总线的可靠性 - 对区域范围的故障的复原能力。
方案
可以使用 Geo-Replication 功能来实现不同的方案，如本文所述。 有关何时触发晋升的指导，请参阅 推荐的方案来触发晋升。
灾难恢复
主要区域和次要区域持续同步数据和元数据。 如果主要区域遇到服务降级的情况，则可以将次要区域提升为主要区域。 此升级使工作负荷在新升级的区域保持运行，而不会中断。 由于你的工作负载中的 服务总线 或其他服务出现性能下降，因此可能有必要进行此类升配，尤其是在你打算让各个组件一起运行时。 根据严重性和受影响的服务，可以计划或强制升级。 如果是计划提升，该过程会先复制传输中的消息，然后再完成提升。 强制升级会立即执行该升级操作。
区域迁移
可能需要迁移服务总线工作负荷，以在不同的区域中运行。 例如，当 Azure 添加的新区域在地理位置上离你的位置、用户或其他服务更近时。 或者，当运行大部分工作负载的区域发生转移时，可能需要进行迁移。 在这些情况下，异地复制功能也是一个很好的解决方案。 在这种情况下，请在现有命名空间上设置 Geo-Replication，并将所需的新区域设置为次要区域，并等待同步完成。 同步完成后，你会启动计划内提升操作，从而复制任何在途消息。 升级完成后，可以选择删除旧区域（现在是次要区域），并继续在所需区域中运行工作负荷。
计划内维护
在主要区域中的计划内维护活动期间，可以提升次要区域，以维护任务关键型应用程序的高可用性。 此方法允许你执行维护，而不会影响工作负荷。
基本概念
异地复制功能在主要-次要复制模型中实现元数据和数据复制。 在给定时间，有一个主要区域同时为生产者和消费者提供服务。 次要区域可以是以下两种状态之一：
- 活动辅助区域：属于复制配置的一部分的辅助区域，且当前正向该区域进行复制。 活动次级节点是同步复制中的仲裁成员。 有关详细信息，请参阅 “管理”中的“就绪”状态。
- 空闲辅助区域：正在设置或提升后正在重新同步的辅助区域。 空闲次要副本不是仲裁的一部分，也不会影响同步模式下的确认。 有关详细信息，请参阅 管理中的 InBuild 状态。
次要区域充当热备用区域，这意味着无法与这些次要区域交互。 但是，它们与主要区域在同一配置中运行，这允许快速升级。 提升完成后，您的工作负载可以立即继续运行。
Geo-Replication 功能的一些关键方面包括：
- 服务总线服务跨区域执行元数据、消息数据以及消息状态和属性更改的完全托管复制，并遵守在命名空间配置的复制一致性。
- 单一命名空间主机名。 成功配置启用了 Geo-Replication 命名空间后，请在客户端应用程序中使用命名空间主机名。 主机名的行为与配置的主要区域和次要区域无关，并且始终指向主要区域。
- 启动升级时，主机名将指向所选区域作为新的主要区域。 旧主要区域成为次要区域。
- 无法在次要区域读取或写入。
- 使用异地复制不需要对数据平面 SDK 或客户端应用程序进行更改。
- 同步和异步复制模式，有关进一步说明，请参阅此处。
- 客户管理的从主要区域到次要区域的提升，为解决中断提供完全的所有权和可见性。 可提供复制延迟指标，您可以使用这些指标来监控复制状态并自动提升。
- 可以添加或删除次要区域。
- 当复制延迟达到配置的最大值时，发布者请求会受到限制。
复制模式
有两种复制模式：同步和异步。 了解这两种模式之间的差异非常重要。
异步复制
使用异步复制时，主服务器会提交所有请求，然后将确认发送到客户端。 复制到次要区域以异步方式进行。 可以配置可接受的最长延迟时间。 滞后时间是主要区域和次要区域上最新操作之间的服务端偏移量。 该服务会持续复制数据和元数据，确保滞后时间尽可能小。 如果活动辅助副本的滞后时间超出用户配置的最大复制滞后时间，则主要副本将开始限制传入请求。
同步复制
使用同步复制时，系统会在向客户端发送确认之前将所有请求提交到主位置和辅助位置。 因此，您的应用程序将以能够向所有区域提交数据的速度进行发布。 此过程还意味着应用程序依赖于这两个区域的可用性。 如果次要区域滞后或不可用，则主要区域不会确认或提交消息并限制传入请求。
复制模式比较
使用同步复制：
- 由于分布式提交操作，延迟时间更长。
- 可用性取决于两个区域的可用性。
另一方面，同步复制为数据安全提供了最大保证。 如果使用同步复制，提交操作将在您为地理复制配置的所有区域中提交，从而提供数据的最佳保证。
使用异步复制：
- 延迟影响最小。
- 次要区域的丢失不会立即影响可用性。 但是，一旦达到配置的最大复制滞后时间，可用性就会受到影响。
因此，它不像同步复制那样，能够绝对保证在提交之前所有区域都已收到数据；使用强制提升时，则可能发生数据丢失或重复。 但是，由于单个区域滞后或不可用时不再立即受到影响，因此应用程序可用性会提高，并且延迟也会降低。
| 能力 | 同步复制 | 异步复制 |
|---|---|---|
| 延迟 | 由于分布式提交操作，时间更长 | 几乎没有影响 |
| Availability | 取决于次要区域的可用性 | 次要区域的丢失不会立即影响可用性 |
| 数据一致性 | 在确认之前，始终在两个区域中提交数据 | 在确认之前，仅在主要区域中提交数据 |
| RPO（恢复点目标） | RPO 0，提升时无数据丢失 | 配置的延迟时间内的 RPO，在强制提升过程中可能会丢失数据。 |
配置异地复制后，可以更改复制模式。 你可以从同步切换到异步，也可以从异步切换到同步。 在延迟达到零后，如果从异步切换到同步，则次要节点将被配置为同步。 如果由于某种原因导致持续延迟，您可能需要暂停发布进程，以便滞后时间归零后，模式才可以切换到同步。 启用同步复制而不是异步复制的原因与数据、特定业务需求或合规性原因的重要性有关，而不是应用程序的可用性。
注释
如果辅助区域滞后或不可用，应用程序将无法再复制到该区域，并在达到复制滞后的阈值时开始限速。 若要继续使用主要位置中的命名空间，请删除受影响的次要区域。 如果删除所有次要区域，命名空间将会继续运行，但不启用 Geo-Replication。 可以随时添加其他次要区域。 无论配置的复制模式如何，顶级实体（即队列和主题）都会同步复制。 但是，主题订阅遵循所选复制模式。 因此，在决定适当的复制模式时，必须考虑到它们。
次要区域选择
Geo-Replication 功能取决于将已发布的消息从主要区域复制到次要区域。 如果次要区域位于另一大洲，则此选项会影响从主要区域到次要区域的复制滞后时间。 如果使用异地复制（Geo-Replication）来保证可用性，请尽可能选择至少位于同一大洲的辅助区域。 有关地理距离导致的延迟的详细信息，请参阅Azure网络往返延迟统计信息。
地理复制管理
使用 Geo-Replication 功能可以配置次要区域以复制元数据和数据。 可以执行以下管理任务：
- 配置异地复制。 可以通过启用 Geo-Replication 功能，在区域中的任何新命名空间或现有命名空间上配置次要区域。
- 配置复制一致性。 配置异地复制时设置同步复制和异步复制。 还可以稍后切换此设置。
- 触发促销活动。 所有促销都是客户发起的。
- 删除辅助副本。 可以删除次要区域。 删除次要区域中的数据。
Setup
使用 Azure 门户
以下部分概述了如何通过 Azure 门户在新命名空间上设置 Geo-Replication 功能。
- 创建新的高级层级命名空间。
- 选中“异地复制”部分下的“启用异地复制”复选框。
- 选择 “添加次要区域”，然后选择一个区域。
- 选中 “同步复制 ”复选框，或指定 异步复制 - 最大复制滞后 时间值（以分钟为单位）。
使用模板
若要创建启用了异地复制功能的命名空间，请添加 geoDataReplication 属性部分。
@description('Name of the Service Bus namespace')
param serviceBusName string
@description('Primary location for the namespace')
param primaryLocation string
@description('Secondary location for geo-replication')
param secondaryLocation string
@description('Maximum replication lag in seconds for async replication')
param maxReplicationLagInSeconds int
resource serviceBusNamespace 'Microsoft.ServiceBus/namespaces@2025-05-01-preview' = {
name: serviceBusName
location: primaryLocation
sku: {
name: 'Premium'
tier: 'Premium'
capacity: 1
}
properties: {
geoDataReplication: {
maxReplicationLagDurationInSeconds: maxReplicationLagInSeconds
locations: [
{
locationName: primaryLocation
roleType: 'Primary'
}
{
locationName: secondaryLocation
roleType: 'Secondary'
}
]
}
}
}
Management
创建启用了 Geo-Replication 功能的命名空间后，可以从 “异地复制 ”边栏选项卡管理该功能。
次要区域可以处于以下状态之一：
| State | 说明 |
|---|---|
| InBuild | 正在设置次要区域并正在进行初始同步，或者区域会在强制升级后重新同步。 处于 InBuild 状态的次要区域不属于仲裁范围。 |
| Ready | 次要区域是复制配置的一部分，并且正在被主动复制到。 |
| 正在删除 | 正在从复制配置中删除次要区域。 |
切换复制模式
若要在复制模式之间切换或更新最大复制滞后时间，请选择 复制一致性下的链接。 选中复选框可启用或禁用同步复制，或更新文本框中的值以更改异步最大复制延迟。
删除次要区域
若要删除次要区域，请选择“ 删除”，然后按照弹出边栏选项卡中的说明进行操作。 删除正在进行时，区域会显示 “删除 ”状态。
促销流程
客户手动触发促销活动（要么通过某个命令显式触发，要么通过由客户端控制并触发该命令的业务逻辑来触发）。 Azure永远不会触发促销。 此方法为客户提供对 Azure 主干中断解决的完全所有权和可见性。
存在两种类型的提升：
- 计划提升：服务在启动提升之前等待以赶上复制延迟。 命名空间在此期间处于只读模式，拒绝新消息和使用者作，直到升级完成。
- 强制升级：服务会立即启动升级，而无需等待复制赶上。
在计划促销启动后，可以随时执行强制促销，使你能够控制在计划促销花费的时间比预期更长时加快促销速度。 但是，切换到强制升级会带来与直接启动强制升级相同的数据丢失风险。
Important
使用 强制 升级时，服务可能会丢失未复制的任何数据或元数据。 此外，由于尚未复制特定的状态更改，此操作还可能导致收到重复的消息，例如未复制“完成”或“延迟”状态更改。
强制升级后，旧的主数据库（现在辅助数据库）仍包含未复制的数据。 当旧的主数据库重新同步为新辅助数据库时，此数据将丢失。
Warning
执行 强制 升级后，旧的主要区域可能包含未复制的数据和状态不一致。 为了确保数据完整性并避免应用程序的潜在问题，当前的最佳做法是 删除旧的主要区域并重新创建它 ，而不是允许它重新同步为辅助区域。
强制升级后的建议步骤：
- 完成强制提升以建立新的主区域。
- 从 Geo-Replication 配置中删除旧的主要区域。
- 添加新的次要区域以还原异地冗余。
执行这些步骤有助于确保命名空间在所有区域使用一致的数据运行。
促销启动后：
主机名将更新为指向辅助区域，此过程可能需要几分钟。
注释
可以通过启动 ping 命令来检查当前主区域：ping your-namespace-fully-qualified-name
客户端自动重新连接到次要区域。
如果使用强制升级，则新的次要区域在重新同步时进入 InBuild 状态，然后转换为“就绪”。
可以通过监控系统或自定义开发的监控解决方案来自动进行推广。 但是，这种自动执行需要额外的规划和工作，它超出了本文的讨论范围。
使用 Azure 门户
在门户中，选择“ 提升 ”图标，然后按照弹出窗格中的说明删除该区域。
使用Azure CLI
运行 Azure CLI 命令以启动升级。
az servicebus namespace failover --namespace-name <your-namespace-name> --resource-group <your-resource-group> --primary-location <new-primary-location>
监视数据复制
可以通过检查复制滞后指标来监视复制作业的进度。 有关可用指标的完整列表，请参阅 服务总线指标。
提供了两个复制延迟指标，二者均按实体（EntityName 维度）分别报告：
- ReplicationLagDuration - 复制滞后时间（以秒为单位，即次要区域与主要区域相距有多远）。 此指标是用于监视恢复点目标（RPO）和配置警报的建议指标。 当滞后达到已配置的最大上限时，主节点会对传入请求进行限流。
- ReplicationLagCount - 次要区域落后于主要区域的待处理复制操作数量。 将其用作复制积压工作相对指标：持续增加意味着辅助数据库落后。 此值反映内部复制日志操作，而不是未复制的消息计数。
在 Azure 门户中查看复制滞后时间
在 Azure 门户中监控复制延迟：
- 在 Azure 门户中转到您的 服务总线 命名空间。
- 选择“监视”部分下的“指标”。
- 从下拉列表中选择 ReplicationLagDuration 指标。
- 此图表显示主要区域和次要区域之间的复制滞后时间（以秒为单位）。
还可以针对此指标设置警报，以在滞后时间超过阈值时收到通知。
在 Log Analytics 中查看复制滞后时间
若要使用 Log Analytics 进行查询和历史分析，请执行以下作：
- 如 Monitor Azure 服务总线 中所述，在服务总线命名空间中启用指标日志。
- 启用指标日志后，需要从命名空间生成和使用数据几分钟，然后才能开始查看日志。
- 若要查看指标日志，请转到服务总线的“监视”部分，然后选择“日志”边栏选项卡。 可以使用以下查询查找主要区域和次要区域之间的复制滞后时间（以秒为单位）。
AzureMetrics
| where TimeGenerated > ago(1h)
| where MetricName == "ReplicationLagDuration"
Considerations
使用此功能时，请记住以下注意事项：
- 在促销计划中，请考虑时间因素。 例如，如果失去连接超过 15 到 20 分钟，你可能会选择开始促销活动。
- 应 至少排练 一次推广复杂的分布式基础结构。
Pricing
服务总线的高级层级按消息传送单元定价。 使用异地复制功能，每个副本在与主要区域上配置的 MU 数量相同的 MU 上运行，并且需要为所有副本的 MU 总数付费。 此外，会根据被复制到次要副本的数据收取费用。 数据传输速率由主要区域在复制时所在的区域确定。 有关当前定价详细信息（包括数据传输费率），请参阅 “服务总线定价”页。
可以计算总成本，如下所示：
（副本数 × 主实例上配置的 MU 数量 × 小时数 × 每个 MU 的每小时费率）+（复制的数据量（GB）× 每 GB 的数据传输费率）
例如，如果在主命名空间上配置了 2 个 MU，并且复制了 10 GB 的数据：
（2 个副本 x 2 个 MU x 小时数 x 每小时费率）+（10 GB x 数据传输费率）
触发促销的推荐场景
虽然可以随时触发提升，但建议在以下一些场景中将次要提升为主要。 有关每个方案的详细信息，请参阅 方案。
- 区域中断：如果发生影响主要区域的区域中断，请提升次要区域以确保业务连续性并最大程度地减少停机时间。
- 性能降低：如果主要区域遇到影响命名空间可用性或可靠性的性能问题，则提升次要区域有助于缓解这些问题。
- 计划内维护：在主要区域中的计划内维护活动期间，提升次要区域有助于保持高可用性。
- 灾难恢复测试：定期测试故障转移机制，以确保业务连续性计划有效，应用程序可以在需要时无缝切换到次要区域。
Migration
若要从 Geo-Disaster 恢复 迁移到异地复制，请先中断主命名空间上的配对。
中断配对后，请按照 设置 启用异地复制。
专用端点
通过私有端点连接到服务总线命名空间的客户端在故障切换后会自动连接到新的主区域。 服务总线命名空间在内部将流量路由到当前的主区域，因此客户端无需知道主区域，私有端点也能继续正常工作，无需更改。 提升通常在两分钟内完成，在此期间客户端可能会看到瞬时错误并重新连接。 相应地配置重试策略。
私有端点是区域性资源。 为了实现高可用性，可以在多个区域部署应用，并在每个区域的虚拟网络中创建一个私有端点。
DNS
每个地区只设一个 privatelink.servicebus.chinacloudapi.cn 私有DNS区，只连接到该区域的虚拟网络。 当你附加私有DNS区域组时，本地私有端点的A记录会自动添加。 每个区域都会将命名空间名称解析到其本地端点，无论哪个区域是主区域。
如果你在两个虚拟网络之间共享同一个专用 DNS 区域，则只会存在一条 A 记录，并且它会指向最后关联的那个终结点。 在这种情况下，添加 跨区域虚拟网络对等连接 ，让所有客户端都能访问该端点。
对于本地客户端，通过条件转发或手动维护的记录，将命名空间解析到最近区域的私有端点。 推广不需要本地更改DNS。
故障切换场景
- 仅限应用程序的故障转移。 应用程序会迁移到另一个虚拟网络。 它通过本地私有端点到达命名空间。
- 仅限命名空间的故障切换。 服务总线 的主角色发生转移。 客户端保持相同的连接字符串和本地端点;流量会自动路由到新的主节点。
- 区域性中断。 受影响区域的私有端点无法访问。 在健康区域中具有专用终结点的客户端将继续在剩余可用区域上运行。
后续步骤
若要了解有关服务总线消息传送的详细信息，请参阅以下文章：