最佳实践 Azure 数据库扩展

Question

我有一个在天蓝色云中运行的 Web 应用程序。目前我们只使用区域“西欧”，但我们现在也将美国添加为区域。

现在我正在考虑数据库... 目前我在西欧地区拥有 Azure SQL 数据库。 它是一个非常小的数据库，不包含大量数据。里面大多只有关系、用户数据和其他类似的东西。

那么现在将其扩展到多个区域的最佳做法是什么？

我认为我有以下选择：

• 将数据库留在该区域并从其他区域连接到同一个数据库（这里我主要担心延迟问题）
• 为每个区域创建一个数据库并使用数据库同步

关于数据库同步，我找不到可以解释在以下情况下会发生什么的答案：

初始状态（两者都是同步的）：

区域 A，表 A

标识值

1“测试”

2“测试2”

3“测试3”

区域 B，表 A

标识值

1“测试”

2“测试2”

3“测试3”

现在两个数据库中都添加了数据：

区域 A，表 A

标识值

1“测试”

2“测试2”

3“测试3”

4“test4”

5“测试5”

区域 B，表 A

标识值

1“测试”

2“测试2”

3“测试3”

4“测试6”

5“测试7”

在文档中，他们总是谈论如果行已更新，则特定规则“中心获胜”或“客户端获胜”适用。但是在添加行的情况下会发生什么？ 我相信同步后的最终结果将是（如果选择了 hub 获胜并且 Hub 是 Region A 中的数据库）：

4“test4”

5“测试5”

因此区域 B 中的所有更改都将被忽略。那正确吗？ 此表中的 PK 为整数。如果 PK 我猜是 Guid，也许这个问题可以解决......

我目前不确定，扩展数据库的最佳方式是什么。我希望有人能给我一个提示。 是否有人已经体验过跨多个区域的 Azure 网络内部的延迟情况？

感谢您的帮助！

Answer 1

您在双向 Azure DB 同步上是正确的 - 在您的情况下，同步后，区域 B 将根据冲突解决设置更新为与区域 A 相同。

要在允许主动-主动的同时横向扩展您的应用，您需要确保 PK 在每个地区都是唯一的，例如使用 GUID 或分区良好。如果您的应用程序是读取密集型的，另一种选择是将所有写入操作重定向到单个“主”数据库，然后将更改推送到其他只读区域；它可以避免冲突，但需要更改应用程序逻辑。

（顺便说一句，请注意，Azure 数据同步是最终一致性而不是事务一致性，它是计划的而不是连续的。您最好评估一下您的应用是否可以容忍这些。）

关于跨区域的网络延迟，有一个 3rd 方站点 azurespeed.com 具有很好的可视化效果，可能会有所帮助，但不是专门针对 Azure DB。