如何在数据库绑定应用程序之间有效通信

Question

我们有许多不同的旧式客户端 - 服务器C＃WinForm客户端应用程序，它们本质上是数据库的前端。然后有一个C＃服务器端Windows服务，它等待客户端应用程序提交订单然后处理它们。

服务器端服务发现是否有工作要做的方法是轮询数据库。多年来，由于无数的业务规则，轮询等待订单的逻辑变得更加复杂。因此，即使没有任何事情要做，轮询存储过程本身也会使用相当多的SQL Server资源。除此之外，还要求订单在提交时处理，并且您自己遇到了性能问题，因为数据库正在不断进行轮询。

现在设置实际上工作正常，但负载即将通过屋顶，很明显，它不会支撑。

在一堆不同的客户端应用程序和服务器端Windows服务之间进行通信的有效方法有哪些，这比现有方法更具有前瞻性？

数据库服务器是SQL Server 2005.如果真的能实现，我可能会获得最新SQL Server的权力，但我宁愿不打那场战斗。

Answer 1

您可以通过多种方式通知客户。

• 您可以使用现成的解决方案（如NServiceBus）将信息从服务器发布到客户端或其他服务器。 NServiceBus使用MSMQ以非常简单和持久的方式向多个订阅者发布一条消息。
• 您可以使用MSMQ或其他排队产品从服务器发布将传递给客户的邮件。
• 您可以在Windows服务上托管WCF服务，并使用双工通道从每个客户端连接到该服务。每次更改时，服务都会通知相应的客户或甚至所有客户。这对代码来说更复杂，但也更灵活。您可以将足够的信息发送回客户端，根本不需要轮询数据库。
• 您可以让服务向所有客户端广播UDP数据包，以通知他们需要进行更改。您可以在数据包中添加足够的信息，以允许客户端决定是否需要从服务器提取数据。这对于服务器和网络来说非常轻量级，但它假设所有客户端都在同一个LAN中。

Answer 2

也许您可以利用SqlDependency仅在数据实际发生变化时才接收通知。

Answer 3

您可以使用任何消息中间件（如MSMQ，JMS或TIBCO）在您的客户端和服务之间进行通信。

Answer 4

到目前为止，最简单，也是最便宜的答案就是购买更大的服务器。

除此之外，您正在进行一项很有可能早期失败的开发工作。如果失败，我并不是说你最终会刮掉你最终建造的东西。相反，我的意思是你在调试无数业务规则时启动更改并且订单会被搞砸。

坦率地说，我不会考虑在压力下接近通讯变更;假设您在短期内“通过屋顶”进行负载声明。

如果您的风险暴露在第一天必须100％正常运行（当您预期订单大幅增加时这是正常的），没有打嗝，那么只需升级数据库服务器。哎呀，我不会甚至安装最新的sql server。相反，只需购买更大的机器，安装完全相同的操作系统和数据库服务器（以及补丁级别）并移动数据库。

然后查看您的体系结构，以确定需要消除的内容以及可以挽救的内容。

Answer 5

如果每个人都连接到SQL Server，那么还有Service Broker选项。与目前推荐的其他消息传递/排队解决方案不同，它完全包含在您的数据库中（没有单独的产品可供部署，管理和配置），它提供了与您的备份/恢复和高可用性需求相关的单一故事（无需单独备份）对于消息存储，没有单独的DR / HA，无论您的数据库解决方案是什么，也是您的消息传递解决方案），还有统一的编程API（SQL）。

即使所有内容都在一个SQL Server实例中（即，不需要在多个SQL Service实例之间通过网络进行通信），Service Broker仍然具有无人匹配的ace：activation。通过激活，您完全消除了轮询的需要，因为系统本身将在有事件要处理时启动您的处理代码（将“激活”）。处理代码可以是内部的（T-SQL过程或SQLCLR .Net过程）或外部的（参见external activator）。