我正在寻找创build一个多地理基础设施。 基本上，我需要为美国，欧盟和非盟用户提供一个网站。
挑战是这个网站本质上是电子商务，所以需要读取和写入数据库。
据我所知，有很多select：
在中央数据中心（可能是欧盟）有一个RDS实例（多个AZ）。 在每个领土有多个EC2，连接到RDS。
在每个领土有一个完整的环境（独立的RDS和EC2，不以任何方式与其他人连接）。 生活在用户不能共享login/数据跨地区的事实。
EC2在每个领域运行MySQL。 在应用程序层中构build一些东西，以便在写入时处理数据库之间的同步。
拥有容纳所有数据的中央RDS。 在每个领土上都有RDS实例，其中包含所有只读数据（主要是产品数据）。 在应用程序层中构build一些东西，以便产品特定的查询在本地数据库中进行，但写入发生在中央RDS实例中。
目前的select＃1似乎是最明智的，但我不确定数据中心之间的实际延迟，我无法find任何可靠的信息。
第2号是限制，但可能性。
第3号充满了同步不能按预期工作的潜在问题。
第4号是可能的，但将需要大量的应用层重构，这本身可能导致问题。
这里最好的办法是什么？ 我是否缺less选项？ 数据中心之间的延迟是否可以接受？
选项
选项2在单个URL上不可靠，因为它依赖于地理定位。 一段时间以后，地理位置将无法可靠地为给定的用户select相同的服务器。 为此，您需要为每个地区使用不同的url。
您错过了一些选项：
期权分析
我总是会select最简单的选项，在这种情况下，EC2和RDS位于同一位置，使用CDN来提高性能。 你没有说过为什么你认为你需要在不同地区使用多个应用程序服务器，所以我很困惑你为什么直接跳到相对复杂的选项。
如果单个位置不符合性能需求，则可以考虑将应用程序服务器放在每个区域中的单个RDS数据库中。 这可能会更快，这取决于您的应用程序的行为。 你必须进行基准testing。
只有这样我才会考虑多个数据库的额外复杂性。
只读副本
如果你对应用程序有控制权，那么我就可以build立不同的数据库URLS来从头开始读和写。 这可以让你稍后移动到阅读副本，如果你需要。