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

Question

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

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

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

这一切都运行得非常好，直到 MSMQ 变得难以支持，我们放弃了它以在客户端计算机上进行单线程报告。

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

所以：

• SQL Server 2005 及以上版本
• Win Server 2003 及以上版本
• .NET 3.5（是的，我知道，不是那么现代）
• “Web 前端”（无关紧要，因为所有 IPC 都是服务器端，尽管在多个服务器上）
• 水晶报告 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 表轮询更好的方法吗？至少具有优势（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 保证应用程序按照消息发送的顺序只接收每条消息一次。