设计地理分散式数据体系结构
应用程序体系结构设计要考虑的最后一部分是数据存储层。 我们想要确保在发生区域范围的故障后，数据具有完整功能，能够读取、写入。
在货运跟踪门户中，我们选择使用 Azure Front Door 将所有请求发送到美国东部区域的应用程序服务。 如果美国东部区域发生故障，Front Door 会检测到该故障，并将请求发送到美国西部区域的应用程序服务组件副本。 在原有的单区域体系结构中，我们在 Azure SQL 数据库中存储关系数据，在 Cosmos DB 中存储半结构化数据。 现在，我们想要了解在美国东部区域发生故障时，如何确保两个数据库都保持可用。
在这里，我们将了解如何在区域之间复制数据，以及如何确保在必要时可以快速进行故障转移。
Azure SQL 数据库
若要创建 Azure SQL 数据库的多区域实现以存储关系数据，可以使用以下方法之一：
- 活动异地复制
- 自动故障转移组
活动异地复制
Azure SQL 数据库可以使用活动异地复制功能，将数据库及其所有更改从一个数据库自动复制到另一个。 只有主逻辑服务器托管数据库的可写副本。 可以创建最多 4 个托管数据库只读副本的其他逻辑服务器。
对于货运跟踪门户，请在美国西部区域创建辅助数据库，并配置从美国东部区域的异地复制。 发生区域故障时，Front Door 会将用户请求重定向到美国西部区域的应用程序服务。 应用程序服务和 Azure Functions 可以访问关系数据，因为已将副本复制到美国西部区域。
此更改自动进行，但请记住，美国西部的辅助数据库是只读的。 如果用户尝试修改数据（例如创建新的条目），则可能会出现错误。 发现 Azure 门户中的这一问题后，可以手动启动到美国西部的故障转移。 若要自动执行此过程，开发人员可以编写代码，调用 Azure SQL 数据库 REST API 中的 failover 方法。
注意
Azure SQL Database 的托管实例不支持活动异地复制。 托管实例旨在简化从本地 SQL Server 迁移数据的过程，同时保持安全性。 如果使用托管实例，请考虑改用故障转移组。
自动故障转移组
自动故障转移组是一组数据库，其中的数据会从主服务器自动复制到一个或多个辅助服务器。 此设计类似于活动异地复制，并使用相同的数据复制方法。 但是，可通过定义策略来自动响应故障。
对于货运门户，我们将在美国西部区域创建辅助数据库。 接下来，我们将添加一个策略，如果在美国东部区域发生灾难性故障，该策略会将数据库的主要副本故障转移到美国西部。 如果发生这种情况，美国西部副本将自动成为可写的主数据库，并保持完整功能。
如果希望自动执行可写数据库的故障转移而无需编写自定义代码来触发它，请考虑使用自动故障转移组。 此外，如果数据库在 Azure SQL 数据库的托管实例中运行，请使用自动故障转移组。
重要
在活动异地复制和自动故障转移组背后，复制都是异步的。 将更改应用于主要副本时，会向客户端发送确认。 此时，将认为该事务已完成，并进行复制。 发生故障时，主数据库中的最新更改可能尚未复制到辅助数据库。 请记住，在发生灾难后，最新的数据库更改可能已丢失。
Azure Cosmos DB
我们使用 Azure Cosmos DB，配置没有那么复杂，这是因为 Cosmos DB 是作为多区域云数据库系统设计的。 Cosmos DB 是多模型数据库，它能够存储关系数据、半结构化数据和其他格式的数据。 即使在单个区域中运行 Cosmos DB，也会将数据复制到跨容错域的多个实例中，以便最大限度地提高可用性。
创建多区域 Cosmos DB 帐户时，可以从以下模式中进行选择：
具有多个写入区域的多区域帐户。
在此模式下，数据库的所有副本始终是可写的。 如果某个区域发生故障，无需进行故障转移。
具有单个写入区域的多区域帐户。
在此模式下，只有主要区域包含可写数据库。 复制到次要区域的数据是只读的。 如果主要区域发生故障，将默认禁用更新。 但是，可以选择“启用自动故障转移”，以便 Cosmos DB 自动将数据库的主要、可写副本故障转移到另一个区域。
重要
在 Cosmos DB 中，数据复制是同步的。 应用更改后，只有将事务复制到规定的副本后，才认为事务已完成。 然后，将向客户端发送确认。 发生故障时，不会丢失最近的更改，因为已进行了复制。