在多线程服务中处理IPC的好方法是什么？

Question

多年前，我们编写了一个“多线程”客户端/服务器报告生成系统。

它基于VB6，SQL Server 7，Crystal Reports 7和MSMQ，混合使用NT4 / Win2K / Win98

它在服务器上运行了多个EXE（多线程），监听来自客户端的循环请求，以生成报告并将消息发送回客户端计算机上的托盘应用程序。

这一切都非常顺利，直到MSMQ成为支持的痛苦，我们放弃了它在客户端机器上进行单线程报告。

现在我们必须使用现代技术重新创建该系统。

所以：

• SQL Server 2005以后
• Win Server 2003以后
• .NET 3.5（是的，我知道，不是那么现代）
• “网络前端”（与所有IPC无关，尽管在多台服务器上都是如此）
• Crystal Reports 10.5

现在，大多数情况下，没有什么困难。

但是在被MSMQ烧毁之后，我们想要一些可以在没有一百种不同的客户IT策略的情况下部署的东西，从而无法支持。

我的默认回落在这个位置很简单。使用SQL Server存储作业列表和这些作业的状态。

我们都准备好了一个“ReportLog”表来存储作业，我只需要添加状态字段，可能是：

• 正在运行（位，非空）
• 完成（位，非空）

这很愚蠢，但很有效。

我的愚蠢解决方案

好的，所以我构建了一个Windows服务，其中有一个线程正在监视表，每次出现新作业时都会生成线程池作业。完成单个报告后，每个线程都会返回OK或Error。

客户端扫描日志表，查看要完成的作业。

优点：

1. 它将永远有效，没有IT部门会妨碍我们
2. 很简单，每个人都会理解它
3. 没有额外的技术或配置。 （MSMQ总是需要安装和配置）

缺点：

1. 客户不知道服务的状态。
2. 它是双被动的，客户端和服务器都在不断地轮询表格
3. 如果启动了多台服务器，它们将启动双重呈现报告
4. 只有解决方案（3）我能想到的是桌子上的某种独家写锁（哎呀！）
5. 感觉像是圆孔中的方形钉，是一种解决方案，而不是解决方案。 IMO这不是数据库的用途！

问题1：如果我的愚蠢解决方案是个好主意，我该如何预防劣势（4）？

问题2：说真的，MSMQ和SQL Server表轮询是不是有更好的东西？至少具有Advantage（1）和（3）

的东西

Answer 1

如果您已经在使用SQL Server，那么SQL Server Service Broker是MSMQ的最佳替代品，尤其是对于这种情况。

缺点＃2,3,4和5自动解决，＃1可以通过一些工作解决。您应该能够保留优势＃1和3，但可能会失去＃2。

我已经通过这种方式实现了多个基于服务的解决方案，特别是您希望使用External Activation方法，也称为Event-Based Activation。

文档说明：

  

同一任务的消息是同一对话的一部分。在每个对话中，Service Broker保证应用程序按照发送消息的顺序只接收一次消息。