Sql Service Broker、CLR 集成、触发后端问题答案

【问题标题】：Sql Service Broker, CLR Intergration, Triggers back end problemSql Service Broker、CLR 集成、触发后端问题
【发布时间】：2011-06-30 03:24:09
【问题描述】：

我正在寻找构建用于存储/处理数据的后端的最有效方法。基本上，数据被发送到服务器，解析然后保存到数据库。然后根据数据库中的其他数据对其进行一些处理，然后通过电子邮件或短信发出警报。

平台是 .NET，数据库是 SQL Server 2005 或 2008。

即

温度传感器向服务器发送 4 个字节的数据。
服务器将数据转换为实际值，例如 20。
然后将值保存到 SQL 服务器数据库。
然后根据表中为该传感器设置边界的行检查该值，即 0-50
如果超出范围，则会引发警报。（通过短信或电子邮件发送。）

这一切看起来都很简单，但我正在寻找最好的方法，因为理想的情况是这一切都是“实时”发生的，并且每秒可能有 100 或 1000 个请求。我想利用 SQL 2005/08 的一些“新”功能，例如 Service Broker、CLR 集成、触发器等，我对此几乎没有经验。

步骤 1 和 2 已经完成。

考虑到排队的事务数量，使用服务代理或 MSMQ 是否明智？鉴于我需要查找边界数据，我应该在什么时候处理警报数据？我有一些想法，我希望如何处理数据，但不确定要使用的最佳技术/方法。

我的想法是（从第 3 步开始）是将数据提交给服务代理，后者又调用 CLR 过程来处理数据上的“业务逻辑”。或者我是否使用触发器将数据添加到服务代理以处理数据？服务代理可以直接调用 CLR 过程吗？考虑到我希望以事件驱动而非轮询的方式处理数据，使用服务代理是否是正确的想法？

从我在 Service Broker 上看到的示例来看，您似乎需要有代码来接收数据，而我真正想做的只是将数据添加到队列中并自动清空队列（处理提醒数据）。

我可以通过标准存储过程完成所有这些操作，但我希望尽可能少地使用存储过程，而是使用 CLR 集成，因为业务逻辑将比示例中复杂得多。

鉴于服务代理处理队列和线程，我认为它可能是调用 CLR 过程来处理警报数据并发送短信或电子邮件的理想选择？

请给我亮光！谢谢！

【问题讨论】：

标签： sql sql-server database service-broker clrstoredprocedure

【解决方案1】：

dportas 和 SPE109 提供了很好的建议，如果功能齐全的事件监控解决方案对您来说是可行的。

不过，我可以回答您提出的有关 Service Broker 的具体问题：

Service Broker 可以处理您指定的数据速率。 Remus Rusanu 是 Microsoft Service Broker 背后的主要人员之一，他使用廉价的商品硬件实现了每秒远远超过 1000 个事件的消息吞吐量。
您是使用批处理流程提交到 Service Broker 还是使用触发器在很大程度上取决于您的偏好以及它如何适合您的工作流程。任何一种方法都可以。
如果您使用 Service Broker，您可以使用内部激活过程（标准 SQL 存储过程）或外部激活器（单独的过程）。我没有外部激活的经验，但是对于内部激活，您必须编写一个 SQL 过程，当消息进入给定队列时，Service Broker 将调用该过程。该过程可以调用 CLR 过程来对收到的消息数据执行操作。

一个更基本的问题是：Service Broker 为您提供了哪些“标准”方法（将数据保存到数据库，然后每秒轮询一次并对传入的事件进行批处理）没有提供的功能？

当您需要消息持久性和排序、在 SQL Server 实例之间进行通信时，或者当您可以利用其机制为您完成大部分工作时，Service Broker 非常棒。在这种情况下，鉴于您的问题陈述，听起来持久性和排序并不特别重要。您希望密切关注数据并在违反边界条件时发出警报。除非对消息的处理顺序有依赖性，否则我认为轮询批处理可以更简单地完成工作，并且没有 Service Broker 的设置开销。

【讨论】：

该问题并未说明是否需要消息持久性、排序和服务器间通信。 @Matt如果服务器不可用，消息丢失是否重要？如果是这样，您需要消息持久性。如果您在 5 分钟前收到一堆 10 分钟前的消息，这是一个问题吗？如果是这样，您需要订购。您是否打算在多个 SQL 服务器上执行此操作？如果是这样，服务器间通信可能会很有用。
嗨。好点。我不得不考虑这些问题。是的，如果消息丢失确实很重要，但我认为我已经从源头解决了这个问题。即在我的示例中，传感器数据来自已保存在 FIFO 中的数据记录器中的记录。如果记录没有送达，则不会从 FIFO 中删除并稍后重新发送。在这个阶段，我认为排序并不重要，因为有效负载将具有“创建记录”的日期戳。我会说一开始可能是一台服务器，但随着项目规模的增加，未来肯定会更多。

【解决方案2】：

看看复杂事件处理解决方案领域。有来自 OsiSoft（PI 系统）、Streambase、Oracle 等的领先产品。 Microsoft 拥有 Streaminsight，尽管这是第一代产品，不保证交付或支持持久性。

【讨论】：

【解决方案3】：

听起来您可能想看看 Streaminsight http://www.microsoft.com/sqlserver/2008/en/us/r2-complex-event.aspx。我不能说我对此了解太多，但如果你用谷歌搜索 Allan Mitchell 和 Streaminsight 或查看 SQLIS.com，他已经使用它制作了许多演示视频。

【讨论】：