复制vs Sync Framework与Service Broker

Question

我已经分别询问过这些技术，但实际上还没有找到合适的答案。

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

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

我们尝试了一段时间的事务复制，虽然它在某些时候有效，但它对我们来说维护得太高了，它似乎经常随机错误而没有可能的解释，迫使我们重新初始化订阅（这可能需要超过4个小时，假设该位置将保持连接足够长的时间，以便一次性完成整个快照）。我们已经从头开始研究自己的解决方案，但鉴于我们需要的规模和可靠性，我认为这不是最好的想法。

到目前为止，我们还查看了Sync Framework，并且正如其他人所建议的那样，Service Broker。 Sync Framework似乎更合适，但我被告知Service Broker更好地扩展并且更可靠？我找不到任何关于Sync Framework或Service Broker所涉及的开销的经验数据，因此在这方面无法比较这两者。

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

这个问题有很多可能的解决方案，所有这些都涉及完全不同的技术，我需要对此有新的认识。

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

编辑：显然，升级到SQL Server 2008可以轻松解决这个问题。但是，我们首先想尝试更便宜的选择。

Answer 1

我没有提供任何硬数据，但我们不久前在项目中使用了同步框架。我的经历非常糟糕。它很慢（即使在通过LAN同步相对较小的表时），规模非常大，并且需要大量工作来手动处理错误条件（它会很快产生比WCF默认处理的更大的数据包 - 并且只能分割更新在同步一个方式而不是另一个方式时批量生成。）它只适用于一些选择的数据库（客户端必须使用MS SQL Compact Edition，我记得），除非你愿意编写自己的SyncAdapter。

总的来说，很多工作只是为了解决问题的脆弱和低效的解决方案。我不推荐它。

Answer 2

您可以在一端使用带有SQL Express 2008 R1 / R2的同步框架，在中央端使用多租户db SQl服务器企业。下面是通过安全WCF通道进行n层同步的示例应用程序。您可以编写Windows服务来同步来自后端的数据：

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

它足以处理大量客户（数千）。

Answer 3

我想我们会研究SQL Server 2008的升级路径。看起来本机更改跟踪支持将是实现此目的的最简单方法。