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