本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 多区域基础知识 2：了解数据
当您采用多区域架构时，管理数据是一个不容忽视的问题。区域之间的地理距离会带来不可避免的延迟，这种延迟表现为跨区域复制数据所花费的时间。在可用性、数据一致性以及为使用多区域架构的工作负载引入更高的延迟之间进行权衡是必要的。无论您使用异步复制还是同步复制，都需要修改应用程序以应对复制技术带来的行为变化。数据一致性和延迟方面的挑战使得使用专为单一区域设计的现有应用程序并使其成为多区域变得非常困难。了解特定工作负载的数据一致性要求和数据访问模式对于权衡利弊至关重要。
## 2.a：了解数据一致性要求
[CAP 定](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/cap-theorem.html)理为推理数据一致性、可用性和网络分区之间的权衡提供了参考。对于一个工作负载，只能同时满足其中两个要求。顾名思义，多区域架构包括区域之间的网络分区，因此您必须在可用性和一致性之间做出选择。
如果您选择跨区域的数据可用性，则在事务写入操作期间不会出现明显的延迟，因为依赖区域间提交的数据的异步复制会导致复制完成之前各区域之间的一致性降低。对于异步复制，当主区域出现故障时，写入操作很有可能等待从主区域进行复制。这会导致一种情况，即在恢复复制之前，最新数据不可用，并且需要对账流程来处理未从经历中断的地区复制的正在进行的交易。这种情况需要了解您的业务逻辑，并创建一个特定的流程来重播事务或比较各区域之间的数据存储。
对于偏爱异步复制的工作负载，您可以使用 [Amazon Aurora 和 Amazon](https://aws.amazon.com/rds/aurora/) D [ynamo](https://aws.amazon.com/dynamodb/) DB 等服务进行异步跨区域复制。[Amazon Aurora 全球数据库](https://aws.amazon.com/rds/aurora/global-database/)和[亚马逊 DynamoDB 全局](https://aws.amazon.com/dynamodb/global-tables/)表都有默认的[ CloudWatch亚马逊](https://aws.amazon.com/cloudwatch/)指标，以帮助监控复制延迟。Aurora 全球数据库由一个写入数据的主区域和最多五个只读辅助区域组成。DynamoDB 全局表由跨任意数量的区域的多活动副本表组成，您的数据将从中写入和读取。
设计工作负载以利用事件驱动架构对多区域策略来说是一个好处，因为这意味着工作负载可以包括数据的异步复制，并通过重播事件来实现状态重建。由于流媒体和消息服务将消息负载数据缓冲到单个区域，因此区域故障转移或故障恢复过程必须包括重定向客户端输入数据流的机制。该流程还必须核对存储在经历中断的地区的飞行中或未交付的有效载荷。
如果您选择 CAP 一致性要求并使用跨区域同步复制的数据库来支持在多个区域同时运行的应用程序，则可以消除数据丢失的风险并使数据在区域之间保持同步。但是，这会引入更高的延迟特征，因为写入需要提交到多个区域，而且这些区域彼此之间可能相隔数百或数千英里。您需要在应用程序设计中考虑这种延迟特性。此外，同步复制可能会导致相关故障，因为写入操作需要提交到多个区域才能成功。如果一个区域内存在损失，则需要形成法定人数才能成功写入。这通常涉及在三个区域中设置数据库，并建立三个区域中两个的法定人数。 诸如 [Paxos](https://www.cs.yale.edu/homes/aspnes/pinewiki/Paxos.html) 之类的技术可以帮助同步复制和提交数据，但需要大量的开发人员投资。
当写入涉及跨多个区域的同步复制以满足严格的一致性要求时，写入延迟会增加一个数量级。如果不进行重大更改（例如重新审视应用程序的超时和重试策略），通常无法将较高的写入延迟改装到应用程序中。理想情况下，在首次设计应用程序时必须将其考虑在内。对于优先考虑同步复制的多区域工作负载，[AWS Partner 解决方案可以提供](https://partners.amazonaws.com/)帮助。
## 2.b：了解数据访问模式
工作负载数据访问模式要么是*读取密集型，要么是*写*密集型*。了解特定工作负载的这一特性将有助于您选择合适的多区域架构。
对于读取密集型工作负载，例如完全只读的静态内容，您可以实现[主动-主动](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)多区域架构，与写入密集型工作负载相比，该架构的工程复杂性更低。使用内容分发网络 (CDN) 在边缘提供静态内容，通过缓存最接近最终用户的内容来确保可用性；[在 Amazon 中使用诸如源故障转移之](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)类的功能集 CloudFront可以帮助实现这一目标。另一种选择是在多个区域部署无状态计算，并使用 DNS 将用户路由到最近的区域以读取内容。您可以使用[带有地理定位路由策略的 Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) 来实现这一目标。
对于读取流量比例高于写入流量百分比的读取密集型工作负载，您可以使用[本地读取、写入全局策略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)。这意味着所有写入请求都将发送到特定区域的数据库，数据将异步复制到所有其他区域，并且可以在任何区域进行读取。这种方法需要工作负载才能实现最终一致性，因为跨区域写入复制的延迟增加可能会导致本地读取过时。
[Aurora 全球数据库](https://aws.amazon.com/blogs/database/improving-business-continuity-with-amazon-aurora-global-database/)可以帮助在只能在本地处理所有[读取流量的备用区域中配置只读副本](https://aws.amazon.com/rds/features/read-replicas/)，并在特定区域预置单个主数据存储以处理写入流量。数据从主数据库异步复制到备用数据库（只读副本），如果您需要将操作故障转移到备用区域，则可以将备用数据库提升为主数据库。您也可以在这种方法中使用 DynamoDB。D@@ [ynamoDB 全局](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)表可以跨区域[预配置副本](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/V2globaltables_HowItWorks.html)表，每个区域都可以扩展以支持任意数量的本地读取或写入流量。当应用程序将数据写入一个区域中的副本表时，DynamoDB 会自动将写操作传播到其他 区域的其他副本表。使用此配置，数据将从定义的主区域异步复制到备用区域中的副本表。任何区域中的副本表都可以随时接受写入，因此将备用区域提升为主区域是在应用程序级别管理的。同样，工作负载必须包含最终的一致性，如果不是从一开始就为此而设计的，则可能需要对其进行重写。
对于写入密集型工作负载，应选择主区域，并在工作负载中设计故障转移到备用区域的功能。与主动-主动方法相比，[主备用方法还有额外的权衡取舍](https://aws.amazon.com/rds/features/multi-az/)。这是因为对于主动-主动架构，必须重写工作负载，以处理到区域的智能路由、建立会话关联性、确保等效事务以及处理潜在的冲突。
大多数使用多区域方法实现弹性的工作负载不需要主动-主动方法。您可以使用[分片](https://aws.amazon.com/what-is/database-sharding/)策略通过限制减值对整个客户群的影响范围来提高弹性。如果您可以有效地对客户群进行分片，则可以为每个分片选择不同的主区域。例如，您可以对客户端进行分片，使一半的客户端与区域一对齐，一半的客户端与区域二对齐。通过将区域视为单元，您可以创建多区域单元方法，从而缩小工作负载的影响范围。有关更多信息，请参阅有关此方法的 [AWS re: Invent 演示文稿](https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Reducing_blast_radius_with_cell-based_architectures_ARC411-R1.pdf)。
您可以将分片方法与主备用方法相结合，为分片提供故障转移功能。您需要为工作负载设计经过测试的故障转移过程和数据协调流程，以确保故障转移后数据存储的事务一致性。本指南稍后将详细介绍这些内容。
## 关键指导
+ 出现故障时，待复制的写入操作很可能不会提交到备用区域。在恢复复制之前，数据将不可用（假设异步复制）。
+ 作为故障转移的一部分，需要一个数据协调过程来确保使用异步复制的数据存储保持事务一致的状态。这需要特定的业务逻辑，而不是由数据存储本身处理的事情。
+ 当需要强一致性时，需要修改工作负载，以容忍同步复制的数据存储所需的延迟。