Azure 表存储 是一项服务，用于在云中存储结构化 NoSQL 数据，提供无架构设计的键/属性存储。 单个表可以包含具有不同属性集的实体，并且属性可以是各种数据类型。
Azure 表存储通过基础 Azure 存储平台提供多项可靠性功能。 作为 Azure 存储的一部分，表存储继承了相同的冗余选项、可用性区域支持和异地复制功能，以确保表数据的高可用性和持久性。
本文介绍 Azure 表存储中的可靠性和可用性区域支持。 有关 Azure 中可靠性的更详细概述，请参阅 Azure 可靠性。
注释
Azure 表存储是 Azure 存储平台的一部分。 表存储的某些功能在许多 Azure 存储服务中很常见。 本文档使用“Azure 存储”来指示这些常见功能。
生产部署建议
对于生产环境：
为包含表存储资源的存储帐户启用区域冗余存储（ZRS）。 ZRS 通过在主要区域中的多个可用性区域同步复制数据，从而提供更高的可用性，从而防止可用性区域故障。
如果需要提高对区域中断的容灾能力，并且存储帐户的主要区域已配对，请考虑启用异地冗余存储，以异步方式将数据复制到配对区域。 在受支持的区域中，可以使用 GZRS 将异地冗余与区域冗余相结合。
对于大规模生产工作负载，或者需要高可用性要求，请考虑使用 Azure Cosmos DB for Table。 Azure Cosmos DB for Table 与为 Azure 表存储编写的应用程序兼容。 它支持大规模的低延迟读取和写入操作，强大的全球分布能够跨多个区域进行，并提供灵活的一致性模型、内置备份，以及一系列其他功能，以增强应用程序的复原能力和性能。
可靠性体系结构概述
Azure 表存储在 Azure 存储平台基础结构中充当分布式 NoSQL 数据库。 该服务通过表数据的多个副本提供冗余，具体冗余模型取决于存储帐户配置。
本地冗余存储 (LRS) 将存储帐户中的数据复制到所选主要区域中的一个或多个 Azure 可用性区域。 尽管没有选择首选可用性区域的选项，但 Azure 可以跨区域移动或扩展 LRS 帐户以提高负载均衡。 无法保证数据将分散到各个区域。 有关可用性区域的详细信息，请参阅可用性区域是什么？。
区域冗余存储 (ZRS)、异地冗余存储 (GRS) 和异地区域冗余存储 (GZRS) 提供额外的保护。 本文详细介绍了这些选项。
暂时性故障
暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。
与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循 Azure 暂时性故障处理指南。 有关详细信息，请参阅 处理暂时性故障的建议。
Azure 表存储客户端库和 SDK 包括内置的重试策略，这些策略可自动处理常见的暂时性故障，例如网络超时、临时服务不可用（HTTP 503）、限制响应（HTTP 429）和分区服务器重载条件。 当应用程序遇到这些暂时性条件时，客户端库会使用指数退避策略自动重试作。
使用 Azure 表存储时，有效管理瞬态故障：
- 在表存储客户端中配置适当的超时，以平衡响应速度与对临时减速的适应能力。 Azure 存储客户端库中的默认超时通常适用于大多数方案。
- 为重试策略实现指数退避，尤其是在遇到 HTTP 503 服务器繁忙或 HTTP 500 操作超时错误时。 当单个分区变为热分区或存储帐户限制接近时，表存储可能会限制请求。
- 在大规模应用程序中设计分区感知重试逻辑。 分区感知重试逻辑是一种更高级的方法，它考虑表存储的分区体系结构，并在多个分区之间分配操作，以减少在单个分区服务器上遇到限流的可能性。
若要详细了解 Azure 表存储体系结构以及如何设计可复原和大规模应用程序，请参阅 表存储的性能和可伸缩性清单。
可用性区域支持
可用性区域 是每个 Azure 区域内物理上独立的数据中心群组。 当某个区域发生故障时，服务可以切换到其他可用的区域。
使用 ZRS 配置部署时，Azure 表存储是区域冗余的。 与 LRS 不同，ZRS 保证 Azure 跨多个可用性区域同步复制表数据。 此配置可确保即使整个可用性区域不可用，表仍可访问。 在完成之前，必须在多个区域中确认所有写操作，从而提供强的一致性保障。
区域冗余在存储帐户级别启用，并应用于该帐户中的所有表存储资源。 由于该设置适用于整个存储帐户，因此无法为不同的冗余级别配置单个实体。 当可用性区域遇到中断时，Azure 存储自动将请求路由到正常区域，而无需你或应用程序进行任何干预。
区域支持
可以在支持可用性区域的任何区域中部署区域冗余 Azure 存储帐户。
要求
必须使用标准常规用途 v2 存储帐户，为表存储启用区域冗余存储。 高级存储帐户不支持表存储。
成本
启用区域冗余存储 (ZRS) 时，由于额外的复制和存储开销，你需以不同于本地冗余存储 (LRS) 的费率付费。
有关详细的定价信息，请参阅 Azure 表存储定价。
配置可用性区域支持
更改复制类型。 若要了解如何将现有存储帐户更改为区域冗余存储 (ZRS)，以及配置选项和要求，请参阅更改存储帐户的复制方式。
禁用区域冗余。 使用相同的冗余配置更改过程，将 ZRS 帐户转换回非区域配置，例如本地冗余存储 (LRS)。
常规操作
本节介绍如何在配置表存储帐户以实现区域冗余，并且所有可用区都正常运行时的预期情况。
区域之间的流量路由：具有区域冗余存储 (ZRS) 的 Azure 存储自动在多个可用性区域中的存储群集之间分配请求。 流量分布对应用程序是透明的，不需要客户端配置。
区域之间的数据复制：对 ZRS 的所有写入操作都跨区域内的所有可用性区域进行同步复制。 上传或修改数据时，在数据成功复制到所有可用性区域之前，该作不会被视为完成。 此同步复制可确保在发生区域故障期间保持高度一致性和零数据丢失。
区域关闭体验
当可用性区域不可用时，Azure 表存储会自动使用以下行为处理故障转移过程：
检测和响应： Azure 会自动检测区域故障并启动恢复过程。 对于区域冗余存储 (ZRS) 帐户，不需要客户操作。
如果某个区域变得不可用，则 Azure 会执行网络更新，例如域名系统 (DNS) 重新指向。
通知：可以使用 Azure 服务运行状况和资源运行状况监视区域故障事件。 针对这些服务设置警报，以接收区域级别问题的通知。
活动请求：在恢复过程中，正在传输的请求可能会掉线，应该重试。 应用程序应 实现重试逻辑 来处理这些临时中断。
预期数据丢失： 区域故障期间不会发生数据丢失，因为在写入作完成之前，数据在多个区域中同步复制。
预期的故障时间：在自动恢复过程中，由于流量被重定向到正常区域，可能会出现少量故障时间，通常为几秒钟。 为 ZRS 设计应用程序时，请遵循暂时性故障处理的做法，包括实现具有指数退避的重试策略。
- 交通改道。 如果某个区域变为不可用，Azure 会进行网络更新（如域名系统 (DNS) 重新指向），以便将请求定向到剩余的正常可用性区域。 该服务通过剩余可用区域保持全部功能，无需客户干预。
区域恢复
发生故障的可用性区域恢复时，Azure 存储会自动还原所有可用性区域中的正常作。 该服务通过同步中断期间发生的任何操作来自动确保数据一致性。
对区域故障进行测试
使用区域冗余存储 (ZRS) 时，Azure 存储自动管理复制、流量路由和区域故障响应。 由于此功能是完全托管的，因此你无需启动或验证可用性区域故障流程。
多区域支持
Azure 存储（包括 Azure Blob 存储、Azure 文件存储、Azure 表存储和 Azure 队列存储）提供了一系列异地冗余和故障转移功能，以满足不同的要求。
重要
异地冗余存储 (GRS) 仅在 Azure 配对区域内工作。 如果存储帐户的区域未配对，请考虑使用 替代的多区域方法。
跨配对区域复制
Azure 存储在配对区域中提供多种类型的 GRS。 无论使用哪种类型的 GRS，次要区域中的数据始终使用本地冗余存储 (LRS) 进行复制。 此方法针对次要区域内的硬件故障提供了保护。
GRS 支持在主要区域发生中断时，向 Azure 配对区域的计划和未计划的故障转移。 GRS 以异步方式将数据从主要区域复制到配对区域。
异地区域冗余存储 (GZRS) 将主要区域中多个可用性区域中的数据复制到配对区域。
- 读取访问异地冗余存储 (RA-GRS) 和读取访问异地区域冗余存储 (RA-GZRS) 扩展了异地冗余存储 (GRS) 和异地区域冗余存储 (GZRS)，并具有对次要终结点进行读取访问的额外优势。 这些选项非常适合为高可用性业务关键型应用程序设计的应用程序。 在主终结点遇到中断的可能性不大的情况下，配置为对次要区域进行读取访问的应用程序可以继续运行。
故障转移类型
针对不同场景，Azure 存储支持三种类型的故障转移。
客户托管的未计划的故障转移：如果主要区域中出现区域范围的存储故障，你负责启动恢复。
客户托管的计划的故障转移：如果解决方案的另一部分在主要区域中发生故障，你负责启动恢复。 需要将整个解决方案切换到次要区域。
Microsoft托管的故障转移： 在特殊情况下，Azure可能会为某个区域中的所有异地冗余存储（GRS）帐户发起故障转移。 但是，Azure 管理的故障转移是最后的手段，仅预期在长时间的服务中断之后才执行。 不应依赖由 Azure 管理的故障转移。
GRS 帐户可以使用这些故障转移类型中的任何一种。 无需预先配置存储帐户即可使用任何故障转移类型。
区域支持
Azure 存储异地冗余配置使用 Azure 配对区域进行次要区域复制。 次要区域根据主要区域选择自动确定，无法自定义。
如果存储帐户的区域未配对，请考虑使用 替代的多区域方法。
要求
异地冗余存储 (GRS) 及客户发起的故障转移和故障回复可在支持常规用途 v2 Azure 存储帐户的所有 Azure 配对区域中使用。
注意事项
实现多区域 Azure 表存储时，请考虑以下重要因素：
异步复制延迟：向次要区域的数据复制是异步操作，这意味着将数据写入主要区域与这些数据在次要区域中变为可用之间存在一个滞后时间。 如果在复制最近的数据之前发生主要区域故障，则此滞后可能会导致潜在的数据丢失。 数据丢失由恢复点目标 (RPO) 度量。 可以预期复制滞后时间少于 15 分钟，但此时间是一个估计值，无法保证。
可以检查“上次同步时间”属性，了解如果存储帐户具有未计划的故障转移，可能会丢失多少数据。
次要区域访问：使用异地冗余存储 (GRS) 和异地区域冗余存储 (GZRS) 配置，在发生故障转移之前，无法访问次要区域进行读取。
读取访问异地冗余存储 (RA-GRS) 和读取访问异地区域冗余存储 (RA-GZRS) 配置在正常操作期间提供对次要区域的读取访问权限，但由于异步复制延迟，它们可能会返回略微过时的数据。
- 功能限制：在你使用异地冗余存储 (GRS) 或客户托管的故障转移时，某些 Azure 存储功能不受支持或存在限制。 在实现异地冗余之前，请查看功能兼容性。
成本
多区域 Azure 存储帐户配置对次要区域中的跨区域复制和存储会产生额外的成本。 Azure 区域之间的数据传输根据标准区域间带宽费率收费。
有关详细的定价信息，请参阅 Azure 表存储定价。
配置多区域支持
- 创建新的异地冗余存储 (GRS) 帐户。 若要创建 GRS 帐户，请参阅创建存储帐户，并在帐户创建期间选择 GRS、读取访问异地冗余存储 (RA-GRS)、异地区域冗余存储 (GZRS) 或读取访问异地区域冗余存储 (RA-GZRS)。
在现有存储帐户上启用异地冗余。 若要将现有存储帐户转换为异地冗余存储 (GRS)，请参阅更改存储帐户的复制方式，了解分步转换过程。
警告
为异地冗余重新配置帐户后，可能需要花费大量时间才能将新的主要区域中的现有数据完全复制到新的次要区域。
若要避免大量数据丢失，请在启动未计划的故障转移之前检查“上次同步时间”属性的值。 若要评估潜在的数据丢失，请将上次同步时间与上次将数据写入新的主要区域的时间进行比较。
禁用异地冗余。 使用相同的冗余配置更改过程，将 GRS 帐户转换回单区域配置，例如本地冗余存储 (LRS) 或区域冗余存储 (ZRS)。
常规操作
本部分说明当存储帐户配置为异地冗余且所有区域都正常运行时的预期情况。
区域之间的流量路由：Azure 存储使用主动-被动方法，其中所有写入操作和大多数读取操作都被定向到主要区域。
对于读取访问异地冗余存储 (RA-GRS) 和读取访问异地区域冗余存储 (RA-GZRS) 配置，应用程序可以通过访问次要终结点选择性地从次要区域读取。 此方法需要显式应用程序配置，并且不是自动的。 此外，由于异步复制滞后，次要区域中的数据可能略有过时。
区域之间的数据复制：通过使用以下配置的冗余类型，写入操作首先被提交到主要区域：
- 针对异地冗余存储 (GRS) 和 RA-GRS 的本地冗余存储 (LRS)
- 针对异地区域冗余存储 (GZRS) 和 RA-GZRS 的区域冗余存储 (ZRS)
在主要区域中成功完成后，数据被异步复制到次要区域，在其中使用 LRS 存储数据。
跨区域复制的异步性质意味着将数据写入主要区域与这些数据在次要区域中可用之间存在一个滞后时间。 可以使用“上次同步时间”属性监视复制时间。
区域故障体验
本部分介绍在为存储帐户配置了异地冗余，且主要区域中出现中断时会发生什么情况。
客户托管的故障转移（未计划）：当主要区域中的存储不可用时，请使用未计划的故障转移。
检测和响应：在主要区域中存储帐户不可用的极端情况下，可以考虑发起客户管理的计划外故障转移。 若要做出此决定，请考虑以下因素：
Azure 资源运行状况是否显示访问主要区域中存储帐户时出现问题
Azure 是否建议您执行故障转移到其他区域
警告
计划外故障转移 可能会导致数据丢失。 在启动客户托管的故障转移之前，请确定还原服务是否值得冒数据丢失的风险。
通知：可以通过 Azure 服务运行状况和资源运行状况监视区域故障事件。 针对这些服务设置警报，以接收区域级别问题的通知。
活动请求： 在故障转移过程中，主存储帐户终结点和辅助存储帐户终结点暂时都不能同时进行读取和写入。 可能会删除任何活动请求，客户端应用程序需要在故障转移完成后重试。
预期数据丢失：由于异步复制滞后，数据丢失在未计划的故障转移期间很常见，这意味着可能不会复制最近的写入。 可以检查“上次同步时间”属性，了解在未计划的故障转移期间可能会丢失多少数据。 你通常可以预期数据丢失少于 15 分钟，但这一时间是无法保证的。
预期的停机时间： 故障转移通常在 60 分钟内完成，具体取决于帐户大小和复杂性。
流量重新路由： 故障转移完成后，Azure 会自动更新存储帐户终结点，以便无需重新配置应用程序。 如果应用程序一直缓存域名系统 (DNS) 条目，则则可能有必要清除缓存，以确保应用程序将流量发送到新的主要区域。
故障转移后配置：在未计划的故障转移完成后，目标区域中的存储帐户使用本地冗余存储 (LRS) 层。 如果需要再次对其进行异地复制，则需要重新启用异地冗余存储 (GRS)，并等待数据复制到新的次要区域。
有关如何启动客户托管的故障转移的详细信息，请参阅客户托管的（未计划）故障转移的工作原理和启动存储帐户故障转移。
客户托管的故障转移（计划）：当存储在主要区域中保持运行，但你出于另一个原因需要将整个解决方案故障转移到次要区域时，请使用计划的故障转移。
检测和响应：你负责故障转移的决定。 如果你需要在区域之间进行故障转移，那么即使你的存储帐户正常，你通常也会做出此决定。 例如，当主要区域中发生另一个应用程序组件的重大中断且无法恢复时，你可能会启动故障转移。
通知：可以通过 Azure 服务运行状况和资源运行状况监视区域故障事件。 针对这些服务设置警报，以接收区域级别问题的通知。
活动请求： 在故障转移过程中，主存储帐户终结点和辅助存储帐户终结点暂时都不能同时进行读取和写入。 可能会删除任何活动请求，客户端应用程序需要在故障转移完成后重试。
预期数据丢失： 由于故障转移过程等待所有数据同步，因此不会丢失任何数据。
预期的停机时间： 故障转移通常在 60 分钟内完成，具体取决于帐户大小和复杂性。 在故障转移过程中，主存储帐户终结点和辅助存储帐户终结点暂时都不能同时进行读取和写入。
流量重新路由： 故障转移完成后，Azure 会自动更新存储帐户终结点，以便无需重新配置应用程序。 如果应用程序一直缓存 DNS 条目，则则可能有必要清除缓存，以确保应用程序将流量发送到新的主要区域。
故障转移后配置： 计划内故障转移完成后，目标区域中的存储帐户将继续进行异地复制，并保留在 GRS 层上。
有关如何启动客户托管的故障转移的详细信息，请参阅客户托管的（计划）故障转移的工作原理和启动存储帐户故障转移。
Microsoft 管理的故障转移： 在极少数情况下发生重大灾难时，如果 Azure 判断主要区域已经无法恢复，Azure 可能会自动切换至次要区域。 此过程完全由 Azure 管理，无需客户操作。 故障转移发生前经过的时间取决于灾难的严重性和评估情况所需的时间。
- 通知：可以通过 Azure 服务运行状况和资源运行状况监视区域故障事件。 针对这些服务设置警报，以接收区域级别问题的通知。
重要
使用客户管理的故障转移选项来开发、测试和实现灾难恢复计划。 请勿依赖于 Microsoft 托管的故障转移，这可能只在极端情况下使用。 Azure 托管的故障转移可能针对整个区域启动。 无法为单个存储帐户、订阅或客户启动该功能。 对于不同的 Azure 服务，故障转移可能在不同的时间发生。 建议使用客户托管的故障转移。
Failback
故障恢复过程在 Azure 托管的故障转移方案与客户管理的故障转移方案之间存在显著差异。
客户托管的故障转移（未计划）：在未计划的故障转移后，存储帐户配置有本地冗余存储 (LRS)。 若要进行故障回复，需要重新建立异地冗余存储 (GRS) 关系，并等待复制数据。
客户托管的故障转移（计划）：在计划的故障转移后，存储帐户保持异地复制状态。 可以启动另一个客户托管的故障转移，以故障回复到原始主要区域。 相同的故障转移注意事项仍然适用。
由微软管理的故障转移： 如果 Azure 启动故障转移，可能是因为在主要区域发生了重大灾难，主要区域可能难以恢复。 任何时间线或恢复计划都取决于区域灾难和恢复工作的程度。 应监视 Azure 服务运行状况通信以了解详细信息。
测试区域故障
可以模拟区域故障以测试灾难恢复过程。
计划的故障转移测试：对于异地冗余存储 (GRS) 帐户，可以在维护窗口期内执行计划的故障转移操作，以测试完整的故障转移和故障回复过程。 计划的故障转移不会导致数据丢失，但它在故障转移和故障回复期间确实涉及故障时间。
次要终结点测试：对于读取访问异地冗余存储 (RA-GRS) 和读取访问异地区域冗余存储 (RA-GZRS) 配置，请定期针对次要终结点测试读取操作，以确保应用程序能够从次要区域成功读取数据。
备选多区域方法
Azure 存储的跨区域故障转移功能可能不适合，原因如下：
存储帐户位于未配对的区域。
内置故障转移选项提供的恢复时间和数据丢失无法满足你的业务运行时间目标。
你需要故障转移到不是你的主要区域的配对的区域。
需要在区域之间进行主动/主动配置。
可转而设计满足需求的跨区域故障转移解决方案。 对 Azure 存储的部署拓扑的完全处理超出了本文的范围，但可以考虑多区域部署模型。
注释
对于构建为使用 Azure 表存储的应用程序，请考虑使用 Azure Cosmos DB for Table，后者支持高级多区域要求，包括对非成对区域的支持。 Azure Cosmos DB for Table 旨在与为 Azure 表存储生成的应用程序兼容。
可使用每个区域中的单独存储帐户，跨多个区域部署 Azure 存储。 此方法提供区域选择的灵活性、使用非配对区域的能力以及对复制计时和数据一致性的更精细控制。 跨区域实现多个存储帐户时，需要配置跨区域数据复制、实现负载均衡和故障转移策略并确保跨区域的数据一致性。
对于 Azure 表存储，多帐户方法要求管理数据分发、处理跨区域（包括冲突解决）的表之间的同步，以及实现自定义故障转移逻辑。
Backups
Azure 表存储不提供传统的备份功能，例如时间点恢复。 但是，可以为表数据实现自定义备份策略。 对于大多数解决方案，不应只依赖于备份。 请改用本指南中所述的其他功能来支持复原要求。 但是，备份可以防范其他方法没有的一些风险。 有关详细信息，请参阅 冗余、复制和备份。
如果需要内置备份功能，请考虑迁移到 Azure Cosmos DB for Table，从而为定期备份和连续备份提供支持。 有关详细信息，请参阅 Azure Cosmos DB 中的联机备份和按需数据还原。
对于需要从 Azure 表存储备份数据的方案，请考虑以下方法：
使用 Azure 数据工厂导出： 使用 Azure 表存储的 Azure 数据工厂连接器 将实体导出到另一个位置。 例如，可以将每个实体备份到存储在 Azure Blob 存储中的 JSON 文件。
应用程序级备份：在应用程序中实现自定义备份逻辑，将关键表实体导出到其他存储服务，例如 Azure SQL 数据库或 Azure Cosmos DB，以实现更可靠的备份和还原功能。
设计表存储的备份策略时，请考虑数据的分区性质，并确保备份进程可以通过并行处理多个分区来有效处理大型表。
服务级别协议
Azure 存储的服务级别协议（SLA）描述了服务的预期可用性以及达到该可用性预期必须满足的条件。 你有资格获得的可用性 SLA 取决于你所使用的存储层和复制类型。 有关详细信息，请参阅 联机服务的 SLA。