SqlDependency 与 SQLCLR 调用 WebService

Question

我有一个桌面应用程序，应该在任何表更改时收到通知。因此，我只找到了两个非常适合我的情况的解决方案：SqlDependency和SQLCLR。（我想知道 .NET 堆栈中是否有更好的）我已经构建了两个结构并使它们工作。我只能比较从 SQL Server 到客户端的 s̲i̲n̲gl̲e̲ 响应的持续时间。

SqlDependency

持续时间：从 100 毫秒到 4 秒

SQLCLR

持续时间：从 10ms 到 150ms

我希望这个结构能够处理高速率通知*，我已经阅读了一些 SO 和博客文章（例如：here），并且我的同事也警告说，在大量请求时 SqlDependency 可能会出错。在这里，MS 提供了一些我没有得到的东西，这可能是我问题的另一种解决方案。

*：不是所有时间，而是一个季节；在 1-2 个服务器上每秒 50-200 个请求。

基于高通知率和性能，我应该继续使用这两个中的哪一个，还是有其他选择？

Answer 1

无论SqlDependency（即查询通知），也不SQLCLR（即调用通过触发一个Web服务）将要工作的流量该卷（每秒50-200 REQ）。事实上，在这些数量上，这两种选择都非常危险。

两个链接页面（SoftwareEngineering.StackExchange.com 上的页面和 TechNet 文章）中给出的建议都是更好的选择。关于从 ms sql 数据库（即每隔几秒轮询一次自定义队列表）向服务器获取推送通知的最佳方式的建议与计划通知TechNet 文章（使用 Service Broker 处理处理）的选项 #1 非常相似队列）。

我最喜欢排队的想法（完全自定义或使用 Service Broker），并且在高度事务性的系统（很容易达到您预期的数量）上使用完全自定义的队列并取得了很大的成功。这两个选项之间的优缺点（当然在我看来）是：

• 服务代理
  • 优点：现有（和经过验证的）框架（可以扩展并绑定到事务中）
  • 缺点：并不总是易于配置或管理/调试，不能轻松地在 1 秒内将 200 个单独的事件聚合成一条消息（每个 Trigger 事件仍然是 1 条消息）
• 完全自定义队列
  • 优点：可以将许多同时触发的事件聚合到客户端的单个“消息”中（即轮询服务接收自上次轮询以来发生的任何更改），可以利用更改跟踪/更改数据捕获作为“更改内容”的来源，因此您可以不需要建立队列表。
  • 缺点：只有您能够做到的可扩展性（可能与 Service Broker 一样好或更好，但高度依赖于您的技能和经验来实现这一点），需要对边缘情况进行彻底测试以确保队列处理不会错过或重复计算事件。

您可以将 Service Broker 与变更跟踪/变更检测结合起来。如果有足够简单的方法来确定处理的最后一次更改（更改跟踪/更改数据捕获表中所述的更改），那么您可以设置一个 SQL Server 代理作业以每隔几秒轮询一次，如果您发现有新的变化进来，然后将所有这些变化收集到一条消息中发送给 Service Broker。

一些帮助您入门的文档：

• 跟踪数据更改（涵盖更改跟踪和更改数据捕获）
• SQL Server 服务代理