复制vs同步框架vs Service Broker

Question

我已经分别询问了每一种技术，但真的没有找到合适的答案。

我们的中心办公室中有一台运行SQL server 2005 Enterprise的服务器，该服务器有几个大型( DSL是限制因素的意义上的大型)数据库，我们在每个位置都需要它们的本地副本。我们目前只有几十个网点，还需要更多的网点。在未来两年内，我们需要将这些数据库同步到的位置总数将达到数百个。

我们正在尝试解决每个位置的WAN连接问题。这些都是DSL线路，这些位置的布线并不总是最好的。我们目前遇到了一些问题，一些位置甚至每小时都会出现故障。虽然我们正在努力通过重新布线和当地电信公司的帮助来解决这些问题，但它主要突出了手头的问题:我们需要一个可以处理偶尔连接的双向同步。

我们尝试了一段时间的事务性复制，虽然它有时会起作用，但对我们来说维护太高了，而且它似乎经常随机出错，没有任何可能的解释，迫使我们重新初始化订阅(假设位置保持连接的时间足够长，可以一次性获得整个快照，这可能需要4个小时以上)。我们已经考虑过从头开始推出我们自己的解决方案，但考虑到我们需要的规模和可靠性，我认为这不是最好的想法。

到目前为止，我们还了解了同步框架，以及其他人所建议的Service Broker。同步框架似乎更适合，但有人告诉我，Service Broker可伸缩性更好，更可靠？我找不到任何有关Sync Framework或Service Broker开销的经验数据，因此在这方面无法将两者进行比较。

我们真正需要的是中心局服务器和远程客户端之间的双向同步，该客户端可以自主运行，并可以在发生需要我们干预的故障时向管理员报告。

这个问题有很多可能的解决方案，都涉及到完全不同的技术，所以我需要一个新的视角来看待这个问题。

您认为对我们的情况最好的解决方案是什么?为什么？

编辑:显然，升级到SQL Server 2008可以很容易地解决这个问题。但是，我们希望先尝试价格较低的选项。

Answer 1

我认为我们将研究一下SQL Server 2008的升级路线。似乎原生的更改跟踪支持将是实现这一点的最简单的方法。

Answer 2

在这方面我没有任何确切的数据可以提供，但我们在不久前的一个项目中使用了sync框架。我对它的体验真的很糟糕。它很慢(即使在LAN上同步相对较小的表时也是如此)，伸缩性很差，需要大量的工作来手动处理错误条件(它很乐意生成比WCF缺省情况下可以处理的包更大的包--并且只能在以一种方式同步时才能将更新分成批处理，而不能以另一种方式同步。)而且它只适用于少数精选的数据库(我记得客户机必须使用must Edition )，除非您愿意编写自己的SyncAdapter。

总的来说，很多工作只是为了给你的问题找到一个脆弱而低效的解决方案。我不建议你这么做。

Answer 3

您可以在一端将同步框架与SQL express 2008 R1/R2一起使用，将多租户数据库SQl服务器企业版与中央端一起使用。下面是用于通过安全WCF的n层同步的示例应用程序channel.You可以写入windows服务以从后端同步数据：

http://www.rajneeshnoonia.com/blog/2012/03/n-tier-sync-framework/

它应该有足够的能力处理大量的客户端(数千个)。