WCF和套接字数据处理-异常数据通知模块（ASP.NET MVC 3和EF 4.0和LINQ和WCF 4.0和套接字和SQL Server 2008 R2和Azure） 业务场景：

假设存在构造。建筑可以是新的建筑物、桥梁等。 施工场地上可能发生各种物理和环境变化。 这些变化可能是例如温度的变化

我们为我们的客户构建了一个应用程序，该应用程序从施工场地收集不同类型的数据，稍后用于：

显示时间变化图表

为施工经理和其他决策者提供见解、警报和通知

当前状态： 应用程序已构建并运行

广告1——所有数据都是通过图表收集和可视化的

广告2-我们仍在扼杀该模块的正确设计

问题: 如何正确设计使用WCF服务和套接字收集数据的异常数据通知模块 过程

总体架构设计：

我们的拼图有4个主要部分：

后端数据库-SQL Server 2008（Azure SQL）

前端web应用程序-ASP.NET MVC 3（Azure的WebRole）

WCF 4.0服务，由向我们发送数据的ZigBee设备调用（Azure的WebRole）

使用套接字IP（WorkerRole for Azure）配置频率呼叫Rfid读卡器的Windows进程

在数据库中，我们有两个单独的Rfid读数表和ZigBee读数表。 为了提高性能，存储结果的表被故意取消规范化：通过多个索引进行更快的查询和分组。我们在前端应用程序中使用Entity Framework和Linq with Projection进行数据访问，效果良好

异常数据通知模块： 我们的通知模块功能要求如下：

发送短信和电子邮件通知特定客户 施工场地：

测量数据的值高于阈值x发生次数

参数有：最小值、最大值、阈值、重复计数、重复时间窗口、传感器类型

例如，我们为特定施工场地添加了通知/警报。此警报配置为：

• 最小值=-5
• 最大值=40
• 阈值=5
• 重复计数=5
• 重复时间窗口=5分钟
• 传感器类型=温度

所以现在当ZigBee WCF或Rfid Windows进程获取数据时，可以触发通知/警报。 例如：

• 日期：2012-08-19 10:00数值：30正常
• 日期：2012-08-19 10:01数值：28正常
• 日期：2012-08-19 10:02数值：40正常（仍低于最大值+阈值）
• 日期：2012-08-19 10:03数值：41正常（仍低于最大值+阈值）
• 日期：2012-08-19 10:04数值：39正常
• 日期：2012-08-19 10:05数值：46正常（高于阈值，重复计数1）
• 日期：2012-08-19 10:06数值：39正常
• 日期：2012-08-19 10:07数值：38正常
• 日期：2012-08-19 10:08数值：39正常
• 日期：2012-08-19 10:09数值：38正常
• 日期：2012-08-19 10:10数值：39正常
• 日期：2012-08-19 10:11数值：38正常（上次异常事件>重复时间窗口，重复计数0）
• 日期：2012-08-19 10:12数值：41正常（仍低于最大值+阈值）
• 日期：2012-08-19 10:13数值：46正常（高于阈值，重复计数1）
• 日期：2012-08-19 10:14数值：47正常（高于阈值，重复计数2）
• 日期：2012-08-19 10:15数值：46正常（高于阈值，重复计数3）
• 日期：2012-08-19 10:16数值：47正常（高于阈值，重复计数4）
• 日期：2012-08-19 10:17数值：46正常（高于阈值，重复计数5）->警报

架构设计要求： 所有逻辑都必须在业务层内，这意味着我们不能使用存储过程或触发器

可能的解决办法1： 我们的第一个想法是为ZigBee和Rfid服务附加模块逻辑，但这可能会导致性能阻塞。如果我们对每个服务请求调用DB进行最后一次检查，我们将生成大量的计算事务，甚至可能以死锁结束。我们可以在这里使用WCF队列机制，但是我们仍然看不到解决这个问题的任何好处

欢迎对此解决方案提出任何建议

可能的解决办法2： 第二个想法是部署另一个Windows进程，该进程将以配置的频率在后台扫描数据库，如果出现“高于阈值”的情况，则将此信息保存到单独的“缓存”表中，并在数据库中“标记”该行已检查特定的通知/警报。 因此，以后它将不会被添加到扫描中

这意味着：

另一个“缓存”表

在我们配置的“扫描仪”中，发送通知/警报的延迟为30分钟

为了将行“标记”为“特定通知”，我们不能简单地添加Bool标志，因为对于许多已定义的通知（3-4个施工场地通知），计算时可能会考虑1行偏离读数

有多少“过程”、“背景工作人员”应该同时工作？与现有通知配置相同，或者一个用于所有通知配置，使用堆栈

欢迎对此解决方案提出任何建议

结论:

---

如果您有任何想法、经验、了解现有的解决方案（DLL）、处理此类问题的模式并与我们分享，我们将不胜感激。

您应该在Windows Azure服务总线中查看另一个解决方案，

主题

。既然你们实际上是在谈论来自传感器/设备的数据，我建议你们阅读《MSDN杂志》上克莱门斯·维斯特的文章：

在上，您正在谈论在数据库中存储非规范化数据。为什么不使用表存储呢？

你说“如果你有任何想法”，所以