你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 事件中心 是一种本地云服务，能够以较低延迟每秒流式传输数百万个事件，从任何源到任何目标。 使用事件中心引入和存储流数据，并与为 Apache Kafka 或使用事件中心客户端 SDK 的应用程序生成的客户端应用程序集成。
使用 Azure 时， 可靠性是共同的责任。 Microsoft提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。
本文介绍了事件中心如何能够具有韧性以应对各种潜在的中断和问题，以及如何将其配置为能够抵御其他问题，包括瞬时故障、可用区中断和区域性中断。 它还介绍了备份和恢复选项，并重点介绍了有关 Azure 事件中心服务级别协议（SLA）的一些关键信息。
生产部署建议
若要了解如何部署事件中心以支持解决方案的可靠性要求，并了解可靠性如何影响体系结构的其他方面，请参阅 Azure Well-Architected Framework 中事件中心的体系结构最佳做法。
可靠性体系结构概述
本部分从可靠性角度介绍了有关事件中心工作原理的重要方面。 它引入了逻辑体系结构，其中包括部署和使用的资源和功能。 它还介绍了物理体系结构，其中提供了有关服务在内部如何管理作的详细信息。
逻辑体系结构
事件中心 命名空间 充当一个或多个事件中心的管理容器。 可以在命名空间级别配置服务，例如分配流式处理容量、配置网络安全以及启用异地复原和异地灾难恢复。
在命名空间中，可以将事件组织到 事件中心。 Apache® Kafka 生态系统将这种类型的实体称为 主题。 事件中心或主题是事件的仅允许追加的分布式日志。
每个事件中心都包含一个或多个分区，这些 分区是顺序事件的日志。 事件中心可以使用多个分区来执行并行处理和水平缩放。 事件中心只保证单个分区内的排序。 分区在应用程序的可靠性设计中起着关键作用。 设计应用程序时，在最大化可用性和一致性之间进行权衡。 若要最大程度地提高大多数应用程序的运行时间，请避免直接从客户端应用程序对分区进行寻址。 有关详细信息，请参阅 事件中心的可用性和一致性。
从事件中心读取数据的使用者可通过维护自己的检查点按顺序读取事件，该检查点用于标识他们接收的最后一个事件。
有关事件中心中的分区和其他基本概念的详细信息，请参阅 事件中心的功能和术语。
物理体系结构
在物理体系结构中，事件中心命名空间在 群集中运行。 群集提供基础计算和存储资源。 大多数命名空间在其他 Azure 客户共享的群集上运行。 使用高级层时，命名空间将分配共享群集中的专用资源。 使用专用层级时，集群被专门用于你的命名空间。 有关专用群集的详细信息，请参阅 事件中心专用层概述。 无论层和群集类型如何，Microsoft管理群集及其基础虚拟机和存储。
为了实现冗余，每个群集都有处理读取和写入请求的多个副本。 为了获得高可用性和性能优化，所有数据都存储在三个存储副本上。 若要缩放命名空间的计算资源，请根据层级部署吞吐量单位（TU）、处理单位（PU）或容量单位（CU）。 有关详细信息，请参阅 使用事件中心进行缩放。
群集跨越多个物理计算机和机架，从而降低影响命名空间的灾难性故障的风险。 在具有可用性区域的区域中，群集跨单独的物理数据中心扩展。 有关详细信息，请参阅 可用性区域故障的复原能力。
暂时性故障的复原能力
暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。
与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循 Azure 暂时性故障处理指南。 有关详细信息，请参阅 处理暂时性故障的建议。
事件中心实现透明故障检测和故障转移机制，以便服务继续在保证服务级别内运行，通常不会在发生故障时明显中断。
设计客户端应用程序以使用事件中心时，请遵循以下指南：
使用内置的重试策略。 事件中心和 Apache Kafka SDK 会自动重试操作，例如网络超时、限制响应或服务器繁忙等情况的可重试错误。 为了避免不必要的重载服务，它们默认实现指数退避。
根据应用程序要求配置适当的超时值。 默认超时通常为 60 秒，但可以根据方案进行调整。
在事件处理程序中实现检查点以跟踪进度，并在临时故障后能够从上次处理位置进行恢复。
使用批处理执行发送作 来提高吞吐量，并减少暂时性网络问题对单个消息的影响。
如果使用 Kafka 协议，请使用 Apache Kafka SDK。 Kafka SDK 还实施重试策略和其他最佳做法，以帮助处理暂时性故障。
应对可用区故障的弹性
可用性区域 是 Azure 区域内物理上独立的数据中心组。 当一个区域发生故障时，服务可以故障转移到其他区域。
事件中心支持所有服务层中的区域冗余部署。 在受支持的区域中创建事件中心命名空间时，会自动启用区域冗余，无需额外付费。 但是，使用专用层时，可用性区域仅在至少有三个 CU 的情况下得到支持。 区域冗余部署模型适用于所有事件中心功能，包括捕获、架构注册表和 Kafka 协议支持。
事件中心以透明方式跨区域中的三个可用性区域复制配置、元数据和事件数据。 区域冗余提供自动故障转移，无需用户进行任何干预。 所有事件中心组件（包括计算、网络和存储）都会跨区域复制。 事件中心有足够的容量储备来立即处理区域完全丢失的情况。 即使整个可用性区域变得不可用，事件中心也会继续运行，而不会丢失数据或中断流式处理应用程序。
此图显示了跨三个可用性区域分布的事件中心群集。 每个区域都包含一个共享命名空间，群集跨越所有区域以提供高可用性。
区域支持
区域冗余事件中心命名空间可以部署到 支持可用性区域的任何 Azure 区域。
要求
标准和高级层支持可用性区域，无需额外配置。
对于专用层，可用性区域至少需要三个计算单元 (CU)。
成本
事件中心中的区域冗余不会增加额外的成本。
配置可用性区域支持
在 受支持的区域中部署时，事件中心命名空间会自动支持区域冗余。 无需进一步配置。
所有区域正常时的行为
当事件中心命名空间使用区域冗余并且所有可用性区域正常运行时，预计会出现以下行为：
区域之间的流量路由： 事件中心在主动-主动模型中运行，其中三个可用性区域中的基础结构同时处理传入事件。
区域之间的数据复制： 事件中心跨可用性区域使用同步复制。 当事件生成者发送事件时，事件中心会在确认写入作完成到客户端之前，将其写入到多个区域中的副本。 此方法可确保零数据丢失，即使整个区域不可用也是如此。 同步复制方法提供强大的一致性保证，同时通过优化的复制协议保持低延迟。
区域故障期间的行为
当事件中心命名空间使用区域冗余并且发生可用性区域中断时，预计会出现以下行为：
- 检测和响应： 事件中心负责自动检测可用性区域中的故障。 无需启动区域故障转移。
- 通知：当区域关闭时，Microsoft不会自动通知你。 但是，可以使用 Azure 服务运行状况 来了解服务的总体运行状况，包括任何区域故障，并且可以设置 服务运行状况警报 来通知问题。
活动请求： 在区域故障期间，事件中心可能会删除活动请求。 如果客户在短时间内重试，以适当处理暂时性故障，通常可以避免重大影响。
预期数据丢失： 区域故障期间不会发生数据丢失，因为事件中心在确认之前同步跨区域复制事件。
预期的停机时间： 区域故障可能会导致几秒钟的停机时间。 如果客户在短时间内重试，以适当处理暂时性故障，通常可以避免重大影响。
流量重新路由： 事件中心检测到区域丢失，并自动将新请求重定向到一个正常的可用性区域中的另一个副本。
事件中心客户端 SDK 通常以透明方式处理连接管理和重试逻辑。
区域恢复
当可用性区域恢复时，事件中心会自动将区域重新集成到活动服务拓扑中。 恢复的区域开始接受新连接，并与其他区域一起处理事件。 在服务中断期间复制到幸存区域的数据保持不变，所有区域中的正常同步复制都会恢复。 无需采取任何措施进行区域恢复和重新集成。
测试区域故障
事件中心负责流量路由、故障转移和区域恢复，以管理区域故障，因此您无需验证可用区故障程序，也无需提供其他输入。
对区域范围的故障的复原能力
事件中心提供两种类型的多区域支持：
异地复制（高级层和专用层） 提供主要区域与一个或多个次要区域之间的元数据和事件数据的主动-主动复制。 对需要保持对区域中断复原且对事件数据丢失的容忍度较低的大多数应用程序使用异地复制。
元数据异地灾难恢复（标准层及更高层） 提供主要区域和次要区域之间的配置和元数据的主动-被动复制，但不会复制事件数据。 对能在灾难情境中容忍一些事件数据丢失的应用程序使用地理灾难恢复，并需要在其他区域快速恢复作业。
异地复制和元数据异地灾难恢复都需要手动启动故障转移或将次要区域提升为新的主要区域。 即使主区域不可用，Microsoft 也不会自动执行故障转移或升级操作。
异地复制
高级层和专用层支持异地复制。 此功能复制命名空间的元数据（如实体、配置和属性）和数据（如事件有效负载）。 为命名空间的配置和事件数据配置复制方式。 此功能可确保事件在另一个区域中保持可用状态，并允许在需要时切换到次要区域。 它还复制模式注册表的元数据和数据。
对于需要抵御区域中断且对事件数据丢失的容忍度较低的情况，请使用地理复制。
命名空间实质上跨区域扩展。 一个区域作为主要区域，其他区域作为次要区域。 无论为异地复制配置了多少个次要区域，Azure 订阅都会显示单个命名空间。
可以随时将次要区域 提升 为主要区域。 升级次要区域时，事件中心会将命名空间的完全限定域名（FQDN）重新指向所选次要区域，并将以前的主要区域降级到次要区域。 你决定是执行 计划的升级，这意味着你等待数据复制完成，还是 强制升级，这可能会导致数据丢失。
注释
事件中心异地复制使用术语 提升 ，因为它最能表示将次要区域提升到主要区域的过程（稍后将主要区域降级到次要区域）。 还可能会出现用于描述常规过程的术语“故障转移”。
本部分总结了异地复制的重要方面。 查看完整的文档以了解其工作原理。 有关详细信息，请参阅 事件中心异地复制。
区域支持
可以选择支持事件中心作为主要区域或次要区域的任何 Azure 区域。 无需使用 Azure 配对区域，因此可以根据延迟、符合性或数据驻留要求选择次要区域。
要求
若要启用异地复制，命名空间必须使用高级层或专用层。
注意事项
启用异地复制时，请考虑以下因素：
检查点格式： 检查点的格式更改。 有关详细信息，请参阅 异地复制：消耗数据。
专用终结点： 如果使用专用终结点连接到命名空间，则还需要在主要区域和次要区域中配置网络。 有关详细信息，请参阅专用终结点。
成本
若要了解异地复制的定价工作原理，请参阅 “定价”。
配置多区域支持
在新的或现有的命名空间上启用异地复制。 若要为新创建的命名空间设置主动-主动复制，请参阅 在新命名空间上启用异地复制。 若要在现有命名空间上设置主动-主动复制，请参阅 在现有命名空间上启用异地复制。
更改复制方法。 若要在同步复制模式和异步复制模式之间进行更改，请参阅 “切换复制模式”。
禁用异地复制。 若要禁用到次要区域的异地复制，请参阅 “删除次要区域”。
当所有区域都正常时的行为
本部分介绍为事件中心命名空间配置异地复制，以及主要区域正常运行时会发生的情况。
区域之间的流量路由： 客户端应用程序通过命名空间的 FQDN 及其流量路由连接到主要区域。
只有在正常作期间，主要区域才会主动处理来自客户端的事件。 次要区域接收复制的事件，否则在备用模式下保持被动。
区域之间的数据复制： 主要区域和次要区域之间的数据复制行为取决于是将复制配对配置为使用同步复制还是异步复制。
同步： 在写入作完成之前，事件将复制到次要区域。
此模式能最大程度地确保事件数据的安全性，因为这些数据必须在主要区域和次要区域中进行保存。 但是，同步复制大大增加了传入事件的写入延迟。 它还要求次要区域能够接受写入作，因此任何次要区域中的中断都会导致写入作失败。
- 异步： 事件被写入主要区域，然后写入操作完成。 不久后，它会将事件复制到次要区域。
此模式提供的写入吞吐量高于同步复制，因为写入作期间没有区域间复制延迟。 此外，异步复制模式可以容忍从属区域的丢失，同时仍允许在主要区域中进行写入操作。 但是，如果主要区域发生中断，则尚未复制到次要区域的任何数据都可能不可用或丢失。
配置异步复制时，请配置复制所需的最大可接受的延迟时间。 随时可以使用 Azure Monitor 指标验证当前复制滞后时间。
如果异步复制滞后时间超出指定的最大值，则主要区域开始限制传入请求，以便复制能够赶上。 为了避免这种情况，请务必选择地理上不太远的次要区域，并确保容量足以满足吞吐量。
有关详细信息，请参阅 复制模式。
区域故障期间的行为
本部分介绍为事件中心命名空间配置异地复制，以及主要区域或次要区域发生故障时会发生的情况。
检测和响应： 你负责决定何时将命名空间的次要区域提升为新的主要区域。 即使发生区域中断，Microsoft也不会为你做出此决定或启动该过程。 有关如何将次要区域提升到新主要区域的详细信息，请参阅 “提升次要区域”。
升级次要区域时，选择是执行 计划的升级 还是 强制升级。 计划内升级会等待辅助区域同步完成后，再接收新流量。 此方法可消除数据丢失，但会导致停机。
在主要区域的中断期间，通常需要执行强制升级。 如果主区域可用，且你因其他原因触发升级，可选择计划内升级。
通知： Microsoft不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 来了解服务的总体运行状况，包括任何区域故障，并且可以设置 服务运行状况警报 来通知问题。
使用该信息和其他指标来确定何时将次要区域提升到主要区域。
活动请求： 此行为取决于区域中断发生在主要区域还是次要区域：
主要区域中断： 如果主要区域不可用，则会终止所有活动请求。 客户端应用程序应在晋级完成后重试操作。
次要区域中断： 在以下情况下，次要区域中的中断可能会导致活动请求出现问题：
如果使用同步复制模式，如果任何次要区域不可用，则主要区域无法完成写入作。
如果使用异步复制模式，则命名空间会限制，在复制滞后时间达到所配置的最大值后不接受新事件。
若要继续使用主要区域中的命名空间，请从异地复制配置中删除辅助命名空间。
预期数据丢失： 数据丢失量取决于您执行的提升类型（计划的或强制的）和复制模式（同步的或异步的）：
计划内促销： 不会丢失任何数据。 但是，在区域中断期间，可能无法进行计划内升级，因为它要求所有主要区域和次要区域都可用。
强制升级、同步复制： 不会丢失任何数据。
强制升级、异步复制： 对于未复制到次要区域的最新事件，可能会遇到一些数据丢失。 金额取决于复制滞后时间。 若要验证当前复制滞后时间，请使用 Azure Monitor 指标。
如果执行强制升级，即使主要区域可用，也不能恢复丢失的数据。
预期的停机时间： 预期的停机时间量取决于是执行计划内升级还是强制升级：
计划的推广： 计划推广的第一步是将数据复制到备用区域。 此过程通常很快完成，但在某些情况下，由于复制滞后，可能需要花费与复制滞后时间相当的时间才完成。 复制完成后，升级过程通常需要大约 5 到 10 分钟。 域名系统（DNS）服务器有时可能需要更长的时间来更新条目并完全将其记录复制到客户端。
在整个升级过程中，主区域不接受写入操作。
在发生区域中断期间，此选项可能无法实现，因为它要求所有主要区域和次要区域都可用。
强制升级： 在强制升级期间，事件中心不会等待数据复制完成，并且会立即启动升级。 升级过程通常需要大约 5 到 10 分钟。 有时，在客户端之间完全复制和更新 DNS 条目可能需要更长的时间。
在整个升级过程中，主区域不接受写入操作。
流量重新路由： 升级完成后，命名空间的 FQDN 指向新的主要区域。 但是，此重定向取决于客户端 DNS 记录的更新速度，其中包括其 DNS 服务器是否遵循命名空间 DNS 记录的生存时间（TTL）。
在某些情况下，必须将使用者应用程序配置为在区域升级后保持行为一致。 有关详细信息，请参阅 异地复制：消耗数据。
区域恢复
原始主要区域恢复后，如果要将命名空间返回到其原始主要区域，请遵循相同的区域升级过程。
如果在区域中断期间执行强制升级，即使主要区域可用，也不能恢复丢失的数据。
针对区域故障进行测试
若要测试异地复制，请暂时将次要区域提升为主区域，并验证客户端应用程序是否可以在发生最小中断的情况下在区域之间切换。
监视升级持续时间并验证 Runbook 和自动化是否正常工作。 测试后，可以将系统切回到原始配置。
了解升级过程中及升级后可能遇到的潜在停机时间和数据丢失情况。 在非生产环境中测试异地复制，以镜像生产命名空间的配置。
元数据地理灾难恢复
标准层和更高层支持元数据异地灾难恢复。 此功能可改进灾难场景下的恢复能力，包括区域发生灾难性故障的情况。 异地灾难恢复仅复制命名空间的配置和元数据。 但是，它不会复制事件数据。 为了支持灾难恢复，此功能可确保预配置另一个区域中的命名空间，并准备好立即接受来自客户端的事件。 异地灾难恢复是一种单向恢复解决方案，不支持故障恢复到之前的主区域。
元数据地理灾难恢复最适合不需要严格维持每个事件的应用程序，并且能够在灾难情景中忍受一些数据丢失。 例如，如果你的事件代表后续会汇总的传感器读数，若能在另一个区域快速恢复处理新事件，你可能会认为可以承受从故障区域丢失部分事件的损失。
重要
异地灾难恢复可实现配置相同的业务连续性，但不会复制事件数据。 如果需要复制事件数据，请考虑使用 异地复制。
配置元数据的异地灾难恢复时，需要创建一个供客户端应用程序连接的别名。 别名是一个 FQDN，默认情况下将所有流量定向到主命名空间。
如果主要区域发生故障或发生其他类型的灾难，可以随时手动启动从主要区域到次要区域的单向故障转移。 故障转移几乎可瞬间完成。 在故障转移过程中，异地灾难恢复别名会重新指向辅助命名空间，且配对关系会被移除。
本部分总结了异地灾难恢复的重要方面。 查看完整的文档以了解其工作原理。 有关详细信息，请参阅 事件中心异地灾难恢复。
区域支持
可以选择任何支持事件中心作为主要命名空间或辅助命名空间的 Azure 区域。 无需使用 Azure 配对区域，因此可以根据延迟、符合性或数据驻留要求选择次要区域。
要求
主命名空间层： 主命名空间必须位于标准层或更高级别中，才能使用元数据跨地域灾难恢复。
辅助命名空间层： 元数据异地灾难恢复支持主要命名空间和辅助命名空间的特定层组合。 有关详细信息，请参阅 支持的命名空间对。
注意事项
角色分配： Microsoft Entra 主命名空间中实体的基于角色的访问控制（RBAC）分配不会复制到辅助命名空间。 在辅助命名空间中手动创建角色分配，以保护对它们的访问。
架构注册表： 使用元数据异地灾难恢复时，架构注册表元数据会复制，但注册到架构注册表的架构不会复制。
应用程序设计： 设计客户端应用程序时，异地灾难恢复需要特定的注意事项。 有关详细信息，请参阅 注意事项。
专用终结点： 如果使用专用终结点连接到命名空间，请在主要区域和次要区域中配置网络。 有关详细信息，请参阅专用终结点。
成本
启用元数据异地灾难恢复时，需要为主要命名空间和辅助命名空间付费。
配置多区域支持
容量计划和管理
规划多区域部署时，如果一个区域发生故障，请确保这两个区域有足够的容量来处理完整负载。 次要区域在正常运行期间保持被动状态，但故障转移后必须立即处理流量。 规划如何缩放辅助命名空间容量，以便它可以不延迟地接收生产流量。 如果在故障转移过程中可以容忍额外的停机时间，则可以选择在故障转移期间或故障转移后缩放辅助命名空间容量。 若要减少停机时间，请提前在辅助命名空间中预配容量，使其仍可接收生产负载。
当所有区域都正常时的行为
本部分介绍为事件中心命名空间配置异地灾难恢复，以及主要区域正常运行时会发生的情况。
区域之间的流量路由： 客户端应用程序通过命名空间的异地灾难恢复别名及其流量路由到主要区域中的主命名空间进行连接。
在正常作期间，只有主命名空间主动处理来自客户端的事件。 辅助命名空间在备用模式下保持被动状态，访问数据的任何请求都失败。
区域之间的数据复制： 仅配置元数据在命名空间之间复制。 配置复制持续且异步。
所有事件数据仅保留在主命名空间中，不会复制到辅助命名空间。
区域故障期间的行为
本部分介绍为事件中心命名空间配置异地灾难恢复，以及主要区域发生中断时会发生的情况。
检测和响应： 你负责监视区域运行状况并手动启动故障转移。 即使主要区域发生故障，Microsoft 也不会自动执行故障转移或升级次要区域。
有关如何启动故障转移的详细信息，请参阅 手动故障转移。
故障转移是一项单向操作，因此之后需要重新建立异地灾难恢复配对关系。 有关详细信息，请参阅 区域恢复。
通知： Microsoft不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 来了解服务的总体运行状况，包括任何区域故障，并且可以设置 服务运行状况警报 来通知问题。
使用该信息和其他指标来确定何时故障转移到次要区域。
活动请求： 在故障转移启动时，正在进行的活动请求将终止。 客户端应用程序应在故障转移完成后重试操作。
预期数据丢失：
元数据： 配置和元数据通常复制到辅助命名空间。 但元数据复制是异步进行的，因此最近的更改可能不会复制，尤其是复杂的更改。 在客户端访问辅助命名空间之前验证辅助命名空间的配置。
事件数据： 事件数据不会在区域之间复制。 如果主要区域出现故障，主命名空间中的事件将变得不可用。
除非灾难性灾难导致主要区域完全丢失，否则这些事件不会永久丢失。 如果区域恢复，则可以稍后从主命名空间检索事件。
预计停机时间：故障转移通常在 5 到 10 分钟内完成。 客户端可能需要更长的时间才能完全复制和更新 DNS 条目。
流量重新路由： 使用异地灾难恢复别名连接到命名空间的客户端在故障转移后自动重定向到辅助命名空间。 但是，此重定向取决于 DNS 服务器是否如实遵循命名空间 DNS 记录的 TTL，以及客户端接收到这些已更新的 DNS 记录。
区域恢复
原始主要区域恢复后，你必须手动重新建立配对关系，并可选择执行故障恢复操作。 新建异地灾难恢复配对，将恢复的区域设为次要区域，然后如果想返回原始区域，再次执行故障转移。 此过程可能会涉及发送到临时主节点的事件的数据丢失。
如果灾难导致主要区域中所有区域丢失，则可能无法恢复数据。 在其他情况下，您的事件数据在故障转移发生前仍保留在原主命名空间中，具有可恢复性。 还原访问后，可以从旧的主命名空间获取历史事件。 你负责配置应用程序以接收和处理这些事件。 Microsoft 不会自动将其还原到次要区域。
针对区域故障进行测试
若要测试你的响应流程和灾难恢复流程，可在维护时段内执行计划的故障转移。 启动从主命名空间到辅助命名空间的故障转移，并验证应用程序是否可以连接和处理来自新主命名空间的事件。
监视故障转移的持续时间，并验证 runbook 和自动化程序是否正常运作。 测试后，可以将系统切回到原始配置。
了解故障转移过程中及故障转移后可能遇到的潜在停机时间和数据丢失情况。 在非生产环境中测试异地复制，以镜像生产命名空间的配置。
用于复原的自定义多区域解决方案
异地复制和元数据异地灾难恢复为区域中断和其他问题提供复原能力，并且它们支持大多数工作负荷。 某些事件中心层不支持这些功能，或者可能需要自定义复制或需要同时维护多个活动区域。
各种设计模式可以在事件中心实现不同类型的多区域支持。 许多模式需要部署多个命名空间，并使用 Azure Functions 等服务在它们之间复制事件。 有关详细信息，请参阅 多站点和多区域联合。
备份和还原
事件中心不是数据的长期存储位置。 通常，将数据存储在事件中心短时间内，然后处理它或将其保存在另一个数据存储系统中。 可以根据你的要求和命名空间使用的层，为事件中心配置数据保留期。 有关详细信息，请参阅事件保留。
如果需要保留事件的副本，请考虑使用 事件中心捕获，它将事件副本保存到 Azure Blob 存储帐户。
服务级别协议
Azure 服务的服务级别协议 (SLA) 描述了每个服务的预期可用性，以及解决方案为实现该可用性预期而必须满足的条件。 有关详细信息，请参阅 联机服务的 SLA。
使用高级层或专用层时，命名空间的可用性 SLA 更高。