我有一个桌面应用程序，任何表格更改都应该通知该应用程序。因此，我只找到了两个非常适合我的情况的解决方案:SqlDependency 和 SQLCLR。 (我想知道 .NET 堆栈中是否有更好的)我已经构建了这两个结构并使它们工作。我只能比较从 SQL Server 到客户端的 s̲i̲n̲gl̲e̲ 响应的持续时间。
Sql依赖
持续时间:从 100 毫秒到 4 秒
SQLCLR
持续时间:从 10 毫秒到 150 毫秒
我希望这个结构能够处理高速率通知*，我已经阅读了一些 SO 和博客文章(例如: here )，并且还收到同事的警告，在大量请求时 SqlDependency 可能会出错。 Here ，MS 提供了一些我没有得到的东西，这可能是我的问题的另一种解决方案。
*:不是一直，而是一个季节； 1-2 台服务器上每秒 50-200 个请求。
在高通知率和性能并行的基础上，我应该选择这两者中的哪一个，或者还有其他选择吗？
最佳答案
SqlDependency(即查询通知)和 SQLCLR(即通过触发器调用 Web 服务)都不适用于该流量(每秒 50-200 个请求)。事实上，在这些数量下，这两种选择都非常危险。
两个链接页面(SoftwareEngineering.StackExchange.com 上的页面和 TechNet 文章)中给出的建议都是更好的选择。关于Best way to get push notifications to server from ms sql database的建议(即每隔几秒轮询一次的自定义队列表)与Planning for Notifications的选项#1非常相似。 TechNet 文章(使用 Service Broker 来处理队列的处理)。
我最喜欢排队的想法(完全自定义或使用 Service Broker)，并且在高度事务性系统(很容易达到您预期的数量)上使用完全自定义队列并取得了巨大成功。这两个选项之间的优缺点(当然，据我所知)是:
- 服务经纪人
- 优点:现有(且经过验证的)框架(可以扩展并绑定(bind)到事务中)
- 缺点:配置或管理/调试并不总是那么容易，无法轻松地将 1 秒内的 200 个单独事件聚合为一条消息(每个触发事件仍为 1 条消息)
- 完全自定义队列
- Pro:可以将许多同时触发事件聚合为发送给客户端的单个“消息”(即轮询服务拾取自上次轮询以来发生的任何更改)，可以利用更改跟踪/更改数据捕获作为“更改内容”的来源因此您可能不需要构建队列表。
- 缺点:只有您能够实现的可扩展性(可能与 Service Broker 一样好或更好，但高度依赖于您的技能和经验来实现这一点)，需要对边缘情况进行彻底的测试才能使确保队列处理不会错过或重复计算事件。
您也许可以将 Service Broker 与更改跟踪/更改检测结合起来。如果有一种足够简单的方法来确定最后处理的更改(更改跟踪/更改数据捕获表中注明的更改)，那么您可以设置一个 SQL Server 代理作业每隔几秒轮询一次，并且如果您发现有新的更改出现，然后将所有这些更改捕获到一条消息中发送到 Service Broker。
一些帮助您入门的文档:
- Track Data Changes (涵盖变更跟踪和变更数据捕获)
- SQL Server Service Broker
关于sql-server - SqlDependency 与 SQLCLR 对 WebService 的调用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44367913/