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