我想要创建一个跨地域的基础设施。本质上，我需要为美国、欧盟和澳大利亚用户提供网站服务。
挑战在于该网站本质上是电子商务网站，因此需要对数据库具有读写权限。
据我所知，有多种选择：
在中央数据中心（可能是欧盟）拥有单个 RDS 实例（多可用区）。在每个地区拥有多个连接到 RDS 的 EC2。
在每个地区都有完整的环境（单独的 RDS 和 EC2，不以任何方式连接到其他环境）。接受用户无法跨地区共享登录/数据的事实。
在每个地区都有运行 MySQL 的 EC2。在应用程序层构建一些东西来处理写入时数据库之间的同步。
拥有一个存放所有数据的中央 RDS。在每个区域都有存放所有只读数据（主要是产品数据）的子 RDS 实例。在应用程序层中构建一些内容，以便特定于产品的查询发生在本地数据库中，但写入发生在中央 RDS 实例中。
目前，选项 1 似乎是最合理的，但我不确定数据中心之间的实际延迟，并且无法获得任何可靠的信息。
2 号有限制，但是有可能。
3 号充满了潜在问题，同步无法按预期进行。
方案 4 是可行的，但需要对应用层进行大量重构，而这本身可能会导致问题。
这里最好的方法是什么？我是否缺少选项？数据中心之间的延迟是否“可以接受”？
答案1
选项
选项 2 无法通过单个 URL 实现可靠性，因为它依赖于地理位置。地理位置无法随着时间的推移为给定用户可靠地选择同一服务器。为此，您需要为每个区域设置不同的 URL。
您错过了许多选项：
- 使用中央 RDS 实例进行写入，并在每个区域使用读取副本。
- 使用 MySQL 内置复制，而不是 AWS 功能。我不知道您是否可以使用 RDS 执行此操作 - 我怀疑您必须在 EC2 上运行 MySQL。这与 #4 类似，但不完全相同。
- 拥有单个 EC2 实例/集群和 RDS 实例。使用 CloudFront 等内容分发加速应用程序。
期权分析
我总是首先选择最简单的选项，在本例中，EC2 和 RDS 位于同一位置，使用 CDN 来提高性能。您还没有说明为什么需要在不同区域使用多个应用服务器，所以我很困惑为什么您直接跳到相对复杂的选项。
如果单个位置不能满足性能需求，您可以考虑在每个区域放置一个 RDS 数据库的应用服务器。这可能会更快，这取决于您的应用程序行为。您必须进行基准测试。
只有那时我才会考虑多个数据库的额外复杂性。
只读副本
如果您可以控制应用程序，我会从一开始就内置不同的数据库 URL 进行读取和写入的功能。这样，您可以在以后需要时转到读取副本。