SqlDependency vs SQLCLR调用WebService

Question

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

的SqlDependency

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

SQLCLR

持续时间：从10ms到150ms

我希望这个结构能够处理高速率通知*，我已经阅读了一些SO和博客帖子（例如：here），并且还向同事发出警告，即群发请求SqlDependency可能出问题。 Here，MS提供了一些我没有得到的东西，这可能是我问题的另一种解决方案。

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

基于高通知率并与表现并行，我应该继续使用这两个中的哪一个，还是有其他选择？

Answer 1

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

两个链接页面（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），并且在高度事务性系统上使用完全自定义队列（很容易就是您期望的卷）并取得了很大的成功。这两个选项之间的利弊（当然，正如我所看到的那样）是：

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

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

一些文档可以帮助您入门：

• Track Data Changes（包括更改跟踪和更改数据捕获）
• SQL Server Service Broker