SqlDependency 与 SQLCLR 调用 WebService

Question

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

SqlDependency

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

SQLCLR

持续时间：从 10 毫秒到 150 毫秒

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

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

在高通知率和性能并行的基础上，我应该继续使用这两者中的哪一个，或者还有其他选择吗？

Answer 1

SqlDependency（即查询通知）和 SQLCLR（即通过触发器调用 Web 服务）都不适用于该流量（每秒 50-200 个请求）。事实上，这两种选择都非常危险。

在两个链接页面（SoftwareEngineering.StackExchange.com 和 TechNet 文章）中给出的建议都是更好的选择。关于Best way to get push notifications to server from ms sql database（即每隔几秒轮询一次的自定义队列表）的建议与Planning for Notifications TechNet 文章（使用 Service Broker 处理队列）的选项 #1 非常相似。

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

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

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

一些帮助您入门的文档：

• Track Data Changes（涵盖变更跟踪和变更数据捕获）
• SQL Server Service Broker