0

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

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

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

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

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

所以：

  • SQL Server 2005 及更高版本
  • Win Server 2003 及以上版本
  • .NET 3.5（是的，我知道，不是那么现代）
  • “网络前端”（无关紧要，因为所有 IPC 都是服务器端，尽管在多个服务器上）
  • 水晶报表 10.5

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

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

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

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

  • 运行（位，不为空）
  • 完成（位，不为空）

这很愚蠢，很简单，但会起作用。

我的愚蠢解决方案

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

客户端扫描日志表以查看作业是否完成。

好处：

  1. 它总是有效的，没有 IT 部门会妨碍我们
  2. 很简单，大家都会明白的
  3. 没有额外的技术或配置。（MSMQ 总是需要安装和配置）

缺点：

  1. 客户不知道服务的状态。
  2. 它是双重被动的，客户端和服务器都在不断地轮询一个表
  3. 如果启动了多台服务器，它们将开始双重渲染报告
  4. 我能想到的（3）的唯一解决方案是表上的某种排他写锁（Yuck！）
  5. 感觉就像圆孔中的方钉，一种解决方法而不是解决方案。IMO 这不是数据库的用途！

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

问题2：说真的，难道没有比MSMQ 和SQL Server 表轮询更好的东西吗？至少具有优势（1）和（3）的东西

4

1 回答 1

2

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

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

我已经以这种方式实现了几个基于服务的解决方案，特别是您希望使用外部激活方法，也称为基于事件的激活。

该文档指出：

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

于 2013-02-12T17:22:57.490 回答