我只是在研究如何在Azure上构建一个大规模的、全局可访问的应用程序。
已经有很多技术可以让你的应用程序尽可能接近消费者。
- CDN边缘服务器，用于在世界各地共享静态内容
- 不同地区的云服务，使用Traffic Manager将域名路由到最近的应用程序主机
我有点困惑的是数据库。如果你正在使用SQL Azure，你必须指定一个区域来放置它。如果我的SQL Azure实例在西欧（阿姆斯特丹），但我的客户在澳大利亚，并且通过澳大利亚（新南威尔士州）的实例访问应用程序，则应用程序与数据库之间会有一些延迟。
我看到的所有关于地理复制的参考资料似乎都是在主从冗余设置的背景下。但我想知道，在同一地理区域中，每个应用程序实例都与自己的SQL Azure主实例进行对话，然后SQL Azure负责它们之间的双向复制，这样设置Master Master是否可行。
Azure SQL数据库的主动地理复制：
Active Geo Replication功能实现了一种机制，用于在同一Microsoft Azure区域或不同区域中提供数据库冗余（地理冗余）。Active Geo Replication异步将已提交的事务从数据库复制到不同服务器上数据库的最多四个副本。原始数据库将成为连续副本的主数据库。每个连续副本都称为活动辅助数据库。主数据库将提交的事务异步复制到每个活动的辅助数据库。虽然在任何给定的点上，活动的辅助数据可能略落后于主数据库，但活动的辅助数据库保证始终与提交到主数据库的更改在事务上一致。Active Geo Replication最多支持四个活动辅助，或最多支持三个活动辅助和一个脱机辅助。
Active Geo Replication的主要好处之一是它提供了数据库级别的灾难恢复解决方案。使用Active Geo Replication，您可以在高级服务层中配置用户数据库，以将事务复制到相同或不同区域内不同Microsoft Azure SQL数据库服务器上的数据库。跨区域冗余使应用程序能够从自然灾害、灾难性人为错误或恶意行为导致的数据中心永久性丢失中恢复。
另一个关键好处是活动的辅助数据库可读。因此，活动辅助可以充当读取工作负载（如报告）的负载平衡器。虽然您可以在不同的区域中创建活动辅助以进行灾难恢复，但也可以在不同服务器上的同一区域中创建一个活动辅助。两个活动辅助数据库都可以用于平衡为分布在多个区域的客户端提供服务的只读工作负载。
请注意，大师并没有被提及。复制副本可读，从不可写。因此，这个问题实际上是没有意义的，因为SQLAzure根本不支持您所希望的。
另一种选择是应用层分片，让每个租户连接到一个邻近数据库，但这假设数据是不相交的（澳大利亚客户不会查看南美商品）。请在此处查看此答案。
你也可以研究像Cassandra这样的东西，它确实支持你想要的东西，但这是一个重大的范式转变，你需要托管和管理它
但您也要问：是否需要master master数据库来实现低延迟？写入是否经常出现在您的应用程序中？读取延迟可以很容易地得到改善，这就是为什么您有用于的缓存和CDN。想想所有澳大利亚用户阅读这个问题。从用于灾难恢复的地理复制数据库提供服务，而不是从主数据库提供服务。请参阅StackOverflow如何扩展SQL Server。
注意：我没有在这方面使用过SQL Azure，但我已经广泛地使用了地理复制。
根据我可以告诉你的，Azure内置的Active Geo Replication是一个单向副本，这是正确的——你在一个位置有一个主数据库，它将事务共享到其他只读数据库。
要获得完整性，双向复制是一项非常棘手的任务。失败条件的机会是巨大的，而且极难测试。这就是为什么很难找到很多人提供事务数据库的双向复制——即使你的数据库中有相同的数据，他们也会有不同的事务历史记录，并且不会准确地相互镜像。然后，当您必须决定哪个数据库是权威数据库时，事情会很快变得复杂起来。
但是，这并不一定妨碍我们实现实用的双向复制。当您了解自己的数据并了解哪些需要复制，哪些不需要复制时，您就不再需要将复制作为一个抽象问题来解决，因此您可以围绕现有数据进行设计。如果你正在考虑以这种规模工作，你将使用大量的队列来传递数据。举一个非常简单的例子，如果您的服务将数据推入队列，以便数据库能够提取数据，然后将其弹出存储，那么在将数据放入数据库的处理过程中，将相同的数据推入传输队列到其他地理区域并不难。
最终，你需要问问自己，你有多少百万用户，他们将向你的数据库中推送多少GB的数据。如果这些数字相当低，那么双向复制几乎肯定是不必要的，而且考虑太多可能是过早的优化。