多区域基础知识 2：了解数据

对于多区域架构来说，管理数据是一个不容忽视的问题。区域之间的地理距离会带来不可避免的延迟，这种延迟表现为跨区域复制数据所花费的时间。在可用性、数据一致性以及向使用多区域架构的工作负载引入更高数量级的延迟之间进行权衡是必要的。无论使用异步复制还是同步复制，您都需要修改应用程序以应对复制技术带来的行为变化。由于数据一致性和延迟方面的挑战，要采用专为单区域设计的现有应用程序并使其成为多区域非常困难。了解特定工作负载的数据一致性要求和数据访问模式对于权衡利弊至关重要。

2a：了解数据一致性要求

CAP 定理为推理数据一致性、可用性和网络分区之间的权衡提供了参考，对于工作负载，其中只有两个分区可以同时满足。根据定义，多区域包括区域之间的网络分区，因此您必须在可用性和一致性之间做出选择。

如果您选择跨区域的数据可用性，则在事务写入期间不会出现明显的延迟，因为在复制完成之前，需要对已提交的数据进行异步复制，从而降低各区域之间的一致性。对于异步复制，当主区域出现故障时，很有可能出现待从主区域复制的写入操作。这会导致一种情况，即在恢复复制之前，最新数据不可用，并且需要对账流程来处理未从经历中断的地区复制的正在进行的交易。

对于偏爱异步复制的工作负载，您可以使用提供异步跨区域复制的 Amazon Aurora 和 Amaz on DynamoDB 等服务。亚马逊 Aurora 全球数据库和亚马逊 DynamoDB 全局表都有默认的 CloudWatch亚马逊指标，以帮助监控复制延迟。

设计工作负载以利用事件驱动架构对多区域策略来说是一个好处，因为这意味着工作负载可以包括数据的异步复制，并通过重播事件来实现状态重建。由于流媒体和消息服务在单个区域中缓冲消息有效载荷数据，因此区域故障转移/故障恢复流程必须包括一种机制，用于重定向客户端输入数据流，以及协调存储在经历中断的区域中的传输中和/或未交付的有效负载。

如果选择一致性，则由于在事务写入期间同步复制数据，将导致延迟很长。同步写入多个区域时，如果所有区域的写入操作均未成功，则可用性可能会降低，因为事务不会提交，需要重试。尝试同步向所有区域写入数据的重试将以每次尝试的延迟为代价。在某个时候，当重试次数用尽时，需要做出决定，要么使事务完全失败，从而降低可用性，要么仅将事务提交到可用区域，从而导致不一致。有些法定人数形成技术，例如 Paxos，可以帮助同步复制和提交数据，但需要开发人员的大量投资。

当写入涉及跨多个区域的同步复制以满足严格的一致性要求时，写入延迟会增加一个数量级。如果不进行重大更改，通常无法将较高的写入延迟改装到应用程序中。理想情况下，在首次设计应用程序时必须将其考虑在内。对于优先考虑同步复制的多区域工作负载，AWS合作伙伴解决方案可以提供帮助。

2b：了解数据访问模式

工作负载数据访问模式分为以下类型之一：读取密集型或写入密集型。了解特定工作负载的这一特性将指导选择合适的多区域架构。

对于读取密集型工作负载，例如完全只读的静态内容，可以在不显著复杂的情况下实现主动/主动多区域架构。使用内容分发网络 (CDN) 在边缘提供静态内容，通过缓存离最终用户最近的内容来确保可用性；在 Amazon 中使用诸如 Origin 故障转移之类的功能集 CloudFront可以帮助实现这一目标。另一种选择是在多个区域部署无状态计算，并使用 DNS 将用户路由到最近的区域以读取内容。可以使用@@ 带有地理定位路由策略的 Route 53 来实现这一目标。

对于读取比例大于写入百分比的读取密集型工作负载，可以使用本地读取、写入全局策略。这需要将所有写入操作都发送到特定区域的数据库，同时将数据异步复制到所有其他区域，并且可以在任何区域进行读取以实现此目的。这种方法需要工作负载才能实现最终一致性，因为跨区域写入复制的延迟会增加，因此本地读取可能会过时。

Aurora Global Databas e 可以帮助在只能在本地处理所有读取流量的备用区域中配置只读副本，并在特定区域配置单个主数据存储以处理写入。数据从主数据库异步复制到备用数据库（只读副本），如果您需要将操作故障转移到备用区域，则可以将备用数据库提升为主数据库。如果工作负载更适合非关系数据模型，则也可以在这种方法中使用 DynamoDB。同样，工作负载需要包含最终的一致性，如果不是从一开始就为此而设计的，则可能需要对其进行重写。

对于写入密集型工作负载，应选择主区域，并在工作负载中设计故障转移到备用区域的功能。与主动/主动方法相比，主/备用方法不那么复杂。这是因为对于主动/主动架构，需要重写工作负载，以处理到区域的智能路由、建立会话关联性、确保等效事务以及处理潜在的冲突。

大多数考虑多区域恢复能力的工作负载不需要主动/主动方法。分片策略可用于通过限制整个客户群中损伤的爆炸半径来提高弹性。如果您可以有效地对客户群进行分片，则可以为每个分片选择不同的主区域。例如，如果您可以对客户端进行分片，使一半的客户端与区域一对齐，一半的客户端与区域二对齐，将区域视为单元，则可以创建多区域单元方法，从而缩小工作负载的冲击半径。

分片方法可以与主/备用方法相结合，为分片提供故障转移功能。需要在工作负载中设计经过测试的故障转移流程，还需要设计数据协调流程，以确保故障转移后数据存储的事务一致性。这些 paper 稍后将详细介绍。

关键指导

• 出现故障时，待复制的写入操作很可能不会提交到备用区域。在恢复复制之前，数据将不可用（假设异步复制）。

• 作为故障转移的一部分，需要一个数据协调过程，以确保使用异步复制的数据存储保持事务一致的状态。

• 当需要强一致性时，需要修改工作负载以容忍同步复制的数据存储所需的延迟。